logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 18-11-2014 01:20:37

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

J'avais écrit dans mon analyse :
"Ces règles acceptent tous les paquets émis ou reçus entre le routeur et le réseau B. Toutes les règles suivantes (et les règles ACCEPT précédentes) relatives à eth1 dans INPUT et OUTPUT donc sont redondantes."

Il vaut mieux montrer que raconter.

Hors ligne

#27 18-11-2014 02:37:39

anonyme
Invité

Re : Iptables : Parefeu Passerelle pas d acces internet

j'ai supprimé toutes les regles sur eth1  (80 , dns , steam etc ...)  et tout fonctionne

sur eth1 il ne reste que ces 2 regles (par contre l inverse ne fonctionne pas )
il ne reste que le filtrage sur eth0

#accepter le sous-réseau
/sbin/iptables -A INPUT -i eth1 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth1 -j ACCEPT


# Generated by iptables-save v1.4.21 on Mon Nov 17 13:16:49 2014
*mangle
:PREROUTING ACCEPT [1114:339184]
:INPUT ACCEPT [42:4913]
:FORWARD ACCEPT [1072:334271]
:OUTPUT ACCEPT [25:18984]
:POSTROUTING ACCEPT [1093:353095]
-A PREROUTING -p tcp -m tcp --dport 3128 -j DROP
-A PREROUTING -p tcp -m tcp --dport 3129 -j DROP
COMMIT
# Completed on Mon Nov 17 13:16:49 2014
# Generated by iptables-save v1.4.21 on Mon Nov 17 13:16:49 2014
*nat
:PREROUTING ACCEPT [70:4333]
:INPUT ACCEPT [5:300]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3129
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.10:3129
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Nov 17 13:16:49 2014
# Generated by iptables-save v1.4.21 on Mon Nov 17 13:16:49 2014
*filter
:INPUT DROP [8:386]
:FORWARD DROP [6:240]
:OUTPUT DROP [74:7221]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m multiport --sports 80,443,8080 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 27000 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -i eth1 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.10.0/24 -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443,8080 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 27000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Mon Nov 17 13:16:49 2014

 



voici mon nouvel iptables , le filtrage ce fait sur eth0 (si je commente les lignes web et steam j ai plus rien qui fonctionne).
par contre je comprend pas le principe , j ai le ping sur tous les réseau d 'un client de B mais la passerelle n est pas autorisée (donc je pense a eth0 qui est drop alors que eth1 est accept ).
ça me derrange pas de filtrer sur eth0 , par contre mon parefeu est terminé , si mon logiciel fah sort sur le port 8080 et 80 , si steam aussi en 27000 et le dns aussi , tout le reste va etre sur le reseau B
a la rigueur un parefeu sur chaque client (le filter va etre comme ici , sur eth0 du client (une seule carte reseau) ).
regarde si tout est correct , le related sur steam j ai un doute , pour le web je pense oui , les regles en input et output aussi puisque la regle par defaut est drop pour eth0 .
reste le forward je vai regarder sur le web ,
Pour icmp sur le reseau " B => clients" pour l instant tout est ouvert ,de B ver A les pings passent , du reseau A vers B c est nécessaire ?
pour mangle et nat  je pense que c est correct , le proxy fonctionne bien , je vai faire un post a ce sujet , a propos du wiki proxy et de mes soucis  smile

Dernière modification par anonyme (18-11-2014 04:24:35)

#28 19-11-2014 17:48:47

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

Juste un mot pour dire que je ne t'oublie pas, je suis en train d'étudier tes informations.

Il vaut mieux montrer que raconter.

Hors ligne

#29 19-11-2014 18:18:57

anonyme
Invité

Re : Iptables : Parefeu Passerelle pas d acces internet

Bonjour
a ok , smile
je te donne un peu de nouvelles  , j ai teste bind9 , pas bon du tout , en fait je n ai que le dhcp qui est a peu pres correct.
suite a nuit blanche sur bind , j ai retire le proxy , bind et je pense désactiver iptables pour les tests
je n arrive pas a résoudre les noms , mettre a jour bind etc .....
tout est lié , parefeu , proxy , config reseau
j ai gardé tous les .conf
un exemple sur le web j ai acces a peu pres bien partout sauf orange.fr smile  (avec parefeu + proxy + dhcp + bind )
a priori bind utilise le port 53 sur les 2 reseau + un port en 127.0.0.1 le 953 (canal de communication)
@++

