Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

iptables : separation deux sous réseau mais laisser internet

canard-gras

Bonjour,

J'ai installé une machine où j'ai trois cartes réseaux.
sous réseau 1 => eth0 192.168.1.0/24
sous réseau 2 => eth1 10.0.81.0/24
réseau INTERNET => eth3 mon IP publique cablée à internet

Objectif :
=> que les deux sous réseau se connecte à internet
=> que le sous réseau 1 ne puisse aller sur le réseau 2 et réciproquement.

Je butte sur le script iptables.
Pour la connexion intern pas de pb.
mais mon pb est :
à partir d'une machine sur le réseau 1, je pingue une machine du réseau 2 et réciproquement. Le réseau 1 et 2 communiquent.

Je pensai comprendre que cela marcherait avec un
iptables -A FORWARD -d 192.168.1.0/24 -o eth1 -s 10.0.81.0/24 -i eth0 -j DROP
iptables -A FORWARD -s 192.168.1.0/24 -i eth1 -d 10.0.81.0/24 -o eth0 -j DROP

Ben non, pourtant j'ai bien :
Chain FORWARD (policy DROP 2 packets, 104 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth0 eth1 10.0.81.0/24 192.168.1.0/24
0 0 DROP all -- eth1 eth0 192.168.1.0/24 10.0.81.0/24

Comme j'ai d'autres règles installées que je ne comprends pas trop, quel serait le script que vous proposeriez pour réaliser proprement cette connexion internet mais interdire la com. entre les deux sous réseaux ?
(c'est dans un but de compréhension... merci)

tiramiseb

Salut,

Je te conseillerais d'utiliser un vrai logiciel de gestion de pare-feu plutôt qu'un script, comme Shorewall. Surtout si tu as aussi d'autres règles à mettre en place. Il faut apprendre à l'utiliser, mais ce n'est pas sorcier...

Sinon, en terme de commandes iptables, quelque chose de ce style devrait suffire :

iptables -t nat -A POSTROUTING -o eth3 -s 192.168.1.0/24 -j  MASQUERADE
iptables -t nat -A POSTROUTING -o eth3 -s 10.0.0.0/24 -j  MASQUERADE
iptables -A FORWARD -s 10.0.0.0/24 -d 192.168.1.0/24 -j REJECT
iptables -A FORWARD -s 192.168.1.0/24 -d 10.0.0.0/24 -j REJECT

canard-gras

Merci pour ta réponse.

J'avais installé sur une machine Gufw dans l'espoir de voir les commandes iptables mais il fait des lignes à sa façon donc ce n'est pas exploitable pour moi. Je vais voir avec shorewall.
Je n'ai pas d'interface graphique sur ma machine que je destine au routage, donc j'ai fait un script à partir de ce que j'ai pu lire par ailleurs, et notamment sur le forum.

Je comprends les lignes que tu as écrites. Je vais tester et cela me confirme que c'est surement une règle copier/coller que j'ai pris dans le forum qui met la pagaille.

Une question : Pourquoi REJECT au lieu de DROP ?

Il m'a fallut mettre cela, mais je ne comprends pas.

# Acceptation de toutes les connexions en local (un process avec l'autre)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT

#création d'une nouvelle règle
iptables -N MAregle

#définition de la règle : accepter les nouvelles connexions ne venant pas de l'interface internet
# et accepter toutes les connexions établies et reliées (ex: une demande de page HTML provoque l'ouverture
# d'une connexion reliée pour acheminer cette page vers l'ordinateur)

iptables -A MAregle -m state --state NEW ! -i $interface -j ACCEPT
iptables -A MAregle -m state --state ESTABLISHED,RELATED -j ACCEPT

#application de la règle au partage de connexion
iptables -A INPUT -j MAregle
iptables -A FORWARD -j MAregle

# activation du forwarding dans le noyau
# mise en place du partage de connexion sur le réseau local

echo 1 >/proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o $interface -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.0.81.0/24 -o $interface -j MASQUERADE

tiramiseb

l'espoir de voir les commandes iptables

Mais pourquoi tiens-tu absolument à voir les commandes iptables ?

Une question : Pourquoi REJECT au lieu de DROP ?

REJECT : envoyer une réponse icmp à l'expéditeur en lui disant que la connexion est interdite
DROP : laisser tomber le paquet sans autre action (donc attente du timeout du côté du client)

Les timeouts sont très chiants, surtout entre deux réseaux locaux...

# Acceptation de toutes les connexions en local (un process avec l'autre)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT

Houla c'est crade tout ça : il faut faire ça avec les POLICY !

canard-gras

# Acceptation de toutes les connexions en local (un process avec l'autre)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT[

Houla c'est crade tout ça : il faut faire ça avec les POLICY !

Ok j'ai compris. J'ai mis en policy

#stratégies par défaut
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Et j'ai tout enlevé car c'était redondant sauf pour lo où j'ai laissé que la règle OUTPUT

canard-gras

Je ne comprends pas cela

iptables -A MAregle -m state --state NEW ! -i $interface -j ACCEPT
iptables -A MAregle -m state --state ESTABLISHED,RELATED -j ACCEPT

tiramiseb

Tu n'as pas répondu à cette question :
Pourquoi tiens-tu absolument à voir les commandes iptables ?

canard-gras a écritJe ne comprends pas cela
iptables -A MAregle -m state --state NEW ! -i $interface -j ACCEPT
iptables -A MAregle -m state --state ESTABLISHED,RELATED -j ACCEPT

Eh bien avec ces deux commandes, tu ajoutes les deux règles suivantes à la chaîne que tu as appelée "MAregle" :
- accepter toutes les nouvelles connexion provenant de l'interface définie dans la variable "$interface"
- accepter toutes les connexions déjà en cours, quelle que soit la provenance

Je crois à peu près percevoir la logique tordue derrière cette organisation de règles... mais c'est vachement tordu...

canard-gras

tiramiseb a écritTu n'as pas répondu à cette question :
Pourquoi tiens-tu absolument à voir les commandes iptables ?

Je ne sais pas répondre à ta question. Je souhaite " voir les commandes iptables" afin de comprendre comme cela marche et modifier ensuite les règles selon mes besoins.
Si c'est bien le sens de la question, ce dont je ne suis pas sûr.

tiramiseb a écrit Eh bien avec ces deux commandes, tu ajoutes les deux règles suivantes à la chaîne que tu as appelée "MAregle" :
- accepter toutes les nouvelles connexion provenant de l'interface définie dans la variable "$interface"
- accepter toutes les connexions déjà en cours, quelle que soit la provenance

J'avais compris que le signe d'exclamation indiquait "ne provenant pas de l'interface $interface"
Si c'est le cas, cela signifie que toutes les connexions eth0 et eth1 sont autorisées ! non ?

En tout cas, je souhaite de remercier pour tes réactions.

tiramiseb

comprendre comme cela marche et modifier ensuite les règles selon mes besoins

L'intérêt de ces logiciels est de pouvoir modifier les règles selon tes besoins sans avoir à trifouiller les commandes iptables, justement.
Pour "comprendre comment cela marche", le mieux est de regarder les règles mises en place avec les commandes :

iptables -L
iptables -t nat -L

J'avais compris que le signe d'exclamation indiquait "ne provenant pas de l'interface $interface"

Oups oui désolé, tu as raison : accepter toutes les nouvelles connexion ne provenant pas de l'interface définie dans la variable "$interface".

Et je réitère mon conseil : ne t'emm....e pas à trifouiller les commandes iptables, utilise un outil efficace de gestion de pare-feu...

Haleth

10.0.0.0/24 n'est pas 10.0.81.0/24

canard-gras

tiramiseb a écritcomprendre comme cela marche et modifier ensuite les règles selon mes besoins

Et je réitère mon conseil : ne t'emm....e pas à trifouiller les commandes iptables, utilise un outil efficace de gestion de pare-feu...

Oui d'accord, mais je n'ai pas d'interface graphique pour faire marcher par exemple ufw
et Shorewall me semble trés compliqué...

tiramiseb

mais je n'ai pas d'interface graphique pour faire marcher par exemple ufw

Tu peux utiliser gufw qui est une surcouche graphique à ufw. Mais bon, je ne vois pas l'intérêt des interfaces graphiques...
Par contre je ne suis pas sûr qu'UFW (et a fortiori GUFW) répond à ton besoin.

Shorewall me semble trés compliqué...

Pas tant que ça, il faut juste comprendre comment ça marche.
Et puis ça répond parfaitement à ton besoin...

canard-gras

Bon, désolé de faire cela de façon illogique mais je fais plusieurs choses en même temps...
Ci-dessous ce qui ne marche pas, et cela vient de Maregle qui, je le précise, vient d'un sujet de forum.
Ci-dessous le résultat iptables -L -n -v

Chain INPUT (policy DROP 923 packets, 69142 bytes)
pkts bytes target prot opt in out source destination
9672 759K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
5991 554K ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
0 0 ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5010
0 0 ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5011
0 0 ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5012
0 0 ACCEPT tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5013
170K 27M MAregle all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 2044 packets, 93363 bytes)
pkts bytes target prot opt in out source destination
2745K 2872M MAregle all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * * 10.0.0.0/24 192.168.1.0/24 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 192.168.1.0/24 10.0.0.0/24 reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 21072 packets, 2484K bytes)
pkts bytes target prot opt in out source destination
9943 815K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0

