Passerelle+ipatbles+débutant

Support Debian
#1

Bonjour,

J’aimerais quelques éclaircissements sur le cheminement des paquets lorsqu’ils arrivent sur ma passerelle. Ceci afin de configurer (essayer déjà) correctement iptables.
Ma passerelle est derrière la livebox. Elle possède trois cartes (eth0, eth1 et Wlan0). Eth1 et Wlan0 sont reliés sur un bridge (br0). Eth0 pointe vers l’extérieur alors que br0 va vers le LAN.

Squid+dansguardian assurent le contrôle parental.

Lorsque un client envoi une requête vers l’exterieur, je ne sais déjà pas par où elle passe ?? Je suppose qu’elle suit ce chemin :

client1 ------bridge-------livebox-----exterieur

Au retour,

exterieur ---- livebox-----bridge----squid---dansguardian---client1

Lorsque je regarde les tables de iptables je ne vois pas très bien quel chemin suivent mes paquets. J’ai bien compris que MANGLE ne me concernait pas pour le moment.
Mais FORWARD, INPUT, OUTPUT me concernent.
Normalement les paquets traversent mon bridge (donc chaîne forward) ; mais dans ce cas, que devient INPUT et OUTPUT ??

Edit : la présentation a été modifiée suite au message posté par PascalHambourg.

#2

[DISCLAIMER: je n’ai pas fait intensément de réseau depuis des lustres, ce que je vais dire est peut être faux/obsolète]

En fait, associer les interfaces en bridge travaille au niveau lien (ethernet), pas réseau (ip), et ça fait une jonction logique entre les deux interfaces : ça rallonge logiquement ton réseau interne jusqu’à la livebox comme si elle etait branchée sur le même switch que ton bridge et qu’il n’était pas là.

Comme ce n’est plus qu’un seul périphérique, les paquets qui ne sont pas explicitement destinés à ton bridge le “touchent” juste, un peu comme les paquets du réseau, qu’ils lui soient destinés ou non, touchent ton interface physiques sans entrer dans ton noyau (c’est ce qui permet de les sniffer).

Donc >au niveau IP< ils ne sont plus sensé entrer traverser les chaines et ressortir.
Théoriquement, du coup, ça devrait être identique avec toutes les chaines, mais depuis les noyaux 2.6, le module br_netfilter introduit de force les paquets ip non destinés au bridge dans la chaine FORWARD du bridge.
(si tu DROP tout le FORWARD sur ton bridge, tu peux couper le trafic)

Du coup, ce qui passe par l’INPUT/OUTPUT de ton bridge, c’est uniquement ce qui concerne l’IP de ton bridge, pas ce qui ne fait que passer.

Tu peux toujours ajouter des règles basées sur tes interfaces physique, sur les chaines INPUT, FORWARD, et OUTPUT, en utilisant -m physdev --physdev-[in|out] eth[0|1], mais ça ne concernera le même traffic.

Si tu veux >intercepter< du trafic qui n’est pas destiné à ton bridge, par exemple pour en rediriger de manière transparente une partie vers un proxy, il faudra utiliser ebtables pour filtrer au niveau de la couche OSI lien.

Exemple: https://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxBridge

#3

çà j’ai bien compris. En fait on fait comme si le bridge n’existait pas réellement. Les paquets le traversent comme un pont pour aller là où ils doivent aller. De ce que j’ai lu, le bridge n’a pas d’ip propre en fait.

#4

çà je ne comprends pas. Il me faudrait une image (immeubles, routes, voitures,…) si c possible.

#5

J’ai lu un sujet traitant de iptables+bridge sur le forum dans lequel il était dit que pour l’interface du bridge il fallait utiliser ‘physdev’. Pourquoi dans ce cas utiliser ‘physdev’ pour les interfaces physiques eth0 et eth1 ?

#6

Je crois que c’est pour çà que j’en ai déduis que le bridge n’avait pas d’ip. C’est parceqsu"il intervient au niveau 2 et pas au 3 qui concerne les ip. Mais je n’ai certainement pas tout compris :wink:

En fait plus je lis et moins je comprends !!! C’est un peu désespérant :frowning:

Ton lien est en anglais c pas facile :smile:

#7

Avec un exemple ce sera peut-être plus facile :

un paquet qui vient de l’exterieur traverse la livebox qui l’envoie vers ma passerelle. A ce stade il passe par le pont parceque je lui ai dit de le prendre : donc règle dans la table NAT chaîne FORWARD. Autrement il ne va nulle part ?

Je repars lire des docs.

Merci