ps2: faut que tu lise le sujet sur bind (avec dhcp) , des infos peut etre pour le parefeu  et le routage a faire (pour l instant je travaille avec iptables posé sur ce post avec dnat en moins puisque le proxy ne me convient pas)

Dernière modification par anonyme (20-11-2014 18:50:47)

#30 21-11-2014 00:06:16

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

Note : quand je parle des "machines du réseau B", j'exclus la passerelle elle-même bien qu'elle fasse techniquement partie du réseau B.

anonyme a écrit :

Il y a des serveurs FTP, STEAM, DNS, HTTP, HTTPS et écoutant sur le port 8000 dans le réseau B, avec lesquels le routeur a besoin de communiquer ?


oui tous ses services sont sur le réseau B


Sur des machines du réseau B ou sur la passerelle ?
Je doute qu'il y ait un serveur STEAM sur le réseau B.
Ces règles permettent à la passerelle de se connecter à ces services sur des machines via eth1. Si tu veux faire l'inverse, permettre aux machines du réseau B de se connecter à ces services sur la passerelle, les règles sont différentes. Grosso modo, il faut permuter les entrées et les sorties pour les paquets aller et retour :

Permettre à la machine de se connecter au port TCP X d'autres machines accessibles par eth1 (connexion sortante) :

iptables -A OUTPUT -o eth1 -p tcp --dport X -m state --state NEW,ESTABLISHED -j ACCEPT # aller
iptables -A INPUT -i eth1 -p tcp --sport X -m state --state ESTABLISHED -j ACCEPT # retour



Permettre à d'autres machines de se connecter au port TCP X de la machine par eth1 (connexion entrante) :

iptables -A INPUT -i eth1 -p tcp --dport X -m state --state NEW,ESTABLISHED -j ACCEPT # aller
iptables -A OUTPUT -o eth1 -p tcp --sport X -m state --state ESTABLISHED -j ACCEPT # retour


Néanmoins, en autorisant tout le trafic entrant et sortant sur eth1, tu n'as pas besoin de règles individiduelles. Aussi, que ce soit dans un sens ou dans l'autre ces règles ne servent pas pour les paquets des connexions qui traversent la passerelle entre le réseau B et le réseau A ou internet. Ces paquets ne passent pas dans les chaînes INPUT ni OUTPUT mais dans la chaîne FORWARD.

anonyme a écrit :

pour ftp serveur pas encore fait mon choix , mais sera sur un client port par defaut (pas d acces de l exterieur ni de A )


Je ne comprends pas cette phrase. Serveur, client, port par défaut ?

anonyme a écrit :

j ai un programme (fah) sur chaque client qui utilise le port 8080


fah = Folding@home ? Folding@home se connecte à des serveurs qui sont sur internet. S'il est installé sur des machines du réseau B, les paquets des connexions traversantes du réseau B vers internet doivent être acceptés dans la chaîne FORWARD :

iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 8080 -m state --state NEW,ESTABLISHED -j ACCEPT # aller
iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 8080 -m state --state ESTABLISHED -j ACCEPT # retour