Chain MAregle (2 references)
pkts bytes target prot opt in out source destination
236K 26M ACCEPT all -- !eth3 * 0.0.0.0/0 0.0.0.0/0 state NEW
2675K 2873M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

tiramiseb

Ci-dessous ce qui ne marche pas

Qu'est-ce qui ne marche pas? Que se passe-t-il ?

canard-gras

Sur une machine sur le réseau 192.168.1.0/24 je peux pinguer une machine du réseau 10.0.81.0/24
Et cela, je souhaiterai que cela ne soit pas possible.

tiramiseb

Ben oui, mais là tes règles fonctionnent tout à fait correctement.
Le paquet fait le cheminement suivant :

1/ arrivée du paquet dans ton système
2/ entrée dans la chaîne FORWARD
3/ redirection vers la chaîne appelée "MAregle" grâce à la première règle de la chaîne "FORWARD"
4/ autorisation du paquet grâce à la première règle de la chaîne "MAregle" : le paquet ne provient pas d'eth3, il est accepté.

Dans tes règles là, tu n'as aucun filtrage entre des deux réseaux internes.
Tu n'as pas mis en place d'équivalent des règles REJECT que j'ai proposées dans mon message #2 en réponse à ta problématique d'origine.
Tu piétines au niveau de ton message d'origine alors que j'ai déjà répondu à ce problème.

