Iptables/Netfilter problème avec les hooks (décision routage erronée) - réseaux et sécurité - Linux et OS Alternatifs
Marsh Posté le 16-08-2005 à 21:20:05
J'ai d'autres exemples en tête:
-Terminal Server sur un poste du reseau local => nickel
-Ping vers un poste du reseau local => nickel
-Ouverture d'une session VNC sur un poste => nickel mais le flux de données est bloqué après
J'ai aucune règles pour ces trois services dans mes chaînes INPUT/OUTPUT pourtant (donc DROP).
Comment expliquer cette erreur de routage ?
Ou est-ce moi qui est à coté de quelque chose ?
Marsh Posté le 20-08-2005 à 10:49:56
clockover a écrit : Voila j'ai un serveur VPN avec les règles iptables suivantes (extrait j'ai jsute mis ce qui nous interresse): |
Pour le reste, sois plus clair, je comprends pas tout
Plus de détails, et clairs, stp
Marsh Posté le 20-08-2005 à 12:21:54
Donc déjà le réseau:
Portable (1) -------Internet------ Routeur\Switch ------ Serveur-VPN (2)
|
------ Reseau Local (3)
Donc je me branche en VPN sur le reseau grace à Serveur-VPN (2).
Une fois branché, je peux accèder à tous les services disponibles sur Serveur-VPN (2) c'est-à-dire SSH, Webmin, IPP, DNS ....
Maintenant avec le portable (1) (toujours en VPN bien sûr), j'essaye de pinger une machine en (3) => ok pas de problème
Je peux également ouvrir une session SSH sans problème.
Par contre si j'essaye d'ouvrir une session SSH sur un ordinateur de (3) toujours, impossible ! Je reçois bien le certificat et tout mais rien ne s'affiche et en suivant l'état du pare-feu (iptables -L -v) je vois très bien que mes paquets ont été bloqué sur la chaîne OUTPUT.
Et si j'ouvre cette fameuse chaîne, je peux alors ouvrir mon Webmin sur un ordinateur de (3) sans problème !
Et toujours en suivant mon flux de données avec iptable -L -v, je vois bien ma transaction s'acheminer à travers la chaine forward !
Pourquoi ma chaien OUTPUT bloque-t-elle certaines de mes transactions ?
Cela devrait unquiement passer par la chaîne FORWARD vu que les paquets ne sont pas destiné au serveur VPN lui-même, non ?
Les règles en entier:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- localhost.localdomain localhost.localdomain
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:ssh
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:10000
ACCEPT udp -- localnet/24 Serveur-VPN udp dpt:netbios-ns
ACCEPT udp -- localnet/24 Serveur-VPN udp dpt:netbios-dgm
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:netbios-ssn
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:microsoft-ds
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:ipp
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:12411
ACCEPT tcp -- localnet/24 Serveur-VPN tcp dpt:ftp
ACCEPT tcp -- localnet/24 Serveur-VPN state RELATED,ESTABLISHED tcp dpts:30000:30999
ACCEPT udp -- localnet/24 Serveur-VPN udp dpt: domain
ACCEPT tcp -- anywhere Serveur-VPN tcp dpt:1723
ACCEPT gre -- anywhere Serveur-VPN
ACCEPT tcp -- anywhere Serveur-VPN state ESTABLISHED tcp spt:www
ACCEPT udp -- anywhere Serveur-VPN state ESTABLISHED udp spt: domain
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- localnet/24 localnet/24
ACCEPT all -- localnet/24 localnet/24
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- localhost.localdomain localhost.localdomain
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:ssh
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:10000
ACCEPT udp -- Serveur-VPN localnet/24 udp spt:netbios-ns
ACCEPT udp -- Serveur-VPN localnet/24 udp spt:netbios-dgm
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:netbios-ssn
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:microsoft-ds
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:ipp
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:12411
ACCEPT tcp -- Serveur-VPN localnet/24 tcp spt:ftp
ACCEPT tcp -- Serveur-VPN localnet/24 state RELATED,ESTABLISHED tcp spts:30000:30999
ACCEPT udp -- Serveur-VPN localnet/24 udp spt: domain
ACCEPT tcp -- Serveur-VPN anywhere tcp spt:1723
ACCEPT gre -- Serveur-VPN anywhere
ACCEPT tcp -- Serveur-VPN anywhere state NEW,ESTABLISHED tcp dpt:www
ACCEPT udp -- Serveur-VPN anywhere state NEW,ESTABLISHED udp dpt: domain
Pour conclure:
-SSH/ Ping passe de (1) à (3) via une connxeion VPN sur (2)
-Https/ Http ne passe pas.
Alors que tout devrait passer vu que:
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- localnet/24 localnet/24
ACCEPT all -- localnet/24 localnet/24
Marsh Posté le 20-08-2005 à 14:02:27
J'ai besoin de qq infos supplémentaires là ...
décris moi la connexion VPN dans ses moindres détails, stp ...
Marsh Posté le 20-08-2005 à 14:50:01
poptop
pptp-options
Code :
|
voila
Marsh Posté le 20-08-2005 à 15:28:21
clockover a écrit : poptop
|
Concrètement, il créé une "nouvelle interface" sur la machine Linux/serveur VPN ?
Et côté client, à l'autre bout du VPN, c'est vu comment ? une nouvelle interface aussi ? avec une adresse IP d'un côté et de l'autre du VPN ?
Marsh Posté le 20-08-2005 à 19:30:26
Oui il créé une interface virtuelle de type ppp* (uen par connexion)
Ben coté client une nouvelel interface aussi. Et le client obtient une IP du reseau local avec comme passerelle le serveur VPN .
Marsh Posté le 21-08-2005 à 14:19:01
clockover a écrit : |
Ton tunnel VPN est établi entre ton client et ton serveur, donc ces paquets devraient etre vus par les règles INPUT et OUTPUT. Parce que s'ils ne peuvent pas atteindre les processus locaux, comment peuvent-ils etre déchiffrés ?
Marsh Posté le 21-08-2005 à 15:38:25
Hum bizzare sachant que je viens de tester en autorisant tout sur FORWARD et en relancant une connection VPN tout fonctionne très bien maintenant.
A mon avis le problème venait que:
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- bond0 ppp+ localnet/24 localnet/24
ACCEPT all -- ppp+ bond0 localnet/24 localnet/24
En mettant localnet, implicitement ca signifiait que le portable (1) faisait effectivement partit du reseau local!
Ca aurait dû être (car le firewall travaille avec l'ip wan du portable (1)):
ACCEPT all -- bond0 ppp+ localnet/24 *
ACCEPT all -- ppp+ bond0 * localnet/24
A confirmer va falloire que je test!
Mais en ouvrant tout forward j'ai plus de problème. (je n'avais pas relancer
Marsh Posté le 28-08-2005 à 11:40:39
ben sur mon mac ca passe mais pas sur mon pc du boulot...
Marsh Posté le 16-08-2005 à 21:05:18
Voila j'ai un serveur VPN avec les règles iptables suivantes (extrait j'ai jsute mis ce qui nous interresse):
INPUT (drop):
ACCEPT tcp -- any any localnet/24 Serveur-VPN tcp dpt:ssh
ACCEPT tcp -- any any localnet/24 Serveur-VPN tcp dpt:10000
FORWARD (drop):
ACCEPT all -- bond0 ppp+ localnet/24 localnet/24
ACCEPT all -- ppp+ bond0 localnet/24 localnet/24
OUTPUT (drop):
ACCEPT tcp -- any any Serveur-VPN localnet/24 tcp spt:ssh
ACCEPT tcp -- any any Serveur-VPN localnet/24 tcp spt:10000
Le serveur ne fait pas office de passerelle, il y a un modem/routeur devant.
Donc je me connecte sur mon VPN à distance sans problème.
Si je ping une bécane du réseau local aucun problème, idem si je demande le moindre services hebergé par le Serveur-VPN.
Et les choses se corsent juste maintenant.
Si j'ouvre une session SSH à distance sur une machine du reseau local, ca fonctionne tout bien correctement mais si j'essaye d'ouvrir une session Webmin, ça ne fonctionne pas! Le firewall le bloque.
Alors que les règles sont similaires...
J'ai essayé en ouvrant la chaîne OUTPUT (ACCEPT par défaut) ça fonctionne nickel. Après ça, je referme cette règle une fois ma session établie ca continue à tourner nickel et je vois en faisant "iptables -L -v" les règles contenu dans FORWARD faire transiter les paquets.
Alors d'ou vient cette neccessité d'avoir une ouverture sur OUTPUT ???
N'est-ce pas senser passer directement sur la chaîne FORWARD vu que ma requête n'est pas à destination du serveur ?
Et pourquoi ça fonctionne avec SSH mais pas Webmin ?
Merci
PS: Mon serveur dispose juste de bond0 un aggrégat de lien réseau vers le réseau local et de ppp+ l'interface virtuel des connexion VPN
Message édité par clockover le 16-08-2005 à 21:08:21