Re: Configuration de socks et iptables
Le mercredi 27 septembre 2006 à 21:17 +0200, Pascal Hambourg a écrit : Pascal Hambourg a écrit : [des trucs qui peuvent faire peur aux âmes sensibles] Et là quelque chose me dit que David n'est plus très chaud pour se lancer dans l'option tunnel et qu'il va plutôt se concentrer sur l'option proxy. ;-) Ah, c'est pas faux ;-) Indépendamment de la partie réseau, je n'ai pas encore suffisamment d'expérience Linux à mon goût... Néanmoins, c'est très intéressant. Bon, je n'ai pas vraiment le temps d'étudier ça de près en ce moment, mais à l'occasion, j'essaierais de le faire... En tous cas, merci pour vos réponses nombreuses... David. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Configuration de socks et iptables
C'est marrant, j'ai la même impression... (voir message de David sur Dante plus loin). Moi, dans son cas, je préfère jouer avec les paquets tcpip, iptables, iproute2 et vtun plutôt que multiplier les proxy mais chacun son truc. En fait, dans mon cas précis, il me semble que la solution proxy (un seul !) est la plus simple, non ? Et puis, même si je suis d'accord sur l'aspect satisfaction que l'on peut ressentir après avoir réussi à mettre en oeuvre quelque chose de compliqué, pour la maintenance dans le temps, ce n'est pas obligatoirement l'idéal... De toutes façons, je sais bien que je devrais jouer avec iptables un jour. Si c'était la meilleure solution, je me serais lancé dedans dès aujourd'hui. Mais là, je pense qu'il y a plus simple/léger/performant ? David. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Configuration de socks et iptables
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. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration de socks et iptables
Le jeudi 28 septembre 2006 à 11:41 +0200, Pascal Hambourg a écrit : 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. Et par défaut, ça donne quoi ? Je dis ça car, en ce qui me concerne, je n'ai rien configuré du tout en dehors de mon tunnel et ça marche nickel. Ainsi, sur mon ordinateur A (réseau interne, adresse 10.*.*.*), je me connecte en SSH (via un proxy) sur mon serveur B (également réseau interne, adresse 192.168.*.*). Bon, bien évidemment, il y a du NAT. Mais quand je fais ma requête POP sur mon ordinateur A, elle est envoyée dans le tunnel, passe par mon serveur B et ressort sur Internet par son intermédiaire. Et le retour suit la même voie. En effet, il n'est pas possible que le retour arrive directement sur mon ordinateur A à partir du serveur POP. David. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Configuration de socks et iptables
David BERCOT a écrit : Et par défaut, ça donne quoi ? Je dis ça car, en ce qui me concerne, je n'ai rien configuré du tout en dehors de mon tunnel et ça marche nickel. Tu parles de quoi ? De la redirection de port TCP local avec l'option -L de ssh ? Dans ce cas il n'y a pas de problème de routage puisqu'il n'y a pas de lien IP entre le client et le serveur SSH. Mais ça ne marche que si on connaît à l'avance la liste exhaustive des serveurs à atteindre. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration de socks et iptables
Le jeudi 28 septembre 2006 à 16:55 +0200, Pascal Hambourg a écrit : David BERCOT a écrit : Et par défaut, ça donne quoi ? Je dis ça car, en ce qui me concerne, je n'ai rien configuré du tout en dehors de mon tunnel et ça marche nickel. Tu parles de quoi ? De la redirection de port TCP local avec l'option -L de ssh ? Dans ce cas il n'y a pas de problème de routage puisqu'il n'y a pas de lien IP entre le client et le serveur SSH. Mais ça ne marche que si on connaît à l'avance la liste exhaustive des serveurs à atteindre. OK. C'est parce que j'ai redirigé uniquement pour le port 110 vers pop.wanadoo.fr ? Le client de la requête POP est le serveur SSH qui reçoit la réponse (logique) et la transmet à l'autre bout du tunnel ? David. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Configuration de socks et iptables
David BERCOT a écrit : Tu parles de quoi ? De la redirection de port TCP local avec l'option -L de ssh ? Dans ce cas il n'y a pas de problème de routage puisqu'il n'y a pas de lien IP entre le client et le serveur SSH. Mais ça ne marche que si on connaît à l'avance la liste exhaustive des serveurs à atteindre. OK. C'est parce que j'ai redirigé uniquement pour le port 110 vers pop.wanadoo.fr ? Le client de la requête POP est le serveur SSH qui reçoit la réponse (logique) et la transmet à l'autre bout du tunnel ? Oui et non. Le client de la *connexion* TCP sur le port 110 du serveur POP3 est le serveur SSH. L'émetteur des *requêtes* POP3 (LIST, RETR, DELE...) reste l'hôte qui se connecte au port 110 du client, le tunnel SSH faisant le relais entre les deux. Note que si tu connais à l'avance la liste de tous les serveurs et ports auxquels tu as besoin de te connecter, les redirections de ports de SSH associées à des règles iptables DNAT peuvent suffire. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Configuration de socks et iptables [Was Re: Tunnel SSH et redirection générique pour un port...]
Bon, je continue à réfléchir sur le sujet (je ne vais quand même pas attendre que ça m'arrive tout cuit ;-))) et, finalement, j'ai l'impression qu'un serveur socks installé sur mon serveur SERV_PRIV devrait faire l'affaire, non ? Ensuite, pour les applis qui peuvent utiliser un serveur proxy, je les redirige vers le serveur socks et, pour celles qui ne peuvent pas (genre Evolution ?), il doit suffire de rajouter des règles iptables du genre : demande vers pop.wanadoo.fr sur port 110 doit passer par serveur socks. Est-ce que ça vous semble jouable ? Maintenant, socks étant un terme générique, j'admets que je n'ai rien trouvé de satisfaisant en terme d'exemple... Auriez-vous un lien ou deux ? De la même manière, ne pratiquant pas du tout iptables, auriez-vous un exemple ou un lien pour ce que je dois faire ? Merci d'avance. David. Le mercredi 27 septembre 2006 à 10:15 +0200, David BERCOT a écrit : Bonjour, Le mardi 26 septembre 2006 à 21:00 +0200, Paul Filo a écrit : En tous cas, sachant que la sécurité du tunnel SSH me convient, si j'avais un moyen (proxy ?) de pouvoir y faire transiter le trafic que je souhaite (une sélection uniquement !), ça me conviendrait parfaitement... Merci d'avance pour les indices que vous pourrez me donner ;-) Tu as essayé vtun (http://vtun.sourceforge.net/) ? Tu fais un tunnel vtun dans ton tunnel ssh et avec les bonnes routes coté client, tu dois pouvoir t'en tirer (ce que tu veux faire n'est pas très clair). J'ai trouvé quelques exemples sur vtun, mais toujours avec 3 réseaux reliés ensemble et j'ai du mal à adapter tout ça à mes besoins... Je vais donc essayer d'expliquer plus clairement mon problème... J'ai un ordinateur A, connecté à Internet. J'ai un réseau privé R, dont un serveur SERV_PRIV est connecté à Internet et accessible via SSH. J'arrive donc à faire un tunnel SSH entre ma machine A et mon serveur SERV_PRIV, sauf que, dans la définition du tunnel, je dois préciser l'adresse Internet à laquelle je veux me connecter via le tunnel. Exemple : ssh -N -f SERV_PRIV -L110:pop.wanadoo.fr:110 Ceci me limite donc, pour le port 110 par exemple, à un seul serveur accessible via le tunnel (ici, pop.wanadoo.fr). Or, mon besoin est le suivant : - création d'un tunnel SSH entre A et SERV_PRIV - ajout de routes spéciales sur certains ports pour que les requêtes correspondantes passent par SERV_PRIV et ensuite par le réseau R A titre d'exemple, ainsi, si je fais une requête sur le port 110, par exemple sur pop.wanadoo.fr, mais aussi sur pop.free.fr, je souhaiterais que ces deux requêtes passent par mon tunnel puis par le réseau R. Déjà, comme lors de la création de mon tunnel, je précise le serveur distant (pop.wanadoo.fr dans l'exemple), j'ai un peu de mal à voir comment modifier tout ça. Avec les réponses que vous m'avez données, j'imagine bien une sorte de serveur proxy sur mon serveur SERV_PRIV qui redirigerait les requêtes qui lui arrivent sur les réseau R (comme il le fait actuellement vers pop.wanadoo.fr). Dans ce cas, j'établirais, sur mon ordinateur A, un tunnel avec une syntaxe du genre : ssh -N -f SERV_PRIV -L5000:proxy_serv_priv:5000 Mais alors, que puis-je mettre comme serveur proxy ? Et ensuite, comment dire à une requête de passer par ce serveur proxy (par exemple, dans Evolution, comment lui dire que mon serveur POP est pop.wanadoo.fr via proxy_serv_priv ? J'espère avoir été un peu plus clair dans mes explications... Merci d'avance. David. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Configuration de socks et iptables
Salut, David BERCOT a écrit : Bon, je continue à réfléchir sur le sujet (je ne vais quand même pas attendre que ça m'arrive tout cuit ;-))) et, finalement, j'ai l'impression qu'un serveur socks installé sur mon serveur SERV_PRIV devrait faire l'affaire, non ? Oui, c'est une possibilité à condition que les logiciels clients supportent SOCKS. Ensuite, pour les applis qui peuvent utiliser un serveur proxy, je les redirige vers le serveur socks et, pour celles qui ne peuvent pas (genre Evolution ?), il doit suffire de rajouter des règles iptables du genre : demande vers pop.wanadoo.fr sur port 110 doit passer par serveur socks. Non, ça ne marche pas comme ça. Un proxy SOCKS utilise un protocole spécifique, on ne peut pas lui balancer directement du POP3. Ce serait comme essayer de parler directement en FTP à un proxy HTTP comme squid. Il existe toutefois la possibilité de socksifier un client pour rediriger ses connexions vers un proxy SOCKS. Maintenant, socks étant un terme générique, j'admets que je n'ai rien trouvé de satisfaisant en terme d'exemple... Auriez-vous un lien ou deux ? Cf. hpsockd, dante-server, dante-client. Une autre voie que le proxy consisterait à créer un véritable tunnel IP entre le client et le serveur. Si SSH est le seul moyen de communication entre les deux, il est possible de monter sur la connexion SSH une session PPP avec pppd au lieu d'un shell. Il y a peut-être moyen de monter un autre type de tunnel IP dans un tunnel TCP sur SSH, mais je n'ai pas de nom en tête. Dans les deux cas tu auras un vrai réseau avec des interfaces et du routage, du NAT, etc... mais les performances peuvent être médiocres car SSH est basé sur TCP, et TCP n'est pas adapté au transport d'une couche IP. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration de socks et iptables
Une autre voie que le proxy consisterait à créer un véritable tunnel IP entre le client et le serveur. Si SSH est le seul moyen de communication entre les deux, il est possible de monter sur la connexion SSH une session PPP avec pppd au lieu d'un shell. Il y a peut-être moyen de monter un autre type de tunnel IP dans un tunnel TCP sur SSH, mais je n'ai pas de nom en tête. Dans les deux cas tu auras un vrai réseau avec des interfaces et du routage, du NAT, etc... mais les performances peuvent être médiocres car SSH est basé sur TCP, et TCP n'est pas adapté au transport d'une couche IP. Je suis d'accord. C'est la voie que j'indiquais en faisant un tunnel avec vtun et qui fonctionne correctement si on n'est pas trop exigeant sur le débit. 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 4) tu ajoutes une route pour router tous les paquets à destination du port 110 pat cette interface. 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) Il me semble que c'est le plus proche de ce que tu veux faire. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration de socks et iptables
Pascal Hambourg a écrit : [des trucs qui peuvent faire peur aux âmes sensibles] Et là quelque chose me dit que David n'est plus très chaud pour se lancer dans l'option tunnel et qu'il va plutôt se concentrer sur l'option proxy. ;-) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration de socks et iptables
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.
Tu as raison : il y a une interface tun de chaque coté. Je voulais dire
que si ton réseau local est en 192.168.1.0/24, tu peux prendre 2
adresses dans cette plage pour le tunnel une coté serveur, l'autre coté
client. Ca évite de rajouter encore d'autres règles de routage coté serveur.
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 !
Effectivement... mais quelle joie quand ça marche... En fait, quand j'ai
testé ça, je filtrai sur l'adresse source et là c'est plus simple car ip
rule le fait directement.
{...]
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...
Et là quelque chose me dit que David n'est plus très chaud pour se
lancer dans l'option tunnel et qu'il va plutôt se concentrer sur
l'option proxy. ;-)
C'est marrant, j'ai la même impression... (voir message de David sur
Dante plus loin). Moi, dans son cas, je préfère jouer avec les paquets
tcpip, iptables, iproute2 et vtun plutôt que multiplier les proxy mais
chacun son truc.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
