Oui il me semble que c’est bien le truc que j’avais vu (bien que leur site ait beaucoup changé depuis le temps, donc je ne suis pas 100% positif, ma mémoire a ses limites).
Évidemment, si j’ai bien compris, c’est toujours sujet aux problèmes que tu citais : les équipements réseau de l’hébergeur pourraient avoir des filtres bloquant les paquets émis avec une autre adresse IP source que celle de la machine émettrice (je pars toujours du principe que les adresses doivent être spoofées, je ne vois pas comment ça pourrait marcher autrement). Mais si ça passe du point de vue de l’hébergeur c’est l’idéal question bande passante pour une configuration avec un front-end.
Au moins les paquets SYN du client sont redirigés vers 10.0.0.2 et arrivent par le tunnel, mais avec l’adresse source originelle du client au lieu de celle du frontal (il vaudrait mieux utiliser --to 10.0.0.1 d’ailleurs). Apparemment la règle SNAT n’est pas efficace. Pourtant elle me semble correcte, il y a un truc qui m’échappe… Et sans routage avancé sur le serveur la réponse vers l’adresse du client devrait être émise par eth0, mais tcpdump sur cette interface ne voit que les paquets UDP du tunnel. Le serveur a bien les sysctl net.ipv4.conf.{all,tun0}.rp_filter à 0 ?
Au moins les paquets SYN du client sont redirigés vers 10.0.0.2 et arrivent par le tunnel, mais avec l’adresse source originelle du client au lieu de celle du frontal (il vaudrait mieux utiliser --to 10.0.0.1 d’ailleurs). Apparemment la règle SNAT n’est pas efficace. Pourtant elle me semble correcte, il y a un truc qui m’échappe… Et sans routage avancé sur le serveur la réponse vers l’adresse du client devrait être émise par eth0, mais tcpdump sur cette interface ne voit que les paquets UDP du tunnel. Le serveur a bien les sysctl net.ipv4.conf.{all,tun0}.rp_filter à 0 ?[/quote]
Sur les deux serveurs :
sysctl -p
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.tun0.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.ip_forward = 1
La règle IPTABLES appliquée sur le serveur frontal :
Je n’ai pas appliqué de règles SNAT puisque tu m’as dis qu’elle était nécessaire seulement pour la méthode 2a.
D’accord, ça explique l’adresse source non modifiée. Mais pas l’absence de réponse sur l’interface eth0 du serveur caché… Tant pis.
Maintenant, pour que les paquets de réponse du serveur caché soient routés via le tunnel :
[code]# router les paquets dont l’adresse source est 10.0.0.2 selon la table 100
ip rule add from 10.0.0.2 table 100
dans la table 100, tout est envoyé par le tunnel
ip route add default dev tun0 table 100[/code]
[quote=“PascalHambourg”]D’accord, ça explique l’adresse source non modifiée. Mais pas l’absence de réponse sur l’interface eth0 du serveur caché… Tant pis.
Maintenant, pour que les paquets de réponse du serveur caché soient routés via le tunnel :
[code]# router les paquets dont l’adresse source est 10.0.0.2 selon la table 100
ip rule add from 10.0.0.2 table 100
dans la table 100, tout est envoyé par le tunnel
ip route add default dev tun0 table 100[/code][/quote]
Tu es un Dieu.
176.31.205.38/
Non. S’il existe Dieu est omniscient, et je ne comprends toujours pas pourquoi tcpdump ne voyait pas les paquets de réponse.
Ah, attention quand même : tu risques de rencontrer des problèmes de MTU ou de fragmentation avec le tunnel car un paquet de taille maximum (1500 octets) ne peut pas être encapsulé en entier dans un seul paquet UDP du tunnel, l’encapsulation ajoutant quelques dizaines d’octets.
Sur le serveur web, tout est OK le serveur est bien caché. En revanche ce n’est pas le cas pour le serveur TeamSpeak. J’arrive à m’y connecter via l’adresse IP du serveur public mais il est affiché que je suis connecté sur l’IP “cachée” :
C’est peut-être une particularité du protocole utilisé par Teamspeak, que je ne connais pas. Apparemment la voix sur IP de Teamspeak utilise UDP, or certains services peuvent avoir des problèmes pour sélectionner l’adresse source de réponse en UDP lorsqu’ils tournent sur une machine “multihomée” qui a plusieurs adresses IP comme c’est le cas du serveur. Tu peux essayer de forcer le serveur Teamspeak à n’utiliser que l’adresse du tunnel 10.0.0.2 pour voir. Tu peux aussi faire une capture de trafic pour voir ce qui se passe au moment de l’établissement de la connexion.
D’acc, merci à tous encore pour votre aide 
(Question au passage : ip rule add from 10.0.0.2 table 100 <= il signifie quoi ce 100 ?)
C’est le numéro de la table de routage utilisée par cette règle.
Il y a 255 tables de routage numérotées de 1 à 255. On peut leur donner des noms plus parlants que les numéros via le fichier /etc/iproute2/rt_tables, qui contient par défaut les noms associés aux tables réservées :
- 255 “local”, qui contient les routes locales et broadcast
- 254 “main”, qui est la table de routage principale utilisée par défaut par les commandes route et ip route)
- 253 “default”, dont je ne connais pas l’utilité, l’ayant toujours vue vide)
Les autres tables entre 1 et 252 sont disponibles pour faire du routage avancé. 100 est une valeur parfaitement arbitraire, j’aurais pu aussi bien en choisir une autre. La commande “ip rule” affiche les règles de routage et les tables qu’elles utilisent. Par défaut :
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Ce qui signifie que le système va successivement chercher une route correspondant à la destination dans les tables local (priorité maximum), main, puis default. Si on ajoute une règle sans spécifier de numéro, elle s’insère avec le numéro de priorité libre le plus élevé, soit 32765 juste avant la règle de la table principale “main”.
D’acc, encore merci pour tout