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

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Iptables/Netfilter problème avec les hooks (décision routage erronée)

clockover

That's the life

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

Publicité

clockover

That's the life

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

clockover

That's the life

clockover

That's the life

up help

rdc3

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

Zzozo

Modérateur
Un peu, passionément, à la fol

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

clockover

That's the life

oki je vais faire un truc bien detailer et propre

clockover

That's the life

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

Zzozo

Modérateur
Un peu, passionément, à la fol

J'ai besoin de qq infos supplémentaires là ...
décris moi la connexion VPN dans ses moindres détails, stp ...

clockover

That's the life

poptop

pptp-options

Code :

name Serveur-VPN
domain xxxxx
chapms-strop-domain
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns ipduserveur
proxyarp
nodefaultroute
lock
nobsdcomp

voila

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

Publicité

Zzozo

Modérateur
Un peu, passionément, à la fol

clockover a écrit :

poptop

pptp-options

Code :

name Serveur-VPN
domain xxxxx
chapms-strop-domain
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns ipduserveur
proxyarp
nodefaultroute
lock
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 ?

clockover

That's the life

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 .

clockover

That's the life

AirbaT

Connection timed out

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 ?

clockover

That's the life

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

clockover

That's the life

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

clockover

That's the life

up une idée ?

FORUM HardWare.fr

Linux et OS Alternatifs

réseaux et sécurité

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

Sujets relatifs
LinkSys ADSL2MUE : Problème sous GNU/Linux	probleme entre win et linux
Problème d'installation de XDTV ?	problème avec les wilcard (*) et sudo+rsync
Problème mrtg snmp [ résolu ]	problème de redirection d'une serie de commandes sous Linux
[FreeBSD] Probleme de partitions non demontees au reboot/shutdown	Red Hat - probleme accés au reseau et au Net
Probleme de partage de connexion en wifi mode ad hoc.	WHAX LIVE CD PROBLEME instal HDD mot de passe root plus valide
Plus de sujets relatifs à : Iptables/Netfilter problème avec les hooks (décision routage erronée)

Page générée en 0.091 secondes