Re: iptables et openvpn
Tekpi a écrit :
ipconfig : Carte Ethernet Connexion au réseau local:
[...]
ifconfig :
[...]
Merci, ça confirme mes déductions. Rien à signaler à part br0 et eth1
dans le même sous-réseau, comme je l'ai déjà dit.
Ah, forcément si tu configures le même sous-réseau IP 192.168.3.0/24 sur
deux interfaces reliées à des réseaux différents, ça va beaucoup moins
bien marcher comme dirait l'autre.
Figures toi que j'ai demandé conseil sur ce forum en développant ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait faire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
J'avais déjà oubliée cette discussion...
Sauf erreur, personne ici ne t'a dit qu'il fallait faire du VPN ponté,
c'est toi qui l'as choisi, et encore moins que les interfaces WAN et LAN
devaient être "les mêmes".
J'avais répondu ceci :
=======================================================================
l'interface eth0 et eth1 de mon serveur linux doivent-elles impérativement
être sur le même réseau?
Car actuellement, j'ai configuré mon eth0 en 192.168.5.0/24 et eth1
192.168.1.0/24.
En gros, le schéma :
Client winxp <------> VPN <-----------> eth0 linux eth1 <------------> Lan
eth0, c'est quoi ? L'interface WAN vers internet ?
Si pontage : l'interface LAN, eth1, doit être pontée avec l'interface
VPN, tapX. Elles sont de fait sur le même réseau, comme les ports d'un
switch. Elles deviennent les ports d'un switch virtuel constitué par le
pont. D'autre part dans la configuration de la machine l'interface pont
(br0) doit remplacer eth1. Ce n'est plus eth1 mais br0 qui a la
configuration IP, les routes associées, qui est utilisée par le serveur
DHCP le cas échéant, etc. Au niveau réseau, eth1 et tapX seront aussi
invisibles que les ports d'un switch.
=======================================================================
Il n'était pas fait mention de l'interface WAN dans ma réponse. On peut
éventuellement la mettre dans le pont (et supprimer la fonction routeur
du serveur), mais en aucun cas dans le même sous-réseau.
Explication :
si l'interface WAN est dans le pont, elle n'est plus une interface
individuelle et n'a plus d'adresse IP ni de sous-réseau ; le serveur se
comporte come un switch à 3 ports WAN-LAN-VPN, il n'y a plus qu'un seul
réseau.
Si l'interface WAN n'est pas dans le pont, elle a son propre sous-réseau
IP distinct de celui du pont-LAN ; le serveur se comporte comme un
switch entre LAN et VPN et comme un routeur entre WAN et (LAN+VPN).
En bref, seules les interfaces individuelles et les ponts ont des
adresses IP et des sous-réseaux (distincts). Les interfaces pontées
disparaissent.
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennent.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me parait
bizarre, c'est que cela fonctionne si j'ouvre complètement mon script
iptables...
S'il n'est pas trop long ou confidentiel tu peux le publier, qu'on jette
un oeil.
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1
Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-réseau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là. Poussée par le serveur VPN ? En tout cas je pense que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une priorité
supérieure) à la route directe juste au dessus.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda.
J'ai supprimé cette option car je pensais qu'elle pouvait être la source du
pb, sans résultat.
Et si tu supprimes les options physdev des règles iptables que tu avais
indiquées, pour voir ?
Ce qui est franchement étrange, c'est que je peux, via mon poste lambda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Rien d'étrange là-dedans. Tu n'accèdes pas à la patte LAN du serveur
mais à l'adresse de sa patte LAN, sur sa patte VPN. La nuance est de
taille. C'est géré dans les chaînes iptables INPUT et OUTPUT, et non
dans la chaîne FORWARD.
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
Je ne sais pas pourquoi ni qui t'a dit ça, mais ce n'était pas ici dans
la discussion "VPN client Windows -> Serveur Debian".
Autant il peut être intéressant de ponter le VPN avec le LAN
(broadcasts, protocoles non IP) autant ça n'a guère d'intérêt de ponter
le LAN (ou le VPN) avec le WAN. Ce n'est d'ailleurs pas toujours
possible, par exemple lorsque le WAN n'est pas un réseau ethernet mais
un lien PPP.
Reply to: