Forum Linux.noyau Routage packet DROP avec ajoute d'une entrée de routage

Posté par (page perso) . Licence CC by-sa.
Tags : aucun
0
12
août
2019

Bonjour,

Je fait des testes sur un petit routeur et je n'arrive pas a cerné un problème.
Je tiens à préciser que j'ai monté mon FAI, donc mes connaissances en routage sont correcte. Mais je pense que je passe à coté d'un truc basique.

J'ai un routeur:
- eth0: LAN
- eth2: WAN + NAT
- tap0: 10.1.2.3 gateway par défaut

Je teste la connexion vers 45.225.75.2:443 (https)
- depuis un FAI: 181.188.139.163, ca marche
- Je fait: /bin/ip route add 181.188.139.0/24 via 10.1.2.3 dev tap0: et depuis ce meme FAI: 181.188.139.163, ca ne marche pas

  • Je vois bien le SYN packet entrée dans tap0
  • Quand la route est dans la table de routage, je ne vois pas le packet sortir vers eth0/eth2/tap0
  • Cette route ne devrai rien charger. car la default gateway est aussi 10.1.2.3 via tap0

Cordialement,

  • # Non non non

    Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 12/08/19 à 15:15.

    j'ai monté mon FAI, donc mes connaissances en routage sont correcte

    Non.
    Il y a bon nombre de mécanos qui sont moins compétents que moi en mécanique.
    Si t'es là aujourd'hui, c'est vraisemblablement que tes connaissances sont p-ê pas si correctes que tu ne le crois.
    Le premier truc à faire qu'en t'es face à des problèmes chelous, c'est de te remettre en cause et te dire que tu as loupé un truc et que tes connaissances restent limitées.
    C'est qu'un état d'esprit, mais ça va tellement mieux quand t'y es.

    J'ai un routeur:
    - eth0: LAN
    - eth2: WAN + NAT
    - tap0: 10.1.2.3 gateway par défaut

    1. Comment tap0 qui est une interface "virtuelle" peut elle être la route par défaut ?
    2. D'ou vient ce tap0 ? OpenVPN ? Container LXC ?

    Je teste la connexion vers 45.225.75.2:443 (https)
    - depuis un FAI: 181.188.139.163, ca marche
    - Je fait: /bin/ip route add 181.188.139.0/24 via 10.1.2.3 dev tap0: et depuis ce meme FAI: 181.188.139.163, ca ne marche pas

    1. Pas compris… c'est quoi 181.188.139.163 ? Une adresse externe lamda ?
    2. Le "ca ne marche pas", c'est depuis la GW ? Depuis un client derrière le LAN ? Depuis une VM sur le routeur ?

    Je vois bien le SYN packet entrée dans tap0
    Quand la route est dans la table de routage

    Si la route n'est pas dans la table de routage, bein c'est pas une route.
    Ca veut dire quoi au final cette phrase ?

    je ne vois pas le packet sortir vers eth0/eth2/tap0
    Tu as activé le forwarding de port sur ta GW ?
    Tu as activé le MASQUERADING si nécessaire ?

    Cette route ne devrai rien charger. car la default gateway est aussi 10.1.2.3 via tap0

    Un bon début pour qu'on t'aide serait:

    • De nous faire un bout de schéma qui rendrait ton setup plus claire.
    • De nous donner:
      1. La sortie d'un route -n.
      2. La sortie d'un iptables -t nat -L -v -n
      3. La sortie d'un iptables -L -v -n
      4. La sortie d'un ifconfig -a (ou l'équivalent avec ip).

    Le ton de mon message peut paraitre un chouia pédant voir tout bonnement connard, mais ça commence à me fatiguer les mecs qui:

    1. Viennent en se la racontant (j'ai monté un FAI tavu, je suis un cador donc je sais).
    2. Viennent sans donner les éléments suffisant à avoir de l'aide (Pourtant, si t'as monté un FAI tu dois etre suffisament technique pour savoir que ton post ne contient pas suffisament d'info).
    3. Ne reviennent jamais ensuite sur le post alors que tout le monde s'est gratté la tête pendant un certain moment pour aider et apprécierait de savoir quel était le problème, dans le fond.
    • [^] # Re: Non non non

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Je comprends ce que tu essaye de me dire. Le but n'est pas de dire que je sais tout, mais de mettre de coté certain commentaire pour les gens qui commence de 0.

      Je ne vois pas le problème que tap0 soit la route par défaut, une interface virtuelle/tunnel reste une interface
      tap0: OpenVPN

      Pas compris… c'est quoi 181.188.139.163 ? Une adresse externe lamda ?
      Le "ca ne marche pas", c'est depuis la GW ? Depuis un client derrière le LAN ? Depuis une VM sur le routeur ?

      181.188.139.163 est l'IP publique du SuperNat de mon FAI 4G que j'utilise sur mon téléphone. Ca ne marche pas depuis mon téléphone.

      Si la route n'est pas dans la table de routage, bien c'est pas une route.
      Ca veut dire quoi au final cette phrase ?

      Je reformule: Quand j'ai l'entrée dans ma table de routage, le packet n'est plus FORWARD.

      Je ferai un schéma que je posterai en réponse.

      Certaines info peuvent être sensible:
      https://pastebin.com/xKQ1UPU1
      https://pastebin.com/MUTFZsqU
      https://pastebin.com/DgrcLWtz
      https://pastebin.com/5sZ2VHeN

      Je comprends que tu soit fatigué. Je ferai de mon mieux pour répondre à tes questions. Désolé si je ne suis pas claire, j'ai des problèmes à m'exprimer clairement.

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

      • [^] # Re: Non non non

        Posté par (page perso) . Évalué à 2 (+0/-0).

        Probléme

        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

      • [^] # Re: Non non non

        Posté par (page perso) . Évalué à 2 (+0/-0).

        Je ne vois pas le problème que tap0 soit la route par défaut, une interface virtuelle/tunnel reste une interface
        tap0: OpenVPN

        Le problème est là: ton interface "virtuelle" est nécessairement reliée, via l'interface, à une interface physique et à un "peer" réel.
        Admettons que la passerelle OpenVPN qui te permet de monter ton tap0 est sur l'adresse IPv4 publique (donc hors de ton réseau) 22.33.44.55.
        Si tu places la route par défaut sur tap0 ET que tu ne forces pas une route via eth2 (ton WAN) vers 22.33.44.55 tu vas te retrouver avec tes paquets OpenVPN vers 22.33.44.55 routés via … ton OpenVPN.
        Tu vois le hic ?

        181.188.139.163 est l'IP publique du SuperNat de mon FAI 4G que j'utilise sur mon téléphone. Ca ne marche pas depuis mon téléphone.

        Ok, donc adresse publique lambda.
        Es tu sûr que cette adresse réponde "tout le temps" ?
        Sur quel port TCP/IP et à quel protocole ? J'ai toujours quelques méfiances envers les trucs de FAI ;-)

        Je reformule: Quand j'ai l'entrée dans ma table de routage, le packet n'est plus FORWARD.

        Et avant ça fonctionne ?
        En gros, l'idée, c'est plutôt que de faire passer ce trafic via OpenVPN plutôt que par ta connection FAI, c'est ça ?

        Certaines info peuvent être sensible […]

        Ok, donc en regardant les infos fournies:

        • Bon, déjà la suspicion évoquée plus haut est caduque: tu as bien forcé une route vers ta passerelle OpenVPN via eth2. Donc on est déjà bon à ce niveau… en tout cas si 192.168.1.2 est bien le routeur qui te permet de joindre internet.

        • As tu essayé de pinguer ta passerelle côté VPN (172.30.125.1) ? Elle répond ?

        • Concernant ton dump de règle iptables et, en particulier, la règle de POSTROUTING je vois un premier problème: tu masquerades TOUT le trafic, sans distinction d'adresse physique source ou autre. En fonction de ton setup, ça peut marcher … ou pas. Vaut mieux dire que tu masquerades tout ce qui sort de tap0 et de eth2 explicitement (la même régle avec un -o <INTERFACE>.

        • Je n'ai pas regardé en détail tes règles de PREROUTING… peut y avoir des choses qui interferent … Pour les tests, mieux vaut, si tu peux, passer par un ruleset "vide".

        • Donc tu as déjà des choses dans ta chaine FORWARD: même conseil que précédemment: par sur un iptables -F FORWARD && iptables -P FORWARD ACCEPT voir si ça marche, ensuite tente d'affiner. Tu peux également ajouter à la fin (donc avant le DROP) une règle de LOG (-j LOG) histoire de voir si tes paquets sont droppés à cause du firewall.

        Là, à vue de nez, le seul truc qui manque c'est d'activer le forwarding côté noyau:

        $ sudo sysctl -a|grep -i ip_forward
        net.ipv4.ip_forward = 0

        Chez toi, ça doit valoir 1 pour que le noyau fasse passer les paquets d'une interface à l'autre ;-)

        Je comprends que tu soit fatigué. Je ferai de mon mieux pour répondre à tes questions. Désolé si je ne suis pas claire, j'ai des problèmes à m'exprimer clairement.

        Pas de soucis… je suis pas totalement "à bout" car j'ai encore envie de donner un coup de main!

        • [^] # Re: Non non non

          Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 12/08/19 à 17:55.

          Tu vois le hic ?

          Justement ce n'est pas le cas, l'ip du serveur OpenVPN est bien dans la table de routage vers eth2 (donc ISP)

          Es tu sûr que cette adresse réponde "tout le temps" ?
          Sur quel port TCP/IP et à quel protocole ? J'ai toujours quelques méfiances envers les trucs de FAI ;-)

          Oui, cette adresse est pour la partie client. J'ai aussi tester depuis mon serveur ovh avec curl (mais je n'est rien dit pour ne pas paraître + confus).

          En gros, l'idée, c'est plutôt que de faire passer ce trafic via OpenVPN plutôt que par ta connection FAI, c'est ça ?

          non, cette partie est déjà fonctionnelle. OSFPv2/v3, IPv4/IPv6 + BGP pour l'échange de route vers différent AS du pays: ok et notre bloque IP est propagé à différent AS.

          As tu essayé de pinguer ta passerelle côté VPN (172.30.125.1) ? Elle répond ?

          oui, avec et sans la route 181.188.139.0/24, ca marche dans tout les cas

          PREROUTING… peut y avoir des choses qui interferent

          je ne peu pas, vu que c'est justement un serveur en LAN qui réponds.

          Donc tu as déjà des choses dans ta chaine FORWARD

          Déjà testé avec un iptables I FORWARD -j ACCEPT

          Là, à vue de nez, le seul truc qui manque c'est d'activer le forwarding côté noyau

          net.ipv4.ip_forward=1 déjà actif, si non je ne pourrai ni l'utilisé comme NAT, ni forward les serveurs vers la LAN. Routeur actuellement online.

          Je te remercie de l'aide et du temps que tu me consacre.

          Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

          • [^] # Re: Non non non

            Posté par (page perso) . Évalué à 2 (+0/-0).

            Je dois t'avouer que je sèche un peu … mais le setup et les flux impliqués ne sont pas hyper clairs dans ma tête.

            Pourrais tu essayer de reposer le contexte de ton problème ?

            • [^] # Re: Non non non

              Posté par (page perso) . Évalué à 2 (+0/-0).

              En temps normal un packet source: x.x.x.x vers y.y.y.y est bien FORWARD.

              z.z.z.z est la default gateway.

              Mais quand je rajoute dans la table de routage une route vers x.x.x.0/24 via z.z.z.z alors ce même packet n'est plus forward. Chose qui est étrange car la table de routage s'applique à la destination et pas à la source

              Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

              • [^] # Re: Non non non

                Posté par (page perso) . Évalué à 2 (+0/-0).

                Ok.
                As tu essayé, dans le doute, de mettre une target -j LOG en guise de dernière règle de tes chaines iptables ?
                Ca te permettra peut être d'y voir plus clair…

                • [^] # Re: Non non non

                  Posté par (page perso) . Évalué à 2 (+0/-0).

                  Ah, et aussi …

                  Déjà, tes essais, c'est directement depuis le routeur ? Ou c'est depuis une machine derrière le routeur ?
                  Dans le premier cas (mais tu le sais probablement déjà), c'est les chaines INPUT et OUTPUT qui régissent le passage de ton flux. Dans le second cas (ça tu le sais c'est sur) c'est la chaine FORWARD.

                  La façon dont tu as écrit ta règle de masquerading m'étonne aussi. Me concernant, j'ai l'habitude préciser une interface de sortie (-o eth0) plutôt qu'une plage d'adresse source… Y a pas de raison que ça ne marche pas … Mais ça risque de créer des trucs bizarres.

                  J'vais continuer à me gratter la tête car ton problème m'intrigue. Tiens nous au jus si tu trouves par toi même ;-)

                  • [^] # Re: Non non non

                    Posté par (page perso) . Évalué à 2 (+0/-0).

                    le log ne me sert pas, idem dmesg.
                    Je fait directement depuis le routeur (routeur secondaire, datacenter tiers 4/ISP fait main ;) ).
                    Le flux passe par le routeur mais n'est pas a destination de celui si, donc tout est coté FORWARD (confirmé en jouant avec le firewall).

                    Justement, vu que j'ai divers ip qui transit par la, dons des IP publiques, seule les IP interne doivent être réecrite.
                    J'ai toujours pas trouvé, je continue de chercher.

                    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.