(Ces règles ne sont pas nécessaires s'il y a déjà des règles plus permissives autorisant les connexions du réseau B vers internet sur tous les ports.)

S'il est installé sur la passerelle, les paquets des connexions sortantes vers internet doivent être acceptés dans les chaînes INPUT et OUTPUT :

iptables -A OUTPUT -o eth0 -p tcp --dport 8080 -m state --state NEW,ESTABLISHED -j ACCEPT # aller
iptables -A INPUT -i eth0 -p tcp --sport 8080 -m state --state ESTABLISHED -j ACCEPT # retour



anonyme a écrit :

definition de "RELATED" le serveur 2 reçoit le paquet SYN  (suite a un NEW du serveur 1)  et renvoie un accusé de réception SYN-ACK (synchronize ackowledgement ) .

si je prend l exemple du dns , un client fait une demande , c est ma passerelle adsl qui traite la requette et pas la passerelle de B , donc la poignée de main est entre la box machin et le client du réseau B .
Mon ip du dns du réseau est l ip de la boxmachin 192.168.1.1 donc pour eth1 de la passerelle ESTABLISHED suffit .
Mon raisonnement est correct ?


Non. En fait j'ai beau le lire dans tous les sens, je n'arrive pas à le comprendre. Je vais essayer d'expliquer le plus clairement possible sans trop entrer dans les détails.

Le protocole IP fournit une connectivité de bout en bout : le client communique directement avec le serveur, et les routeurs intermédiaires sont quasi-transparents, ils se contentent de faire suivre les paquets de l'un vers l'autre.

Le suivi de connexion ("conntrack", contraction de "connection tracking"), examine chaque paquet qui va être traité par iptables pour lui donner un état que pourra utiliser iptables pour décider du sort du paquet. Si c'est un paquet reçu, conntrack intervient avant les chaines PREROUTING. Si c'est un paquet émis, conntrack intervient avant les chaînes OUTPUT. Une chose importante est qu'il ne faut pas confondre un paquet et une connexion, ni l'état d'un paquet avec l'état d'une connexion. Une connexion implique généralement plusieurs paquets dans les deux directions aller et retour, ayant des états différents. A noter que pour conntrack, contrairement aux règles iptables, la direction n'est pas définie par l'entrée ou la sortie mais par la source et la destination du paquet. La direction aller ou retour d'un paquet est définie par rapport à la direction du premier paquet de la connexion : dans le même sens = aller, dans le sens inverse = retour.

Le premier paquet aller d'une connexion, celui qui "crée" la connexion (au sens de conntrack), a l'état NEW. Si ce paquet est bloqué par les règles iptables, la connexion n'est pas créée. Si ce paquet est répété en l'absence de réponse, il a encore l'état NEW.

Le premier paquet retour appartenant à une connexion a l'état ESTABLISHED. Tous les paquets aller et retour suivants ont aussi l'état ESTABLISHED.

Les paquets liés à une connexion existante mais ne lui appartenant pas ont l'état RELATED. Les messages d'erreurs ICMP émis en réponse à un autre paquet sont dans ce cas. Le premier paquet d'une connexion de données liée à une connexion de commande en clair (non chiffrée) qu'on rencontre dans certains protocoles complexes comme FTP, TFTP, SIP, PPTP... a l'état RELATED au lieu de NEW si le module de conntrack pour ce protocole est actif.

Enfin, les paquets qui ne créent pas une nouvelle connexion et ne peuvent pas être rattachés à une connexion existante ont l'état INVALID. Cela concerne principalement les protocoles TCP (qui a intrinsèquement une notion d'état assez stricte) et ICMP. Je ne connais pas de cas où un paquet UDP aurait l'état INVALID. Une particularité notable des paquets dans l'état INVALID est qu'ils sont ignorés par les règles de NAT (DNAT, REDIRECT, MASQUERADE...). Dans la plupart de cas, ces paquets devraient être bloqués.

Quelques exemples pour illustrer :

a) Etablissement d'une connexion TCP HTTP :
- le client envoie au serveur un paquet SYN vers le port 80 qui a l'état NEW
- le serveur envoie au client un paquet SYN/ACK depuis le port 80 qui a l'état ESTABLISHED
- le client envoie au serveur un paquet ACK vers le port 80 qui a l'état ESTABLISHED

b) Résolution DNS :
- le client envoie au serveur un paquet UDP vers le port 53 qui a l'état NEW
- le serveur envoie au client un paquet UDP depuis le port 53 qui a l'état ESTABLISHED

Dans certains cas, les requêtes suivantes peuvent avoir l'état ESTABLISHED au lieu de NEW.

c) Ping (ICMP echo)
- le client envoie au serveur un paquet ICMP de type echo-request qui a l'état NEW
- le serveur envoie au client un paquet ICMP de type echo-reply qui a l'état ESTABLISHED

Dans certains cas, les requêtes suivantes peuvent avoir l'état ESTABLISHED au lieu de NEW.

d) Traceroute
- le client envoie au serveur un paquet UDP avec le TTL=1 qui a l'état NEW
- le premier routeur envoie au client un paquet ICMP de type time-exceeded qui a l'état RELATED
- le client envoie au serveur un paquet UDP avec le TTL=2 qui a l'état NEW
- le second routeur envoie au client un paquet ICMP de type time-exceeded qui a l'état RELATED
- etc.

anonyme a écrit :

-A OUTPUT -o eth1 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT


ces regles ont été commenté pour l instant, a supprimer ( ps : aprés le reboot de la passerelle plus de web.....  a cause du proxy pas vu  )


Normal. Les connexions HTTP sont redirigés vers le port 3129 du proxy local par une règle de NAT, mais s'il n'y a pas de règles globales (celles ci-dessus que tu as commentées) ou spécifiques (voir exemple plus haut) acceptant les connexions entrantes sur eth1 vers de ce port, le proxy ne reçoit rien.

anonyme a écrit :