PS : sérieusement, utilise un vrai outil de gestion de pare-feu plutôt que bricoler des scripts...

canard-gras

Voilà le script que je ne devrai pas faire 🙂
et qui produit le résultat cité ci-dessus.
(tiré du forum ubuntu)

# Dans cette partie, on met en place le firewall
#vidage des chaines
iptables -F
#destruction des chaines personnelles
iptables -X
 
#stratégies par défaut
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
 
#init des tables NAT et MANGLE (pas forcément nécessaire)
iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
 
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
 
 
# Acceptation de toutes les connexions en local (un process avec l'autre)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#création d'une nouvelle règle (tiré d'ubuntu)
iptables -N MAregle
 
#définition de la règle : accepter les nouvelles connexions ne venant pas de l'interface internet
# et accepter toutes les connexions établies et reliées (ex: une demande de page HTML provoque l'ouverture
# d'une connexion reliée pour acheminer cette page vers l'ordinateur)
 
iptables -A MAregle -m state --state NEW ! -i $interface -j ACCEPT
iptables -A MAregle -m state --state ESTABLISHED,RELATED -j ACCEPT

#application de la règle au partage de connexion
iptables -A INPUT -j MAregle
iptables -A FORWARD -j MAregle

iptables -A FORWARD -s 10.0.0.0/24 -d 192.168.1.0/24 -j REJECT
iptables -A FORWARD -s 192.168.1.0/24 -d 10.0.0.0/24 -j REJECT


# activation du forwarding dans le noyau
# mise en place du partage de connexion sur le réseau local
 
echo 1 >/proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o $interface -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.0.81.0/24 -o $interface -j MASQUERADE

tiramiseb

Essaie de faire travailler ton cerveau !

La toute première règle que tu as mise dans FORWARD et dans INPUT renvoie tous les paquets dans ta chaîne que tu as appelée "MAregle". Par conséquent, ce n'est pas dans la chaîne FORWARD qu'il faut mettre les règles que je t'ai données.

Essaie de comprendre ce que tu fais...

tiramiseb

Ah oui, au fait : si tu utilisais un logiciel fait pour ça comme Shorewall, tu n'aurais pas ce genre d'errements...

canard-gras

tiramiseb a écritAh oui, au fait : si tu utilisais un logiciel fait pour ça comme Shorewall, tu n'aurais pas ce genre d'errements...

Oui je sais :lol:

Page suivante »