Peu importe, je verrais plus tard.
Sachant qu’un routeur a une interface dans chaque reseau auquel il est connecté, mon ‘Serveur-debian’ est une passerelle et un routeur !
Eth0 est connecté au réseau 192.168.1.0/24 et br0 (-i) au réseau 172.16.10.0/28
En fait “passerelle” est un terme historique vague et impropre dont l’usage est déconseillé. On devrait uniquement parler de “routeur” qui est le terme approprié.
Je continue donc à comprendre tout cela :
Lorsque un paquet arrive à ma Livebox depuis l’extérieur, ma Livebox est forcément un routeur. Car elle va scanner, via sa table de routage, les routeurs auxquels elle peut envoyer le paquet (les trames plutôt je crois, non ?). Depuis une machine locale :
Destination Passerelle
default 172.16.10.1
Depuis mon serveur-debian :
Destination Passerelle
default livebox.homePourquoi tu dis en parlant de le route que [quote]par défaut, qui est ici la meilleure route (car la seule) correspondant à l’adresse de destination[/quote]
J’ai du mal à percevoir la notion de ‘route par défaut’ mais est-ce vraiment important ?!
Je ne comprends pas les 0.0.0.0 dans la colonne passerelle.
Dans ma tête (ou plutôt sur ma feuille à côté de moi !!), j’ai le schéma suivant :
[quote]Reseaux -------------------Passerelle
192.168.1.0/24 ----------192.168.1.10
172.16.10.0/24 ----------172.16.10.1[/quote]
J’ai lu que la ‘route par défault’ est celle qu’on ne peut pas atteindre de là où on est. Donc depuis mon serveur-debian, il s’agit du reseau exterieur !!
Donc la passerelle de la route par défault est 192.168.1.1, la Livebox.
De même, depuis mon pc debian9 sur le LAN, la passerelle de la route par défault est l’interface du routeur serveur-debian située du côté du LAN donc 172.16.10.1
Mais je ne sais pas non plus ce qu’est le reseau link-local ?
[quote]root@debian9:/home/toto69# route
Table de routage IP du noyau
Destination--------------------------Passerelle
default -------------------------------172.16.10.1
link-local -----------------------------0.0.0.0
172.16.10.0 --------------------------0.0.0.0 [/quote]
Première réponse : 0.0.0.0 serait l’adresse de la machine.
Mais quand 0.0.0.0 est dans la colonne réseau ? La route par défaut ??
Petite remarque préliminaire : par défaut, la commande route résoud les adresses IP en noms, ce qui masque les adresses IP réelles pour qui ne connaît pas la correspondance de ces noms. L’option -n empêche cette résolution.
Alternativement, la commande ip route affiche les routes sous une forme plus moderne et compacte : notation CIDR au lieu du masque, pas de séparation entre l’adresse et la longueur du préfixe, pas d’adresse de passerelle à 0.0.0.0 si la route n’en comporte pas, adresse source par défaut… Je la recommande, d’autant que le paquet net-tools qui contient la commande route ne fait plus partie du système de base depuis Stretch.
Oui, la livebox est un routeur IP. Cela signifie essentiellement qu’elle a la capacité de retransmettre les paquets IP qu’elle reçoit et qui ne lui sont pas destinés, comme ta passerelle et contrairement à une simple “hôte” (poste client ou serveur non routeur). Elle a une table de routage de forme similaire à celle de ta passerelle, contenant une route pour la plage d’adresses de son propre LAN 192.160.1.0/24, une route par défaut via l’interface ADSL ou fibre, et d’éventuelles routes statiques créées par l’utilisateur via l’interface de configuration.
Comme n’importe que routeur qui doit retransmettre un paquet IP (on parle de paquet IP et de trame ethernet), ou n’importe quel hôte qui doit émettre un paquet IP, elle va comparer l’adresse de destination du paquet à chaque route de la table de routage et sélectionner la route qui correspond la plus précise, c’est-à-dire dont la destination a le plus long préfixe ou masque. La longueur est le nombre de bits à 1 du masque. 255.255.255.255 a une longueur de 32 ; 0.0.0.0 a une longueur de 0 ; 255.255.255.0 a une longueur de 24.
La route sélectionnée contient des informations sur la façon dont le paquet doit être envoyé : par quelle interface de sortie, et via quel routeur/passerelle s’il y en a un. Si la route ne définit pas de routeur, elle est directe ; l’adresse MAC de la destination est recherchée et le paquet est envoyé à cette adresse MAC. Si la route définit un routeur, elle est indirecte ; l’adresse MAC de ce routeur est recherchée et le paquet est envoyé à cette adresse MAC.
La route par défaut est, comme son nom l’indique, la route qui est sélectionnée quand aucune autre route plus précise ne correspond à l’adresse de destination du paquet à router. Le préfixe de destination de la route par défaut englobe toutes les adresses possibles, de 0.0.0.0 à 255.255.255.255. Son masque à 0.0.0.0 a une taille de 0 car il signifie qu’aucun bit de l’adresse n’a besoin de correspondre. Par convention tous les bits non significatifs d’un préfixe sont à 0 (comme dans 192.160.1.0/24, où le dernier octet n’est pas significatif), donc comme aucun bit n’est significatif l’adresse est aussi 0.0.0.0.
A noter qu’il n’y a pas toujours une route par défaut. Dans un réseau isolé non connecté à internet, une route par défaut n’est pas utile. Les adresses hors du réseau local ne sont pas joignable.
Une route qu’on ne peut pas atteindre, c’est une destination injoignable. Ce n’est pas le cas de la route par défaut qui permet au contraire d’atteindre toutes les destinations.
Tu veux peut-être dire que c’est une route indirecte qui comporte une adresse de routeur/passerelle et permet d’atteindre les destinations au-delà du réseau local. C’est généralement vrai, mais ce n’est pas une propriété exclusive de la route par défaut. Ce qui caractérise la route par défaut, c’est son préfixe de destination : 0.0.0.0/0, soit toutes les adresses.
Le préfixe link-local, 169.254.0.0/16, est utilisé par le protocole Zeroconf pour la configuration automatique d’un réseau local sans DHCP ni routeur. Cette plage d’adresses n’est pas routable, elle ne peut pas servir à communiquer avec d’autres réseaux.
J’ai voulu vérifier mes routes. Alors j’ai fait un ‘tcpdump’ Depuis mon LAN. Ben j’ai dû rater un truc !!
root@debian9:~# tcpdump -i br0
tcpdump: br0: No such device exists
(SIOCGIFHWADDR: No such device)
Je replonge dans mes lectures
Heu, comment comptes-tu “vérifier tes routes” avec tcpdump au juste ?
Note : comme la commande route, par défaut tcpdump résoud les adresses (et les ports) en noms, ce qui peut nuire à la lisibilité. L’option -n désactive cette résolution et force l’affichage des adresses et ports sous forme numérique.
Le nom d’une interface est une notion locale à la machine et br0 n’existe que sur la passerelle.
J’avais bien raté un truc !
Je voulais voir ce qui se passait en faisant un ‘ping 192.168.1.1’ depuis mon poste sur le LAN.
root@debian9:~# tcpdump -v -i wlp5s0b1 icmp
tcpdump: listening on wlp5s0b1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:04:19.779706 IP (tos 0x0, ttl 64, id 19385, offset 0, flags [DF], proto ICMP (1), length 84)
172.16.10.9 > 192.168.1.1: ICMP echo request, id 17469, seq 1, length 64
21:04:19.782892 IP (tos 0x0, ttl 63, id 36526, offset 0, flags [none], proto ICMP (1), length 84)
192.168.1.1 > 172.16.10.9: ICMP echo reply, id 17469, seq 1, length 64
Ben çà marche pas ! Je pensais voir apparaître 172.16.10.1 quelque part qui pour moi est la route par défault pour atteindre 192.168.1.1
Je suis certainement un peu saturé par toutes mes lectures et exercices de la journée !!! Je lirai ta réponse demain matin.
Demain, je me relance dans iptables. Je devrais y voir plus claire maintenant.
L’adresse IP d’un routeur ne se trouve pas dans les paquets IP qui transitent par lui. Ces paquets ne contiennent que les adresses de la source et de la destination, le routeur n’étant ni l’une ni l’autre mais un intermédiaire.
Pour voir l’adresse IP du routeur, il faut capturer les paquets ARP de la résolution d’adresse IP du routeur en adresse MAC.
C’est apparu dans le noyau 3.18.
Je ne comprends toujours pas cette phrase là. Le ‘par défaut’ laisse supposer que c’est inévitable. Quant à la mention ‘passent aussi par iptables’ je ne comprends tout simplement pas.
Ou alors je comprends que : lorsqu’une trame arrive dans le bridge par wlan0 et que le bridge, après identification de l’adresse MAC, autorise son transfert vers eth1, il refile la trame à Netfilter pour analyse (voir si une chaine n’interdit pas le transfert dans Iptables) avant de la faire passer à eth1.
Pour moi il y a maintenant 2 cas de figures :
-Soit on a deux réseaux distincts de chaque côté du routeur ‘Serveur-debian’ (c’est mon cas) et on a du routage pour relier les paquets sur la couche 3 IP car ils n’appartiennent pas au même réseau.Ce qui revient à dire que j’ai une interface d’un côté et une autre de l’autre. Or si j’ai bien eth0 du côté de la Livebox, j’ai br0 de l’autre côté. Et br0 est une interface virtuelle.
Si br0 ne sert qu’a relier des interfaces d’un même réseau (couche 2 ethernet),je n’ai donc aucune interface physique qui me relie au LAN.
Sauf -i et -o de l’interface br0. (-o) qui me relie à Serveur-debian et (-i) qui me relie au LAN.
Iptables me sert dans ce cas au filtrage (mes histoires de port udp,…).
Si je veux accéder à mes cartes eth1 et wlan0 je dois utiliser le module ‘physdev’.
-Soit on a un seul reseau de chaque côté de la passerelle (ce n’est pas mon cas) donc je passe mon chemin.
Voilà où j’en suis. Ce qui explique les règles que j’ai écrites à la fin de dans l’autre post ‘iptables+android’.
Je relis sans cesse toutes les réponses. Certaines choses me parlent maintenant mais j’ai toujours de grosses zones d’ombre.
Au contraire, “par défaut” laisse entendre que c’est évitable. Je ne l’aurais pas écrit si c’était obligatoire. Et j’avais indiqué dans la suite du paragraphe comment désactiver ce comportement.
D’autre part, j’avais écrit ce paragraphe alors que je ne savais pas encore que cette fonctionnalité de filtrage des trames pontées par netfilter avait été déportée du module bridge (qui contient la fonctionnalité de pontage) vers un nouveau module br_netfilter depuis le noyau 3.18. Je viens d’éditer le message et d’ajouter la précision suivante, déjà présente dans mes messages ultérieurs :
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.
Dans ton cas, avec un noyau 4.9 tant que tu ne charges pas explicitement le module br_netfilter et que tu n’utilises pas “physdev” dans une règle iptables, les trames pontées ne passent pas par netfilter et tu n’es pas concerné.
Exact, excepté que le pont n’attend pas de savoir où va aller la trame pour la soumettre à certaines chaînes d’iptables. Voir le diagramme de netfilter.
Oui.
Si : eth1 et wlan0. Mais elles sont invisibles pour la couche IP, et pour iptables lorsqu’il est appelé depuis la couche IP pour un paquet routé. Si iptables est appelé depuis la couche ethernet pour un paquet ponté, il peut voir les interfaces physiques avec la correspondance physdev.
Tu devrais vraiment arrêter avec ces (-i) et (-o). Cela n’apporte rien que de la confusion. -i et -o ne sont que des options d’iptables pour spécifier l’interface d’entrée et de sortie. Ils ne caractérisent en rien une interface qui, je le répète, est bidirectionnelle.
Oui, pour les trames pontées. Note qu’ebtables permet aussi de faire du filtrage simple basé sur les ports TCP ou UDP. Mais contrairement à iptables il ne permet pas d’utiliser le suivi d’état de connexion (state NEW,ESTABLISHED,RELATED…) qui est bien pratique, voire indispensable, pour gérer les flux.
En fait c’est bien ton cas puisque tu as le même réseau sur eth1 et wlan0.
Tu es dans un troisième cas de figure, hybride : routage + pontage.
Tu utilises iptables pour gérer le trafic routé entre br0 et eth0, mais tu as aussi la possibilité de l’utiliser pour géré le trafic ponté entre wlan0 et eth1. Pour le moment cette possibilité n’est pas activée car le module br_netfilter n’est pas chargé. Si tu décides de l’activer, cela compliquera la création des règles iptables car il n’y a pas deux jeux de règles séparés pour les paquets routés et les paquets pontés mais un seul jeu de règles qui s’applique aux deux types de paquets, et ce sont les règles elles-mêmes qui doivent distinguer entre les deux.
Donc je repose ma question : as-tu besoin de faire du filtrage sur les trames pontées entre wlan0 et eth1, c’est-à-dire le trafic entre les segments ethernet et wifi du LAN ? As-tu besoin de faire du filtrage sur les paquets routés provenant du LAN en fonction de l’interface physique ?
Si non aux deux questions, on en reste là.
Si oui, quel type de filtrage ? S’il s’agit de filtrage simple qui peut être réalisé avec ebtables, inutile d’activer le filtrage des trames par netfilter.
ça y est, je commence enfin à comprendre de quoi on parle et où on va !
C’est marrant que tu me poses cette question là. Je me la suis posé ce matin pour la première fois ! Eh bien je ne vois pas à quoi çà me servirait !?! A l’origine, ce pont a été créé pour unifier la voie d’accès à eth0. Donc ce n’est q’un seul et même reseau.
Faut que je réfléchisse un peu ! Il est vrai que seul l’interface wlan0 est concernée par le filtrage des ports utilisés par certains services android.
[quote=“toto69, post:54, topic:74938”]
Eh bien je ne vois pas à quoi çà me servirait !?![/quote]
Je ne peux pas répondre à ta place. Par exemple tu pourrais vouloir interdire certaines communications entre un poste en wifi et un poste en ethernet.
Qu’entends-tu par “unifier la voie d’accès à eth0” et en quoi est-il important que ce soit un seul et même réseau ? Pourquoi deux réseaux LAN ethernet et wifi distincts ne conviendraient-ils pas ?
Je pense que c’est à cause de la gestion du reseau. moins y en a à gérer plus c’est simple.
Mais il faut que j’écrive tout çà sur papier. J’y verrai plus claire.[quote=“PascalHambourg, post:55, topic:74938”]
en quoi est-il important que ce soit un seul et même réseau ?
[/quote]
Pour les mêmes raisons qu’au-dessus.
Les deux reseaux se rejoignent pour ne former qu’un seul.
Quel rapport avec eth0 ?
eth0 est l’interface de sortie de mon routeur vers le réseau extérieur. Dans mon esprit, on ne faisait qu’un seul et même chemin. Une seule route en somme pour tous les paquets. Un peu comme une voie de circulation. C’est un peu sommaire comme illustration mais j’ai besoin de me représenter les choses visuellement pour les comprendre.
C’est autant l’interface d’entrée depuis le réseau extérieur. Les interfaces et les flux sont bidirectionnels.
Ça, ce n’est pas possible. Deux interfaces (br0 et eth0) et deux réseaux (LAN et extérieur), donc au moins deux routes.