#8

Je vais rester avec mon exemple hardware:
pour transmettre un paquet sur le réseau d’une machine à une autre, l’émetteur envoie le signal sur son cable, il peut être relayé par un hub/switch, mais au final, toutes les machines le reçoivent.
A moins d’être en écoute active, seule la destination (ou les destinations dans le cas d’un broadcast), va traiter le paquet, le faire passer éventuellement par son noyau pour le traiter en fonction des chaines.
Là c’est pareil: ce qui traverse le bridge ne fait que le frôler, les paquets sont ignorés (sauf ce module qui les fait passer par le FORWARD du bridge, mais c’est une bidouille).

#9

[quote=“toto69, post:6, topic:74938”]Je crois que c’est pour çà que j’en ai déduis que le bridge n’avait pas d’ip. C’est parceqsu"il intervient au niveau 2 et pas au 3 qui concerne les ip. Mais je n’ai certainement pas tout compris[/quote] Alors si: ça dépend comment tu l’as créé, mais a priori, ton bridge doit avoir une adresse ip.
La config de debian devant être je crois de pomper du dhcp dessus automatiquement, au pire, tu dois avoir une adresse fournie sur le bridge par la livebox. Par contre, ce sont tes interfaces physiques intégrées au bridge qui ne doivent pas en avoir.[quote=“toto69, post:7, topic:74938”]un paquet qui vient de l’exterieur traverse la livebox qui l’envoie vers ma passerelle. A ce stade il passe par le pont parceque je lui ai dit de le prendre : donc règle dans la table NAT chaîne FORWARD. Autrement il ne va nulle part ?
[/quote]Non.
Un paquet qui vient de l’exterieur, traverse ta livebox pour aller >sur ton réseau<, pas vers ton bridge.
A ce stade, la livebox ne voit qu’un cable sur lequel elle envoie le paquet vers l’intérieur, elle ne sait même pas que c’est ton bridge à l’autre bout, elle sait seulement que l’adresse ip à laquelle envoyer le paquet est associé à telle adresse mac, et elle envoie le paquet dans le tuyau vers cette mac.
De son coté, le bridge qui est dans le passage peut intercepter le paquet dans son forward.

Mais je te rassure, j’ai l’impression que c’est ça parceque ça semble carré dans ma tête, mais ça fait longtemps que je ne touche pas à du réseau, donc comme je le disais plus haut, c’est peut être approxmatif, ce que je dis.

Rien de tel que les configs concrètes pour comprendre les fonctionnements du truc.

Tu veux faire quoi comme filtrage sur ce qui passe sur ton bridge ?

#10

Salut,

Désolé de te prendre du temps avec mes questions de débutant ! C’est sympa de répondre !!

Alors, de mémoire, dans la livebox, à l’installation de la passerelle, j’avavis indiqué l’adresse de la machine 192.168.1.10 (eth0); c’est à cette adresse-là que je me connecte en ssh pour administrer mon serveur. Br0 à l’adresse 172.16.10.1 et le reseau local est sur cette plage d’adresse : 172.16.10.0/16. Eth1 est vers le reseau local et n’a pas d’adresse.

