Re: Configuration de socks et iptables
Paul Filo a écrit :
1) tu fais tourner un serveur vtun sur SERV_PRIV
2) tu fais un tunnel ssh sur le port vtun (par exemple 5000) entre A et
SERV_PRIV avec ssh -L 5000:localhost:5000 SERV_PRIV (voir
http://vtun.sourceforge.net/faq.html#1.23)
3) tu lances ton client vtun sur machine A. Tu vas avoir une nouvelle
interface tun0 avec une adresse ip dans la plage de ton réseau local
Tu veux dire dans le réseau local du serveur SSH ?
Note : le serveur aura aussi une nouvelle interface tunX à l'autre bout
du tunnel.
4) tu ajoutes une route pour router tous les paquets à destination du
port 110 pat cette interface.
Euh, ce n'est pas si simple. On ne peut pas directement router en
fonction du port destination. Il va falloir marquer les paquets sortants
avec une règle iptables MARK et faire du routage avancé avec une règle
de routage (ip rule) basée sur la marque définie qui aiguille le routage
vers une table de routage alternative contenant une route par défaut
passant par le tunnel. Du classique. Sans oublier le cas écheant de
désactiver rp_filter sur l'interface tunnel sinon les paquets de réponse
se feront jeter au retour. Ouf !
Une alternative consiste à gravement truander la table de routage
normale du client :
- créer une route vers le serveur SSH pour remplacer la route par
défaut, afin de maintenir le tunnel ;
- supprimer la route par défaut ;
- créer une route par défaut passant par l'interface tunnel.
Ainsi tout ce qui n'est pas destiné au LAN du client ou au serveur part
dans le tunnel. C'est le principe des VPN sous Windows quand on coche
l'option "route par défaut". A la fermeture du tunnel, ne pas oublier de
restaurer la route par défaut normale. Ou bien jouer sur les métriques
pour ne pas avoir à la supprimer.
Comme ça tout le trafic pop de ta machine A sera routé par vtun vers
SERV_PRIV puis vers pop.wanadoo.fr et compagnie (ton serveur est bien
sur configuré pour forwarder/masquerader les paquets entrants par vtun)
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.
Reply to: