J'ai créer un vpn entre deux ordinateur grace à openvpn.
Le serveur vpn se situe derriere une livebox qui sert de routeur:
addresse du routeur:192.168.1.1
addresse du serveur vpn:192.168.1.16
Le client vpn se connecte au serveur sans probleme.
J'ai donc une interface tun0 des deux cotés avec le serveur en 10.8.0.1
et le client en 10.8.0.2.
Le probleme se pose lorsque le client veux voir les ordinateur du lan du
serveur, en effet le client se situe également sur un réseaux avec la meme
numérotation(en fait il est lui aussi derriere une livebox en 192.168.1.1).
Existe t'il une solution simple, ou suis je obliger de changer l'un des deux
réseaux.
Et oui, Oh joie du routage, les paquets qui arrivent sur les machines du LAN repartent vers la livebox, qui connaît maintenant ton réseau distant et peut les renvoyer vers le tunnel VPN :-)
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient compte et modifie sa table de routage pour que les paquets suivants partent directement vers le serveur VPN. :-)
Et oui, Oh joie du routage, les paquets qui arrivent sur les machines
du LAN repartent vers la livebox, qui connaît maintenant ton réseau
distant et peut les renvoyer vers le tunnel VPN :-)
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à
l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient
compte et modifie sa table de routage pour que les paquets suivants
partent directement vers le serveur VPN. :-)
Et oui, Oh joie du routage, les paquets qui arrivent sur les machines du LAN repartent vers la livebox, qui connaît maintenant ton réseau distant et peut les renvoyer vers le tunnel VPN :-)
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient compte et modifie sa table de routage pour que les paquets suivants partent directement vers le serveur VPN. :-)
Patrick Mevzek
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient compte
Pas forcément. Les ICMPs redirects sont souvent filtrés, ils peuvent être dangereux (détournement de trafic).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à
l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient
compte
Pas forcément. Les ICMPs redirects sont souvent filtrés, ils peuvent
être dangereux (détournement de trafic).
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient compte
Pas forcément. Les ICMPs redirects sont souvent filtrés, ils peuvent être dangereux (détournement de trafic).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Eric Masson
Patrick Mevzek writes:
'Lut,
Pas forcément. Les ICMPs redirects sont souvent filtrés, ils peuvent être dangereux (détournement de trafic).
M'est avis que sur un lan perso, le principal problème de sécurité est situé entre le clavier et la chaise.
Le filtrage icmp par défaut d'XP est amha symptomatique d'un grand n'importe quoi, d'un coté filtrage d'options réseau intéressantes, de l'autre compte utilisateur permettant de faire n'importe quelle connerie par défaut, belle cohérence...
-- De toute façon, Netscape est tellement bourré de trous de sécurité que y'a même pas besoin qu'ils envoient les infos...n'importe qui peut aller les chercher sur le disque dur ;) + LM in Guide du Macounet Pervers : Netscape, une société transparente +
Patrick Mevzek <pm-N200609@nospam.dotandco.com> writes:
'Lut,
Pas forcément. Les ICMPs redirects sont souvent filtrés, ils peuvent
être dangereux (détournement de trafic).
M'est avis que sur un lan perso, le principal problème de sécurité est
situé entre le clavier et la chaise.
Le filtrage icmp par défaut d'XP est amha symptomatique d'un grand
n'importe quoi, d'un coté filtrage d'options réseau intéressantes, de
l'autre compte utilisateur permettant de faire n'importe quelle connerie
par défaut, belle cohérence...
--
De toute façon, Netscape est tellement bourré de trous de sécurité que
y'a même pas besoin qu'ils envoient les infos...n'importe qui peut aller
les chercher sur le disque dur ;)
+ LM in Guide du Macounet Pervers : Netscape, une société transparente +
Pas forcément. Les ICMPs redirects sont souvent filtrés, ils peuvent être dangereux (détournement de trafic).
M'est avis que sur un lan perso, le principal problème de sécurité est situé entre le clavier et la chaise.
Le filtrage icmp par défaut d'XP est amha symptomatique d'un grand n'importe quoi, d'un coté filtrage d'options réseau intéressantes, de l'autre compte utilisateur permettant de faire n'importe quelle connerie par défaut, belle cohérence...
-- De toute façon, Netscape est tellement bourré de trous de sécurité que y'a même pas besoin qu'ils envoient les infos...n'importe qui peut aller les chercher sur le disque dur ;) + LM in Guide du Macounet Pervers : Netscape, une société transparente +
Nicolas Ninin
Pascal Hambourg wrote:
pour faire simple je me demandais si les ordinateurs du lan au lieu d'accéder au client avec une ip en 10.8.0.2, on ne pourrait pas donner au client une ip sur la meme plage que le lan par exemple en 192.168.2.30.
Et je répondais trop rapidement que oui. En effet, ça va poser des problèmes au client : comment va-t-il savoir si une adresse IP 192.168.2.* appartient à son LAN ou à celui du serveur ? A ta place, j'essaierais de faire du NAT 1:1 sur la passerelle si tu n'utilises pas de protocole tordu qui ne passe pas le NAT. La cible NETMAP d'iptables est pratique pour cela, mais n'est pas supportée par tous les noyaux.
J'explique quand même au cas où les deux LAN ont des sous-réseaux différents.
Tu peux attribuer à l'interface VPN du serveur la même adresse que son interface LAN (mais avec masque /32), et à l'interface VPN du client une adresse inutilisée dans le LAN du serveur.
C'était bien ca que je demandais.
Ensuite, comme ton serveur a l'air de tourner sous Linux, tu actives le proxy ARP :
sysctl -w net/ipv4/conf/<interface>/proxy_arp=1
où <interface> désigne le nom de l'interface réseau du LAN, je crois, à moins que ce soit l'interface du VPN, je n'ai jamais su. Dans le doute, tu peut mettre "all" pour activer le proxy ARP sur toutes les interfaces.
Raison : les machines du LAN vont rechercher l'adresse VPN du client et faire des requêtes ARP sur le LAN, alors que le client est à l'autre bout du VPN. Le trafic ARP n'étant pas routé, ce n'est pas lui qui risque d'y répondre. Il faut donc demander au serveur VPN de le faire à sa place.
Pourquoi, d'ailleur, l'ARP n'est il pas routé?
PS : pas besoin de copie par mail privé. Désolé, simple erreur de manipulation.
Pascal Hambourg wrote:
pour faire simple je me
demandais si les ordinateurs du lan au lieu d'accéder au client avec une
ip en 10.8.0.2, on ne pourrait pas donner au client une ip sur la meme
plage que le lan par exemple en 192.168.2.30.
Et je répondais trop rapidement que oui. En effet, ça va poser des
problèmes au client : comment va-t-il savoir si une adresse IP
192.168.2.* appartient à son LAN ou à celui du serveur ? A ta place,
j'essaierais de faire du NAT 1:1 sur la passerelle si tu n'utilises pas
de protocole tordu qui ne passe pas le NAT. La cible NETMAP d'iptables
est pratique pour cela, mais n'est pas supportée par tous les noyaux.
J'explique quand même au cas où les deux LAN ont des sous-réseaux
différents.
Tu peux attribuer à l'interface VPN du serveur la même adresse que son
interface LAN (mais avec masque /32), et à l'interface VPN du client une
adresse inutilisée dans le LAN du serveur.
C'était bien ca que je demandais.
Ensuite, comme ton serveur a
l'air de tourner sous Linux, tu actives le proxy ARP :
sysctl -w net/ipv4/conf/<interface>/proxy_arp=1
où <interface> désigne le nom de l'interface réseau du LAN, je crois, à
moins que ce soit l'interface du VPN, je n'ai jamais su. Dans le doute,
tu peut mettre "all" pour activer le proxy ARP sur toutes les interfaces.
Raison : les machines du LAN vont rechercher l'adresse VPN du client et
faire des requêtes ARP sur le LAN, alors que le client est à l'autre
bout du VPN. Le trafic ARP n'étant pas routé, ce n'est pas lui qui
risque d'y répondre. Il faut donc demander au serveur VPN de le faire à
sa place.
Pourquoi, d'ailleur, l'ARP n'est il pas routé?
PS : pas besoin de copie par mail privé.
Désolé, simple erreur de manipulation.
pour faire simple je me demandais si les ordinateurs du lan au lieu d'accéder au client avec une ip en 10.8.0.2, on ne pourrait pas donner au client une ip sur la meme plage que le lan par exemple en 192.168.2.30.
Et je répondais trop rapidement que oui. En effet, ça va poser des problèmes au client : comment va-t-il savoir si une adresse IP 192.168.2.* appartient à son LAN ou à celui du serveur ? A ta place, j'essaierais de faire du NAT 1:1 sur la passerelle si tu n'utilises pas de protocole tordu qui ne passe pas le NAT. La cible NETMAP d'iptables est pratique pour cela, mais n'est pas supportée par tous les noyaux.
J'explique quand même au cas où les deux LAN ont des sous-réseaux différents.
Tu peux attribuer à l'interface VPN du serveur la même adresse que son interface LAN (mais avec masque /32), et à l'interface VPN du client une adresse inutilisée dans le LAN du serveur.
C'était bien ca que je demandais.
Ensuite, comme ton serveur a l'air de tourner sous Linux, tu actives le proxy ARP :
sysctl -w net/ipv4/conf/<interface>/proxy_arp=1
où <interface> désigne le nom de l'interface réseau du LAN, je crois, à moins que ce soit l'interface du VPN, je n'ai jamais su. Dans le doute, tu peut mettre "all" pour activer le proxy ARP sur toutes les interfaces.
Raison : les machines du LAN vont rechercher l'adresse VPN du client et faire des requêtes ARP sur le LAN, alors que le client est à l'autre bout du VPN. Le trafic ARP n'étant pas routé, ce n'est pas lui qui risque d'y répondre. Il faut donc demander au serveur VPN de le faire à sa place.
Pourquoi, d'ailleur, l'ARP n'est il pas routé?
PS : pas besoin de copie par mail privé. Désolé, simple erreur de manipulation.
Pascal Hambourg
Pourquoi, d'ailleur, l'ARP n'est il pas routé?
Parce que d'une part ARP n'est pas un protocole IP, et d'autre part son utilité est limitée au lien local, comme les adresses MAC qu'il a pour fonction de transmettre. Il n'y a donc aucune raison de router ARP vers d'autres réseaux.
On peut noter que le remplaçant d'ARP pour la résolution des adresses IPv6, bien que basé sur IPv6, utilise des adresses IPv6 dites "lien local" non routables, il est donc nor routable comme ARP.
Pourquoi, d'ailleur, l'ARP n'est il pas routé?
Parce que d'une part ARP n'est pas un protocole IP, et d'autre part son
utilité est limitée au lien local, comme les adresses MAC qu'il a pour
fonction de transmettre. Il n'y a donc aucune raison de router ARP vers
d'autres réseaux.
On peut noter que le remplaçant d'ARP pour la résolution des adresses
IPv6, bien que basé sur IPv6, utilise des adresses IPv6 dites "lien
local" non routables, il est donc nor routable comme ARP.
Parce que d'une part ARP n'est pas un protocole IP, et d'autre part son utilité est limitée au lien local, comme les adresses MAC qu'il a pour fonction de transmettre. Il n'y a donc aucune raison de router ARP vers d'autres réseaux.
On peut noter que le remplaçant d'ARP pour la résolution des adresses IPv6, bien que basé sur IPv6, utilise des adresses IPv6 dites "lien local" non routables, il est donc nor routable comme ARP.
Eric Lalitte
"Pascal Hambourg" wrote in message news:edpkl7$1ho1$
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient compte et modifie sa table de routage pour que les paquets suivants partent directement vers le serveur VPN. :-)
Ah bah oui mais non. Ca c'était vrai avant, mais aujourd'hui la plupart des systèmes ignorent les redirects pour des raisons de sécurité, et par la même occasion, beaucoup de systèmes n'envoient plus de redirects et routent les paquets sans se soucier d'un rebond sur une interface. Après on peut bloquer les rebonds au niveau du firewall si on le souhaite.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> wrote in message
news:edpkl7$1ho1$2@biggoron.nerim.net
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à
l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient
compte et modifie sa table de routage pour que les paquets suivants
partent directement vers le serveur VPN. :-)
Ah bah oui mais non.
Ca c'était vrai avant, mais aujourd'hui la plupart des systèmes ignorent
les redirects pour des raisons de sécurité, et par la même occasion,
beaucoup de systèmes n'envoient plus de redirects et routent les paquets
sans se soucier d'un rebond sur une interface. Après on peut bloquer les
rebonds au niveau du firewall si on le souhaite.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pascal Hambourg" wrote in message news:edpkl7$1ho1$
Si la Livebox n'est pas trop conne, elle envoie un ICMP Redirect à l'émetteur du paquet, et si celui-ci n'est pas trop con, il en tient compte et modifie sa table de routage pour que les paquets suivants partent directement vers le serveur VPN. :-)
Ah bah oui mais non. Ca c'était vrai avant, mais aujourd'hui la plupart des systèmes ignorent les redirects pour des raisons de sécurité, et par la même occasion, beaucoup de systèmes n'envoient plus de redirects et routent les paquets sans se soucier d'un rebond sur une interface. Après on peut bloquer les rebonds au niveau du firewall si on le souhaite.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Eric Lalitte
"Eric Masson" wrote in message news:
M'est avis que sur un lan perso, le principal problème de sécurité est situé entre le clavier et la chaise.
Le filtrage icmp par défaut d'XP est amha symptomatique d'un grand n'importe quoi, d'un coté filtrage d'options réseau intéressantes, de l'autre compte utilisateur permettant de faire n'importe quelle connerie par défaut, belle cohérence...
Je pense que Patrick parlait de la non prise en compte des redirects par les systèmes pour des raisons de sécurité, qu'on peut assimiler à du filtrage. il n'y a pas de filtrage ICMP complet par défaut il me semble. L'impact n'est pas bien méchant au point de vue réseau et on se protège d'une attaque triviale.
Et même si on obtient le même résultat avec du arp cache poisonning, la mise en oeuvre un est un poil plus compliquée.
<agree 100%> "le principal problème de sécurité est situé entre le clavier et la chaise" </agree> Par contre sur un LAN, on a intérêt à mettre en oeuvre des règles strictes parceque les attaques sont d'autant plus puissantes (je dis peut-être cela parceque je bosse dans une école :-) mais bon...)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Eric Masson" <emss@free.fr> wrote in message
news:hu36t3-nfv.ln1@srvbsdnanssv.oursoides-associes.com
M'est avis que sur un lan perso, le principal problème de sécurité est
situé entre le clavier et la chaise.
Le filtrage icmp par défaut d'XP est amha symptomatique d'un grand
n'importe quoi, d'un coté filtrage d'options réseau intéressantes, de
l'autre compte utilisateur permettant de faire n'importe quelle connerie
par défaut, belle cohérence...
Je pense que Patrick parlait de la non prise en compte des redirects par
les systèmes pour des raisons de sécurité, qu'on peut assimiler à du
filtrage. il n'y a pas de filtrage ICMP complet par défaut il me
semble.
L'impact n'est pas bien méchant au point de vue réseau et on se protège
d'une attaque triviale.
Et même si on obtient le même résultat avec du arp cache poisonning, la
mise en oeuvre un est un poil plus compliquée.
<agree 100%>
"le principal problème de sécurité est situé entre le clavier et la
chaise"
</agree>
Par contre sur un LAN, on a intérêt à mettre en oeuvre des règles
strictes parceque les attaques sont d'autant plus puissantes (je dis
peut-être cela parceque je bosse dans une école :-) mais bon...)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
M'est avis que sur un lan perso, le principal problème de sécurité est situé entre le clavier et la chaise.
Le filtrage icmp par défaut d'XP est amha symptomatique d'un grand n'importe quoi, d'un coté filtrage d'options réseau intéressantes, de l'autre compte utilisateur permettant de faire n'importe quelle connerie par défaut, belle cohérence...
Je pense que Patrick parlait de la non prise en compte des redirects par les systèmes pour des raisons de sécurité, qu'on peut assimiler à du filtrage. il n'y a pas de filtrage ICMP complet par défaut il me semble. L'impact n'est pas bien méchant au point de vue réseau et on se protège d'une attaque triviale.
Et même si on obtient le même résultat avec du arp cache poisonning, la mise en oeuvre un est un poil plus compliquée.
<agree 100%> "le principal problème de sécurité est situé entre le clavier et la chaise" </agree> Par contre sur un LAN, on a intérêt à mettre en oeuvre des règles strictes parceque les attaques sont d'autant plus puissantes (je dis peut-être cela parceque je bosse dans une école :-) mais bon...)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Pascal Hambourg
Par contre sur un LAN, on a intérêt à mettre en oeuvre des règles strictes parceque les attaques sont d'autant plus puissantes (je dis peut-être cela parceque je bosse dans une école :-) mais bon...)
Ça dépend du LAN et de ce qu'il y a dessus. Chez moi, je ne filtre rien.
Par contre sur un LAN, on a intérêt à mettre en oeuvre des règles
strictes parceque les attaques sont d'autant plus puissantes (je dis
peut-être cela parceque je bosse dans une école :-) mais bon...)
Ça dépend du LAN et de ce qu'il y a dessus. Chez moi, je ne filtre rien.
Par contre sur un LAN, on a intérêt à mettre en oeuvre des règles strictes parceque les attaques sont d'autant plus puissantes (je dis peut-être cela parceque je bosse dans une école :-) mais bon...)
Ça dépend du LAN et de ce qu'il y a dessus. Chez moi, je ne filtre rien.