-A OUTPUT -o eth1 -p udp -m udp --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT


Ces règles acceptent les requêtes DNS émises par le routeur vers le réseau B et les réponses reçues.
Il y a vraiment un serveur DNS sur le réseau B ?


non pas de dns sur le réseau B , je les gardes pour re-tester   bind9 (le dns sera sur la carte eth1 de la passerelle et fera les requets externe sur la passerelle adsl.)


Alors ces règles ne servent à rien. Elles permettent à la passerelle d'interroger un serveur DNS situé sur le réseau B (connexion sortante sur eth1), ce dont tu n'as pas besoin. Tu as besoin de règles permettant à la passerelle d'interroger un serveur sur le réseau A ou internet (connexion sortante sur eth0), et de règles permettant aux machines du réseau B d'interroger le serveur DNS sur la passerelle (connexion entrante sur eth1.

anonyme a écrit :

ces  regles devraient suffire pour le web ?

-A OUTPUT -o eth1 -p tcp -m multiport --dports 80,443,8080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443,8080 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -p tcp -m multiport --sports 80,443,8080 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp -m multiport --sports 80,443,8080 -j ACCEPT


Les règles pour eth1 sont inutiles. Elles permettent à la passerelle d'interroger un serveur HTTP, HTTPS ou FAH situé sur le réseau B (connexion sortante sur eth1), ce dont tu n'as pas besoin.

Dans les règles pour eth0, le proxy transparent a seulement besoin du port 80. Un proxy ne peut fonctionner avec le port 443 que s'il fonctionne en mode non transparent. Par contre d'autrs processus locaux de la passerelle peuvent avoir besoin de se connecter à un serveur HTTPS pour certains usages, par exemple pour des mises à jour. Quant au port 8080, la passerelle n'en a besoin que si elle fait tourner le logiciel FAH.

Commentaires sur ton dernier jeu de règles

-A PREROUTING -p tcp -m tcp --dport 3128 -j DROP
-A PREROUTING -p tcp -m tcp --dport 3129 -j DROP


A quoi servent ces deux règles ? Pourquoi bloquer précocément les paquets entrants sur ces deux ports ?
Le proxy local écoute sur le port 3129, mais pourquoi bloquer les connexions vers ce port qui n'ont pas été redirigées à partir du port 80 ?
A quoi correspond le port 3128 ?

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3129
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.10:3129


Pourquoi rediriger vers le port du proxy les connexions HTTP qui entrent par eth0, côté réseau A et internet (et qui seront bloquées puisqu'il n'y a pas de règles les autorisant ensuite) ?
Côté réseau B, pourquoi rediriger les connexions HTTP vers l'adresse IP 192.168.1.10, qui est je suppose l'adresse IP d'eth0 ? Cela me laisse penser que le proxy écoute sur cette adresse, alors qu'il me semble qu'il serait plus logique qu'il écoute soit sur toutes les adresses locales, soit sur l'adresse d'eth1.

-A INPUT -i eth0 -p udp -m udp --sport 27000 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 27000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT


Je répète que ces règles ne sont utiles (sans RELATED) que si un client STEAM tourne sur la passerelle. Je doute que ce soit le cas.

Il manque la gestion des paquets ICMP sur eth0 en entrée (INPUT) et en sortie (OUTPUT). Au minimum il faut accepter les types destination-unreachable, time-exceeded et parameter-problem dans l'état RELATED.


Il vaut mieux montrer que raconter.

Hors ligne

#31 21-11-2014 03:36:33

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Iptables : Parefeu Passerelle pas d acces internet

Pour ceux qui suivent de loin ce post qui devrait faire date sur df, le côté des paquets sur internet est dans un tuto df initié par une conférence de Benjamin Bayart retranscrite ici :
internet, qu'est-ce que c'est ? smile

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#32 22-11-2014 06:57:15

anonyme
Invité

Re : Iptables : Parefeu Passerelle pas d acces internet

Bonjour

sur la passerelle apt-get ne fonctionne pas , ntp ne fonctionne pas , imprimante partagée reseau A ne fonctionne pas , dns fonctionne mal



# Generated by iptables-save v1.4.21 on Sat Nov 22 06:15:25 2014
*mangle
:PREROUTING ACCEPT [313088:291063575]
:INPUT ACCEPT [6933:1169075]
:FORWARD ACCEPT [306155:289894500]
:OUTPUT ACCEPT [8001:793720]
:POSTROUTING ACCEPT [314139:290687540]
COMMIT
# Completed on Sat Nov 22 06:15:25 2014
# Generated by iptables-save v1.4.21 on Sat Nov 22 06:15:25 2014
*nat
:PREROUTING ACCEPT [3079:280027]
:INPUT ACCEPT [1589:184162]
:OUTPUT ACCEPT [3809:288382]
:POSTROUTING ACCEPT [1533:114170]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Nov 22 06:15:25 2014
# Generated by iptables-save v1.4.21 on Sat Nov 22 06:15:25 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ftp_in_accept - [0:0]
-A INPUT -i eth0 -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ftp_in_accept
-A INPUT -i eth0 -p tcp -m tcp --sport 20 -m state --state RELATED,ESTABLISHED -j ftp_in_accept
-A INPUT -i eth0 -p tcp -m tcp --sport 21 -m state --state RELATED,ESTABLISHED -j ftp_in_accept
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m multiport --sports 80,443,8080 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 27000 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 123 -m state --state ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -i eth1 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.10.0/24 -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443,8080 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 27000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 123 -m state --state NEW,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sat Nov 22 06:15:25 2014
 



et j ai l impression que eth1 ne profite pas des regles de eth0  donc grand ouvert sur le réseau A (je n ai pas de soucis avec apt du reseau B) .
pour les tests je n ai DROP que INPUT  (FORWARD est toujours DROP , pas de soucis sur le reseau B uniquement sur la passerelle ) .
@++

en mode dépressif l iptables


# Generated by iptables-save v1.4.21 on Sat Nov 22 07:32:49 2014
*mangle
:PREROUTING ACCEPT [42507:42373799]
:INPUT ACCEPT [4337:5439140]
:FORWARD ACCEPT [38170:36934659]
:OUTPUT ACCEPT [3438:222646]
:POSTROUTING ACCEPT [41606:37157225]
COMMIT
# Completed on Sat Nov 22 07:32:49 2014
# Generated by iptables-save v1.4.21 on Sat Nov 22 07:32:49 2014
*nat
:PREROUTING ACCEPT [337:23677]
:INPUT ACCEPT [119:10405]
:OUTPUT ACCEPT [439:32485]
:POSTROUTING ACCEPT [51:3452]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Nov 22 07:32:49 2014
# Generated by iptables-save v1.4.21 on Sat Nov 22 07:32:49 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:ftp_in_accept - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -i eth1 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT  #=> manque le RELATED
-A FORWARD -d 192.168.10.0/24 -i eth0 -o eth1 -m state --state ESTABLISHED -j ACCEPT          #=> manque le RELATED
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
COMMIT
# Completed on Sat Nov 22 07:32:49 2014

 


ici il manque le RELATED sur le FORWARD , connection sur le site avec un client de B possible , mais au momment d enregistrer un post réinitialisation de la connextion et hop ejecté .

Dernière modification par anonyme (22-11-2014 09:40:56)

#33 22-11-2014 09:45:55

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

Normal pour l'imprimante réseau, tu n'as pas ajouté de règles permettant la passerelle de s'y connecter (généralement port TCP 9100).

Pour le reste, peux-tu préciser comment ça ne fonctionne pas ?
Quels sont les serveurs DNS définis dans /etc/resolv.conf sur la passerelle et les postes du réseau B ?
Si c'est ton propre BIND sur la passerelle, est-ce que ça marche mieux avec le DNS de la box ?

Tu peux aussi faire des tests simples :
- résolution DNS avec host, dig ou nslookup vers le DNS par défaut ou un DNS spécifique (box, FAI)
- tcptraceroute vers une adresse IP extérieure sur un port TCP censé être autorisé
- requête NTP manuelle avec ntpdate...

Si tu souçonnes les règles de filtrage, c'est simple : tu autorises tout en INPUT et tu regardes si ça règle le problème.

Tu peux aussi ajouter des règles avec la cible LOG à la fin des chaînes dont la politique par défaut est DROP afin d'enregistrer les paquets bloqués dans les logs du noyau (/var/log/kern.log).

Il vaut mieux montrer que raconter.

Hors ligne

#34 22-11-2014 09:55:22

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

S'il te plaît évite d'éditer tes anciens messages pour ajouter des informations car cela ne se remarque pas forcément et les réponses faites entretemps deviennent obsolètes. Aussi quelqu'un qui lirait le fil après coup n'y comprendrait rien. Fais plutôt un nouveau message.

j ai l impression que eth1 ne profite pas des regles de eth0


En effet, les règles sur eth0 n'ont pas d'effet direct sur les paquets sur eth1.

il manque le RELATED sur le FORWARD , connection sur le site avec un client de B possible , mais au momment d enregistrer un post réinitialisation de la connextion et hop ejecté


Quel site ? Ce forum ? Je ne vois pas de rapport entre l'état RELATED et le protocole HTTP. Tu es sûr que ce n'est pas juste l'expiration de la session ?


Il vaut mieux montrer que raconter.

Hors ligne

#35 22-11-2014 10:00:32

anonyme
Invité

Re : Iptables : Parefeu Passerelle pas d acces internet

raleur a écrit :

Normal pour l'imprimante réseau, tu n'as pas ajouté de règles permettant la passerelle de s'y connecter (généralement port TCP 9100).

Pour le reste, peux-tu préciser comment ça ne fonctionne pas ?
Quels sont les serveurs DNS définis dans /etc/resolv.conf sur la passerelle et les postes du réseau B ?
Si c'est ton propre BIND sur la passerelle, est-ce que ça marche mieux avec le DNS de la box ?

Tu peux aussi faire des tests simples :
- résolution DNS avec host, dig ou nslookup vers le DNS par défaut ou un DNS spécifique (box, FAI)
- tcptraceroute vers une adresse IP extérieure sur un port TCP censé être autorisé
- requête NTP manuelle avec ntpdate...

Si tu souçonnes les règles de filtrage, c'est simple : tu autorises tout en INPUT et tu regardes si ça règle le problème.

Tu peux aussi ajouter des règles avec la cible LOG à la fin des chaînes dont la politique par défaut est DROP afin d'enregistrer les paquets bloqués dans les logs du noyau (/var/log/kern.log).



imprimante je suis d accord pour la regle elle n existe pas
pour le resolv tu a pas lut mon post bind il est complet  smile  , mais oui j ai  name server 192.168.10.1 , name server 80.10.246.130  et search exemple.com
les postes du reseau B sont en auto-config et c est ok (dhcp de la passerelle)
pas de soucis de dns et de dhcp
ntp fonctionne bien et celui de la passerelle distribue au client
je suis en mode depressif tout est autorisé   smile et cela fonctionne bien

@++

Dernière modification par anonyme (22-11-2014 10:01:47)

#36 22-11-2014 10:20:51

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

C'est quoi exactement, le mode dépressif ?

Il vaut mieux montrer que raconter.

Hors ligne

#37 22-11-2014 10:38:56

anonyme
Invité

Re : Iptables : Parefeu Passerelle pas d acces internet

c est ça le mod/ depressif:  tout autoriser

:ftp_in_accept - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -i eth1 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT  #=> manque le RELATED
-A FORWARD -d 192.168.10.0/24 -i eth0 -o eth1 -m state --state ESTABLISHED -j ACCEPT          #=> manque le RELATED
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT

oui sur le forum Debian-facile et j ai fait plusieurs test tres rapide, c est pas le time-out et j ai remit  RELATED et c est bon je peus poster.

Dernière modification par anonyme (22-11-2014 10:39:49)

#38 22-11-2014 11:33:32

raleur
Membre
Inscription : 03-10-2014

Re : Iptables : Parefeu Passerelle pas d acces internet

Sauf erreur, tu as supprimé la redirection vers le proxy transparent donc le HTTP passe par la chaîne FORWARD.

Mais une connexion HTTP n'a pas de paquet dans l'état RELATED, donc je ne vois qu'un paquet ICMP lié à cette connexion HTTP qui pourrait être dans cet état. Je pense notamment à un message ICMP de type "destination unreachable" avec le code "fragmentation needed" signalant qu'il faut réduire la taille des paquets émis. C'est classique avec une liaison ADSL en PPPoE si PMTUD (path MTU discovery) est activé (/proc/sys/net/ipv4/ip_no_pmtu_disc=0) sur le poste, et cela se manifeste surtout quand on envoie une quantité de données approchant ou dépassant la taille maximum d'un paquet, comme un message sur un forum. De toute façon je l'avais écrit dans ma dernière longue réponse : il faut autoriser certains types ICMP dans l'état RELATED, dont celui-ci.

Mais de toute façon j'ai aussi déjà écrit que c'est facile d'identifier les paquets bloqués avec une règle LOG plutôt que d'essayer des dizaines de jeux règles à l'aveugle.

Il vaut mieux montrer que raconter.

Hors ligne

Pied de page des forums