root@serveur-debian:~/# ifconfig 
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.10.1  netmask 255.255.255.240  broadcast 172.16.10.15
        inet6 fe80::208:a1ff:fe6d:beef  prefixlen 64  scopeid 0x20<link>
        ether 00:08:a1:6d:be:ef  txqueuelen 1000  (Ethernet)
        RX packets 5869329  bytes 2020147971 (1.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7602643  bytes 9220918713 (8.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.10  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::216:17ff:feba:be68  prefixlen 64  scopeid 0x20<link>
        ether 00:16:17:ba:be:68  txqueuelen 1000  (Ethernet)
        RX packets 8049646  bytes 9271771503 (8.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5891685  bytes 2562394635 (2.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:08:a1:6d:be:ef  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 182230  bytes 29138613 (27.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Boucle locale)
        RX packets 307045  bytes 96610547 (92.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 307045  bytes 96610547 (92.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ea94:f6ff:feed:d20f  prefixlen 64  scopeid 0x20<link>
        ether e8:94:f6:ed:d2:0f  txqueuelen 1000  (Ethernet)
        RX packets 5877711  bytes 2105610825 (1.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7811134  bytes 9394851124 (8.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ce que je veux faire ? Simple : tout fermé pour ne laisser passer que ce que je veux :smile:

Donc je dois absolument comprendre comment fonctionne tout le système.

J’ai aussi un autre post d’ouvert ‘android-iptables’ actuellement. va jeter un oeil j’y ai mis des infos complémentaires.

Pour le moment, je cherche à comprendre ce qui se passe à l’étape de routage après la table NAT. Qui fait ce routage et où a-t-il lieu ?

Je viens de regarder dans ma Livebox et j’ai bien une ‘dmz’ vers 192.168.1.10 avec l’adresse mac de eth0.

#11

Ca existe les copier collers d’url, pour simplifier la tache à ton interlocuteur. :smiley:

#12

[quote=“toto69, post:10, topic:74938”]
Salut,[/quote]Yo ![quote=“toto69, post:10, topic:74938”]Désolé de te prendre du temps avec mes questions de débutant ! C’est sympa de répondre !![/quote]No PB. Ca m’est utile à moi aussi.[quote=“toto69, post:10, topic:74938”]Alors, de mémoire, dans la livebox, à l’installation de la passerelle, j’avavis indiqué l’adresse de la machine 192.168.1.10 (eth0); c’est à cette adresse-là que je me connecte en ssh pour administrer mon serveur.[/quote]Alors ça, c’est un reliquat de ta config avant le bridge.
En fait, je pense que si tu ne lui affecte aucune adresse dans ton /etc/network/interfaces (tu laisses juste la ligne iface eth0 inet static), ça fonctionnera tout pareil.
Tu ne pourras plus accéder à ton serveur par sa vieille adresse, mais tu pourras utiliser celle de br0.

[quote=“toto69, post:10, topic:74938”]Br0 à l’adresse 172.16.10.1 et le reseau local est sur cette plage d’adresse : 172.16.10.0/16.[/quote]Oui, c’est la livebox qui attribue les ips, et ton bridge, qui est en dhcp par défaut, s’est vu attribuer la 10.
Tu peux rendre ça fixe, ou même transposer la config que tu as sur eth1 actuellement dans ton /etc/network/interfaces, pour utiliser ta vieille adresse 192.168.1.10 sur br0.[quote=“toto69, post:10, topic:74938”]Eth1 est vers le reseau local et n’a pas d’adresse.[/quote]Normal, à aucun moment il n’y a eu besoin de la cibler en ip, il lui suffit de son arp pour recevoir les paquets du réseau qu’elle a à retransmettre.

[quote=“toto69, post:10, topic:74938”]Ce que je veux faire ? Simple : tout fermé pour ne laisser passer que ce que je veux :smile:[/quote]ça commence par iptables -P FORWARD DROP
Là, il ne te reste plus qu’à ouvrir un par un tous les flux que tu veux laisser passer.
A commencer par tout ce qui circule sur lo, sinon, ça va raler.
Un bon exemple de script mini que je viens de voir (merci google):
http://www.brunovalentin.com/linux/bridge-firewall-linux/

[quote=“toto69, post:10, topic:74938”]Donc je dois absolument comprendre comment fonctionne tout le système.[/quote]Fais. Tu comprendras aprés pourquoi ça marche, et tu auras gagné du temps.[quote=“toto69, post:10, topic:74938”]Pour le moment, je cherche à comprendre ce qui se passe à l’étape de routage après la table NAT. Qui fait ce routage et où a-t-il lieu ?[/quote]Depuis le début, je te répète qu’il n’y a pas de routage, pas de nat. Les paquets qui circulent entre ton réseau et ta livebox sont sur ton réseau local, ils ne sont pas routés. Ils passent bien concrètement par tes dispositifs physiques eth[0|1], mais ils ne sont pas routés, il n’y a pas de manipulation dessus qui soit vraiment possibles au sauf à les bloquer.
La seule correspondance d’adresses ip qui existe dans ta config se fait au niveau de ta livebox, ton bridge ne route pas, il transmet juste les paquets d’un coté à l’autre.[quote=“toto69, post:10, topic:74938”]Je viens de regarder dans ma Livebox et j’ai bien une ‘dmz’ vers 192.168.1.10 avec l’adresse mac de eth0.[/quote]Ca, c’est indépendant du traffic aller/retour de tes clients réseau, ta box est juste configurée pour renvoyer tel quel tout le trafic venant de l’internet qui n’est pas le résultat d’une demande depuis un client à l’interieur.
Si tu fais des ajustements sur l’adresse de ton serveur comme je le suggérais plus haut, tu seras peut être obligé de reconfigurer ça, pour par exemple accéder à ton serveur/bridge depuis l’extérieur en ssh, en y accédant par l’ip de ta livebox.

#13

Une interface qui fait partie d’un pont ne devrait normalement pas avoir d’adresse IP propre, à moins de mettre en place des choses un peu sophistiquées comme un “pont-routeur” avec la chaîne BROUTING d’ebtables.

D’autre part, même s’il est possible de faire du NAT avec les trames qui traversent un pont, mon avis est que ce n’est pas une bonne idée, cette violation de la separation des couches Ethernet et TCP/IP pouvant causer des problèmes notamment avec la gestion des adresses MAC. Etant donné qu’un pont sert à relier des parties d’un même réseau (et non interconnecter des réseaux différents comme le fait un routeur), l’adressage IP devrait être le même côté box et côté LAN (ce qui ne semble pas être ton cas), rendant inutile la mise en place de NAT.

Peux-tu fournir la sortie des commandes suivantes pour voir quelles interfaces font partie du pont br0 ?

ip addr brctl show

PS : A quoi sert l’interface wifi wlan0 ?

#14

Seulement addressée en inet6 et avec 1.9Gib de traffic dessus, c’est normal ?

Ca serait peut être bien de l’intègrer au bridge, non ?

#15 
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether 00:08:a1:6d:be:ef brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:16:17:ba:be:68 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:17ff:feba:be68/64 scope link 
       valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether e8:94:f6:ed:d2:0f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ea94:f6ff:feed:d20f/64 scope link 
       valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:08:a1:6d:be:ef brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.1/28 brd 172.16.10.15 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::208:a1ff:fe6d:beef/64 scope link 
       valid_lft forever preferred_lft forever

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.0008a16dbeef	no		eth1
							wlan0
#16

Je suis certain d’avoir lu çà quelque part. C’est peut-être pour çà que je ne comprends pas pourquoi br0 a une adresse ip.

#17 
Il est bizarre mon bridge !! eth0 n'est pas dedans !!

auto eth0
iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
#iface eth0 inet6 auto


## Pont entre les deux interfaces (bridge)
auto br0
iface br0 inet static
bridge_ports eth1
address 172.16.10.1
network 172.16.10.0
netmask 255.255.255.240


##hostapd dans le fichier interface
auto wlan0 
iface wlan0 inet manual
hostapd /etc/hostapd/hostapd.conf

##interface to ethernet lan
auto eth1
iface eth1 inet manual
#18

Elle fait partie du réseau 172.16.10.0/16. Elle permet aux machines du reseau de sortir sur le reseau exterieur tout en étant filtré par mon squid+dansguardian.

#19

C’est bien ce que je soupçonnais. L’interface wifi wlan0 est dans le pont br0 avec eth1 et configurée en point d’accès avec hostapd (autrement elle ne pourrait pas être pontée), et l’interface eth0 côté box n’est pas dans le pont. Tu as donc une configuration relativement classique avec un pont côté LAN entre les interfaces ethernet et wifi, et du routage+NAT entre ce pont et l’interface Ethernet côté extérieur (box). C’est le mode de fonctionnement standard de tous les routeurs+switch+wifi SOHO type Linksys WRT54.

Le pont br0 ne fait que la jonction entre les deux parties Ethernet et wifi du réseau LAN 172.16.10.0/28 (et non /16 - pourquoi avoir choisi une plage aussi réduite ?). Il y a deux réseaux distincts, celui-ci et le réseau côté box 192.168.1.0/24 connecté à eth0. Comme il se doit, la communication entre ces deux réseaux utilise les fonctions de routage IP du noyau, avec iptables pour le filtrage et le NAT.

EDIT : ce qui suit n’est vrai qu’avec les noyaux antérieurs à 3.18 ou lorsque le module br_netfilter du noyau est chargé, manuellement ou parce qu’on utilise la correspondance “physdev” dans une règle iptables.

Là où ça se complique un peu, c’est que par défaut les trames Ethernet ou wifi transportant des paquets IP qui entrent par les interfaces du pont, eth1 ou wlan0, passent aussi par iptables même si elles ne sont pas destinées à la passerelle. Il faut donc faire attention à l’écriture des règles iptables pour ne pas bloquer involontairement les communications entre les segments Ethernet et wifi du LAN. Si tu ne veux pas qu’iptables filtre ces communications, tu peux désactiver cette fonctionnalité en réglant /proc/sys/net/bridge/bridge-nf-call-iptables (et les autres) à 0. Cela n’empêche pas iptables de filtrer les paquets destinées à la passerelle ou au-delà.

#20

Va falloir que je me fasse un petit schéma de tout çà avec par dessus les tables et les chaines de iptables pour comprendre ce que tu dis là :