[size=150]Ceci est le fil de discussion pour le T&A Routage sélectif vers une connexion internet secondaire.[/size]
Bravo, joli travail et intéressant.
Merci, j’avoue avoir pas mal galéré pour arriver à le faire fonctionner… Sans parler des kilomètres de documentation absconse que j’ai dû me farcir. 
Salut,
Bravo Syam, très bon tuto ! J’étais passé à côté hier…
Et se taper iptables avec marquages des paquets, rien que ça… ça mérite une médaille 
Edit : Il y a une place toute prête pour lui sur le wiki 
Il y a encore une chose qui me chagrine : lorsqu’un accès secondaire instable (type PPP) est déconnecté sauvagement, je n’arrive pas à détecter les “anciennes” connexions – qui utilisaient cet accès, et qui doivent impérativement être fermées avec REJECT tcp-reset – et les “nouvelles” connexions qui peuvent utiliser l’accès principal.
En ce qui me concerne je préfère tout bloquer dans ce cas, et intervenir à la main, mais c’est loin d’être idéal !
Si vous avez des idées pour résoudre ce souci, n’hésitez pas…
Et bien entendu, les idées de stratégies de routage sont les bienvenues (même si vous ne savez pas quelles règles utiliser pour que ça fonctionne c’est pas grave, on cherchera ensemble).
L’idée étant d’avoir une partie générique, le premier script de la section (9), et à côté de ça toute une série de « recettes » plus ou moins prêtes à l’emploi (ma stratégie « par process / groupe » n’étant qu’une des infinies possibilités).
[quote=“syam”]Il y a encore une chose qui me chagrine : lorsqu’un accès secondaire instable (type PPP) est déconnecté sauvagement, je n’arrive pas à détecter les “anciennes” connexions – qui utilisaient cet accès, et qui doivent impérativement être fermées avec REJECT tcp-reset – et les “nouvelles” connexions qui peuvent utiliser l’accès principal.
En ce qui me concerne je préfère tout bloquer dans ce cas, et intervenir à la main, mais c’est loin d’être idéal ![/quote]
Je me réponds à moi-même mais c’est pas grave…
Je pense avoir trouvé la solution : ça devrait fonctionner en rajoutant des règles de marquage de connexion (-j CONNTRACK / -m conntrack) là où ça va bien.
Et j’ai aussi trouvé un petit “outil” indispensable : un schéma à la fois complet et clair pour le parcours d’un paquet au travers des divers composants d’iptables et de routage.
Depuis le temps que je cherchais quelque chose comme ça, je n’avais jamais pensé à regarder sur Wikipedia… 
Grâce à ça et avec un peu de chance je vais pouvoir optimiser un peu les différentes règles.
Bref, pour le moment je ne peux pas tester le marquage de connexion (j’ai des transferts importants en cours) mais je vous tiens au courant dès que j’ai réussi.
Edit : en fait, il y a un gros souci avec le blocage des connexions quand l’accès internet secondaire saute sans prévenir. Je sais pas ce que j’ai foutu quand j’ai rédigé/testé le tuto initialement, mais le fait est que même les règles de base (REJECT) ne marchaient pas du tout. J’ai donc supprimé les règles correspondantes du tuto en attendant de tirer ça au clair.
Bon, j’ai trouvé une solution qui fonctionne sur trois pattes (marquage de connexion CONNMARK en plus du marquage de paquets) mais c’est loin d’être idéal.
Je vais reprendre l’ensemble du tuto pour ajouter une notion d’affinité d’interface : autrement dit, une connexion qui commence sur une interface/passerelle continue de l’utiliser quels que soient les changements dans la configuration, ou bien est tout simplement fermée s’il n’y a pas le choix (de toutes façons une connexion commencée sur une interface donnée ne peut pas être transférée sur une autre interface).
Souhaitez moi bon courage. 
Bonjour
Alors voilà cela fait un moment que je me casse les dents pour faire un routage sélectif et là bein je deviens fou, j’ai plus dents etc…
Je cherche donc a avoir un regard extérieur à mon problème. Je suis sure qu’il s’agit d’un oubli/erreur toute bête mais je la vois pas Grrrrrrrr
Donc je serais vraiment reconnaissant si quelqu’un arrive à me dépanner.
En résumé j’ai un serveur sous fedora 14 .
Le serveur à une interface réseau connecté à une livebox.
J’ai un accès vpn pptp dans lequel j’aimerai faire transiter certain procèssus lancé avec un user/group particulier. Ce tutorial très bien fait m’a semblé tout indiqué. ( et j en remercie énormément l’auteur ) Mais snif cela ne marche pas pour moi.
J’ai fais le word suivant avec toute les étapes réalisées avec log & capture.
http://dl.free.fr/v2r1BELsz
dl.free.fr/v2r1BELsz
merci d’avance
see you
gui
Y a pas un peu plus ouvert comme format ? Genre texte brut, HTML, OpenDocument voire PDF…
Je vais encore faire mon grognon (on ne se refait pas), mais ce document n’aurait pas perdu grand chose à être en texte brut… Et faire des captures de terminal texte sous forme d’images, c’est loin d’être optimal.
Non, c’est l’adresse du “pair”, la machine à l’autre bout de la connexion PPP. La notion de passerelle n’a pas de sens ici, car ce qu’un pair envoie par l’interface point à point est forcément destiné à l’autre pair.
[quote]On ajoute ensuite la route par défaut pour la passerelle secondaire :
ip route add table 78 default via 192.168.35.145 dev ppp0[/quote]
En conséquence de ce qui précède, “via 192.168.35.145” est superflu.
[quote]Mise en place de la translation NAT
iptables -t nat -A POSTROUTING -o ppp0 -m mark --mark 78 -j SNAT --to-source
138.199.77.3[/quote]
Il me semble inutile de vérifier la marque : tout ce qui est envoyé par ppp0 doit sortir avec l’adresse de l’interface de toute façon.
Si les paquets émis sont routés correctement et les réponses reçues, alors mon premier réflexe est de regarder du côté du “reverse path filtering” (rp_filter)
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
Les deux valeurs doivent être à 0 pour que le routage avancé soit opérationnel.
merci pour ta réponse ! et dzl pour les captures images …
[quote]
Citer:
On ajoute ensuite la route par défaut pour la passerelle secondaire :
ip route add table 78 default via 192.168.35.145 dev ppp0
En conséquence de ce qui précède, “via 192.168.35.145” est superflu.[/quote]
ok merci ma table de routage donne donc : ( maise cela ne change rien apparemment )
[root@Snorky ~]# ip route show table 78
138.199.67.17 via 192.168.0.1 dev eth0 src 192.168.0.18
192.168.35.145 dev ppp0 proto kernel scope link src 138.199.77.34
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.18
169.254.0.0/16 dev eth0 scope link metric 1002
default dev ppp0 scope link
[root@Snorky ~]# sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0
[root@Snorky ~]# sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0[/code]
Les 2 valeurs sont bien à 0
si je supprime
[code]
iptables -t nat -A POSTROUTING -o ppp0 -m mark --mark 78 -j SNAT --to-source
138.199.77.34[/code]
[code][root@Snorky ~]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- anywhere anywhere to:138.199.77.34
[root@Snorky ~]# iptables -t nat -F
[root@Snorky ~]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
[root@Snorky ~]#
[/code]
alors un tcpdump -i ppp0 me montre que les trames partent avec une adresse d'émission en 192.168.0.18 : ( test d'un ping sur 74.125.230.84 > google.fr )
[code][root@Snorky ~]# tcpdump -i ppp0
00:45:37.658765 IP 192.168.0.18 > 74.125.230.84: ICMP echo request, id 4514, seq 1, length 64
00:45:38.657823 IP 192.168.0.18 > 74.125.230.84: ICMP echo request, id 4514, seq 2, length 64
00:45:39.657819 IP 192.168.0.18 > 74.125.230.84: ICMP echo request, id 4514, seq 3, length 64
00:45:40.657801 IP 192.168.0.18 > 74.125.230.84: ICMP echo request, id 4514, seq 4, length 64je n’est alors aucun retour sur l’interface
alors qu’avec “iptables -t nat -A POSTROUTING -o ppp0 -m mark --mark 78 -j SNAT --to-source
138.199.77.34” :
00:47:23.768518 IP 138.199.77.34 > 74.125.230.84: ICMP echo request, id 4522, seq 1, length 64
00:47:23.816800 IP 74.125.230.84 > 138.199.77.34: ICMP echo reply, id 4522, seq 1, length 64
00:47:24.038801 IP 92.41.255.151.51281 > 138.199.77.34.30295: UDP, length 121
00:47:24.038833 IP 138.199.77.34 > 92.41.255.151: ICMP 138.199.77.34 udp port 30295 unreachable, length 157
00:47:24.767809 IP 138.199.77.34 > 74.125.230.84: ICMP echo request, id 4522, seq 2, length 64
00:47:24.815795 IP 74.125.230.84 > 138.199.77.34: ICMP echo reply, id 4522, seq 2, length 64il semble que l’interface reçoive alors bien un retour de ping, mais la commande “ping” ne reçoit rien )
Je précise que si je ne fais pas de routage sélectif et positionne l’interface ppp0 en route par defaut ( table main) alors cela fonctionne ( mais tout passe par la connexion pptp ce qui n’est pas le but ) ^^
merci encore
edit : pour info la connection pptp m’associe une adresse ip différente à chaque connexion : 138.199.77.3 est ici devenue 138.199.77.34 .
Je n’ai pas dit de supprimer la règle iptables mais juste la correspondance sur la marque (-m mark). Tu peux aussi utiliser MASQUERADE au lieu de SNAT, ça évitera de devoir réécrire la règle avec la nouvelle adresse à chaque fois.
Note : tu as testé deux fois net.ipv4.conf.all.rp_filter, pas net.ipv4.conf.ppp0.rp_filter. Le fait que ça marche en changeant la route par défaut fait vraiment penser à un problème de rp_filter. Si c’était par exemple un problème de filtrage par iptables, alors le changement de route par défaut n’aurait pas d’effet.
yataaaa !
en fait tu avais bien vu juste :
après un
[root@Snorky ~]# sysctl -w net.ipv4.conf.eth0.rp_filter=0
[root@Snorky ~]# sysctl -w net.ipv4.conf.ppp0.rp_filter=0
[root@Snorky ~]# sysctl -p
cela fonctionne niquel 
maintenant il me reste plus qu’à comprendre tout ca :
!
merci encore
Pour finir j’ai donc remplacé sur ton conseil
iptables -t nat -A POSTROUTING -o ppp0 -m mark --mark 78 -j SNAT --to-source
138.199.77.3
par
effectivement c’est beaucoup plus propre et pratique ( plus besoin de récupérer l’adresse ip du vpn qui change tout le temps ) thanks
une petite dernière galère apparemment :
les services qui tournent sur le serveur semblent ne pas être accessibles depuis l’extérieur via la route secondaire ( connexion ppp0 )
un tcpdump m’indique bien que les trames arrivent ( requette http depuis 213.56.181.33(machine extérieur vers l’adresse ppp0 )
[code]
sur poste client distant (213.56.181.33) : wget 138.199.77.0
[root@Snorky ~]# tcpdump -i ppp0 host 213.56.181.33
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:36:03.164790 IP 213.56.181.33.49745 > 138.199.77.0.http: Flags [S], seq 1517055840, win 65535, options [mss 1452,nop,nop,sackOK], length 0
11:36:06.098789 IP 213.56.181.33.49745 > 138.199.77.0.http: Flags [S], seq 1517055840, win 65535, options [mss 1452,nop,nop,sackOK], length 0[/code]
mais le service httpd ne renvoie rien via ppp0 ( rien dans /var/log/httpd/access_log ou /var/log/httpd/error_log )
Cela ressort via eth0 :
[root@Snorky httpd]# tcpdump -i eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:46:36.478776 IP 138.199.77.0.http > 213.56.181.33.50019: Flags [S.], seq 204224492, ack 3745411598, win 5840, options [mss 1460,nop,nop,sackOK], length 0
je suppose que comme le serveur httpd ne tourne pas sous le group user-vpn alors les trames en réponse ne sont par marquées pour transiter via ppp0 ( juste ? )
existe il un moyen de marquer ces trames ?
ou bien une autre piste sur
linux-ip.net/html/adv-multi-internet.html
chapitre “Example 10.4. Multiple Internet links, inbound traffic; using iproute2 only”
à suivre … 
J’avais prévu d’aborder ce point (parmi d’autres comme quelques explications sur rp_filter, ou comment automatiser la mise en place de tout ça lors de l’établissement de la connexion grâce aux scripts de pppd) dans une réponse plus complète, mais pas le temps tout de suite.
Oui, les paquets de réponse ne sont pas envoyés par ppp0 parce qu’ils ne sont pas marqués, car actuellement avec ta règle de routage la seule façon de les envoyer par ppp0 est de les marquer. Donc oui, tu peux ajouter une règle iptables pour marquer les paquets émis avec l’adresse source de l’interface PPP (qu’il faudra mettre à jour à chaque fois que la connexion est établie) :
Une autre option est d’ajouter une règle de routage basée sur l’adresse source :
Encore une autre alternative consiste à marquer les connexions entrant par ppp0 et à reporter la marque de connexion sur les paquets sortants appartenant à ces connexions.
iptables -t mangle -A PREROUTING -i ppp0 -m state --state NEW -j CONNMARK --set-mark 78
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
niquel :
iptables -t mangle -A PREROUTING -i ppp0 -m state --state NEW -j CONNMARK --set-mark 78
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
cela fonctionne parfaitement, je suis vraiment bluffé par ton skill et la vélocité de tes réponses.
merci mille fois. 
[quote=“gsavin”]…je suis vraiment bluffé par ton skill et la vélocité de tes réponses.
merci mille fois. [/quote]
Arrête, on ne va plus pouvoir le tenir 