>> 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 !
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.
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. ;-)
>> 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 !
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.
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. ;-)
>> 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 !
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.
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. ;-)
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. ;-)
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. ;-)
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. ;-)
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 ma is
chacun son truc.
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 ma is
chacun son truc.
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 ma is
chacun son truc.
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...
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...
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...
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 - qu e la
>>passerelle du serveur sait joindre, par exemple dans le sous-résea u du
>>LAN du serveur, et d'autre part le proxy_arp est activé sur le ser veur.
>>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 d u 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 n e 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 cl ient
ayant pour passerelle l'adresse du serveur. Ainsi on fait d'une pierre
deux coups.
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 - qu e la
>>passerelle du serveur sait joindre, par exemple dans le sous-résea u du
>>LAN du serveur, et d'autre part le proxy_arp est activé sur le ser veur.
>>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 d u 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 n e 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 cl ient
ayant pour passerelle l'adresse du serveur. Ainsi on fait d'une pierre
deux coups.
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 - qu e la
>>passerelle du serveur sait joindre, par exemple dans le sous-résea u du
>>LAN du serveur, et d'autre part le proxy_arp est activé sur le ser veur.
>>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 d u 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 n e 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 cl ient
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.
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.
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.
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.
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.
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.
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 ?
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 ?
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 ?