Iptables/Netfilter problème avec les hooks (décision routage erronée)

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: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...  :??:  :heink:  
 
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 :) :hello:
 
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
Reply

Marsh Posté le 16-08-2005 à 21:05:18   

Reply

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 ?


Message édité par clockover le 16-08-2005 à 21:42:31
Reply

Marsh Posté le 17-08-2005 à 21:09:49    

up

Reply

Marsh Posté le 20-08-2005 à 01:48:55    

up help

Reply

Marsh Posté le 20-08-2005 à 07:06:25    

Il faut que tu acceptes le protocole UDP en plus du TCP

Reply

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):
 
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...  :??:  :heink:  
 
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.
C'est normal si tu as une règle 'ESTABLISHED' en tête qui laisse passer ...
 
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 :) :hello:
 
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


Pour le reste, sois plus clair, je comprends pas tout
Plus de détails, et clairs, stp

Reply

Marsh Posté le 20-08-2005 à 12:09:14    

oki je vais faire un truc bien detailer et propre :)

Reply

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


Message édité par clockover le 20-08-2005 à 12:27:06
Reply

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 ...

Reply

Marsh Posté le 20-08-2005 à 14:50:01    

poptop
 
pptp-options

Code :
  1. name Serveur-VPN
  2. domain xxxxx
  3. chapms-strop-domain
  4. refuse-pap
  5. refuse-chap
  6. refuse-mschap
  7. require-mschap-v2
  8. require-mppe-128
  9. ms-dns ipduserveur
  10. proxyarp
  11. nodefaultroute
  12. lock
  13. nobsdcomp


 
voila


Message édité par clockover le 20-08-2005 à 14:56:47
Reply

Marsh Posté le 20-08-2005 à 14:50:01   

Reply

Marsh Posté le 20-08-2005 à 15:28:21    

clockover a écrit :

poptop
 
pptp-options

Code :
  1. name Serveur-VPN
  2. domain xxxxx
  3. chapms-strop-domain
  4. refuse-pap
  5. refuse-chap
  6. refuse-mschap
  7. require-mschap-v2
  8. require-mppe-128
  9. ms-dns ipduserveur
  10. proxyarp
  11. nodefaultroute
  12. lock
  13. nobsdcomp


 
voila


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 ?

Reply

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 :).

Reply

Marsh Posté le 21-08-2005 à 14:06:39    

up

Reply

Marsh Posté le 21-08-2005 à 14:19:01    

clockover a écrit :


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 ?


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 ?

Reply

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  
 

Reply

Marsh Posté le 28-08-2005 à 11:40:39    

ben sur mon mac ca passe mais pas sur mon pc du boulot... :heink:

Reply

Marsh Posté le 28-08-2005 à 20:51:26    

up une idée ?

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed