Paul Filo a écrit :
Masquerading de rigueur en effet pour que les paquets de réponse trouvent le chemin du retour jusqu'au serveur SSH, sauf si d'une part l'interface tunnel du client a une adresse - libre évidemment - que la passerelle du serveur sait joindre, par exemple dans le sous-réseau du LAN du serveur, et d'autre part le proxy_arp est activé sur le serveur. Ainsi le serveur répondra aux requêtes ARP pour l'adresse de tunnel du client.Une bonne vieille route statique point à point suffit il me semble. Et je suis sûr de ne pas avoir eu besoin de proxy arp mais peut-être pour certaines utilisations...
Si le serveur SSH ne fait pas de masquerading de l'adresse IP du client, la passerelle du LAN du serveur verra les paquets "aller" partant vers l'extérieur avec l'adresse IP source du client, et non l'adresse IP du serveur. Et il cherchera a envoyer les paquets "retour" reçus de l'extérieur à cette même adresse. Il y a deux conditions à ce que l'envoi réussisse : - la passerelle doit avoir une route vers l'adresse du client, ce qui est implcitement le cas si cette adresse appartient au sous-réseau du LAN ; - la passerelle doit retrouver l'adresse MAC correspondante grâce à une requête ARP. Le client n'étant pas directement sur le LAN, il ne peut répondre aux requêtes ARP. Le serveur doit donc le faire à sa place, et c'est l'objet de l'option proxy_arp du noyau.
Alternative : créer sur la passerelle une route vers l'adresse du client ayant pour passerelle l'adresse du serveur. Ainsi on fait d'une pierre deux coups.