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 LaBienPensanceMaTuer . Évalué à 4. Dernière modification le 12 août 2019 à 15:15.
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.
tap0qui est une interface "virtuelle" peut elle être la route par défaut ?tap0? OpenVPN ? Container LXC ?181.188.139.163? Une adresse externe lamda ?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 ?
Un bon début pour qu'on t'aide serait:
route -n.iptables -t nat -L -v -niptables -L -v -nifconfig -a(ou l'équivalent avecip).Le ton de mon message peut paraitre un chouia pédant voir tout bonnement connard, mais ça commence à me fatiguer les mecs qui:
[^] # Re: Non non non
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
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
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.
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 alpha_one_x86 (site web personnel) . Évalué à 2.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Non non non
Posté par LaBienPensanceMaTuer . Évalué à 2.
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
tap0est 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 ?
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 ;-)
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 ?
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
tap0et deeth2explicitement (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 uniptables -F FORWARD && iptables -P FORWARD ACCEPTvoir 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 ;-)
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 alpha_one_x86 (site web personnel) . Évalué à 2. Dernière modification le 12 août 2019 à 17:55.
Justement ce n'est pas le cas, l'ip du serveur OpenVPN est bien dans la table de routage vers eth2 (donc ISP)
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).
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.
oui, avec et sans la route 181.188.139.0/24, ca marche dans tout les cas
je ne peu pas, vu que c'est justement un serveur en LAN qui réponds.
Déjà testé avec un iptables I FORWARD -j ACCEPT
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 LaBienPensanceMaTuer . Évalué à 2.
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 alpha_one_x86 (site web personnel) . Évalué à 2.
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 LaBienPensanceMaTuer . Évalué à 2.
Ok.
As tu essayé, dans le doute, de mettre une target
-j LOGen 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 LaBienPensanceMaTuer . Évalué à 2.
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
INPUTetOUTPUTqui 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 alpha_one_x86 (site web personnel) . Évalué à 2.
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/
[^] # Re: Non non non
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Pas d'autre réponse, je te remercie encore d'être le seul à avoir pris du temps pour moi.
J'ai un comportement qui peu expliquer CE BUG.
Mon routeur fait NAT et que je sort par une interface et re-rentre la réponse de mon ping par une autre interface alors ca ne marche pas.
Donc comment faire que ca marche? Comment voir et purger les connexions dans le NAT?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Non non non
Posté par LaBienPensanceMaTuer . Évalué à 2.
Ah, ce comportement est en effet problématique…
Est-ce voulu ?
Avec la commande ip (de iproute2) tu peux ajuster les routes plus finement pour forcer l'interface de sortie.
Peut être une piste à creuser …
Tu as des compteurs dispo avec le flag
-vpour iptables qui te donneront le nombre de paquets "catchés" par tes règles de NAT.Tu as aussi des outils dispos pour interagir avec la table de conntrack:
Genre, sous ma Debian:
conntrack - programme pour modifier les tables conntrack
conntrackd - démon de suivi de connexion
iptstate - interface de type top pour la table de surveillance de connexions netfilter
netstat-nat - tool that display NAT connections
Bon courage, tiens nous au courant !
[^] # Re: Non non non
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Le comportement n'est pas voulu, mais posible, BGP ne garantie pas que le reverse path soit le même, c'est les joies d'internet. Chaque AS envoie vers le chemin qu'il souhaite (ce que j'ai aussi vu dans mes cours de routages por les AS avec beaucoup de liaisons).
Je suis tombé sur les outils que tu m'as cité, mais cela ne m'aide pas à corrigé mon problème.
Je sais ni quel mot clef chercher (pas de résultat avec ceux que j'ai utilisé), ni où trouver de l'aide.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.