Re: [FRnOG] [TECH] iptables me rendra fou
Merci pour vos réponses malheureusement aucune piste ne me permet une résolution. J'y reviendrais mais la plus envie Le lun. 28 janv. 2019 à 10:59, Guillaume Tournat a écrit : > Le nom peut être rendu déterministe par une règle udev ou par inscription > de la MAC address dans les fichiers /etc/sud config/network-scripts/ifcfg-* > > > > Le 28 janv. 2019 à 09:09, Alexandre PIERRET < > alexandre.pierret-fr...@loiklo.net> a écrit : > > > > De mémoire, en RH6 et avant, le système nomme initialement les ethX dans > > l’ordre d’apparition, puis un script vient les renommer (pour suivre le > > fichier de conf) par un jeu de taquin. Le problème est que ce script > n’est > > pas atomique et pendant le jeu de taquin, si une interface est détecté > elle > > peut prendre la place d’une interface cible (du jeu de taquin) pendant le > > renommage. Et donc l'interface 'en cours de renommage' n'a pas de nom car > > la place a déjà été prise entre temps. > > > > En RH7, par défaut, les interfaces sont nommées en fonction de leur > > emplacement physique et donc elles ont leur nom définitif dès la > détection. > > Etant donné ce fonctionnement par défaut, il n’y a plus le script de > > renommage dans RH7, le nom est donné par ordre d'apparition. > > > > Si on repasse au nommage legacy (ethX) sur du RH7, les interfaces sont > donc > > nommées uniquement suivant leur ordre de détection. Donc à chaque reboot, > > elles peuvent changer de nom, on a eu le cas sur une sonde réseau > notamment > > qui possède un grand nombre d'interfaces. > > > > Sauf à vouloir implémenter un système maison de nommage d'interface, il > est > > fortement déconseillé de repasser en nommage legacy sur une machine qui > > possède plus d'une interface à partir de la RH7. > > > > Alex > > > > On Sun, Jan 27, 2019 at 6:34 PM Jonathan Leroy < > jonat...@unsigned.inikup.com> > > wrote: > > > >>> Le dim. 27 janv. 2019 à 16:54, Johan Fleury a > écrit : > >>> Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il faut > >> reconnaître que ce dernier a des features intéressantes : validation > >> DNSSEC, DNS over TLS avec fallback, etc. > >> > >> Oh la la malheureux, je te conseille de retirer ça, de présenter > >> tes excuses, de dire que la journée n’avait pas été facile, etc... :) > >> > >> La dernière fois que j’ai dit publiquement du bien de systemd (sur > >> FRSAG, pas ici), les gens d’accord avec moi sont venus me le dire > >> majoritairement *en privé*, parce que tu comprends, l’avouer > >> publiquement c’est prendre le risque de se faire traiter de tous les > >> noms (j’exagère à peine). > >> > >> systemd, toutes les distribs y sont passées pour une raison : le tas > >> de script bash utilisés précédemment est une horreur à maintenir et > >> dans certains cas à utiliser. Ceux qui s’y opposent le font soit pour > >> suivre le mouvement, soit parce qu’ils ne veulent pas trop remettre en > >> question tout ce qu’ils ont appris il y a des années. Sûrement les > >> mêmes qui t’expliquent qu’il n’y a pas de souci à utiliser qmail en > >> 2019. > >> > >> > >> --- > >> Liste de diffusion du FRnOG > >> http://www.frnog.org/ > >> > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Le nom peut être rendu déterministe par une règle udev ou par inscription de la MAC address dans les fichiers /etc/sud config/network-scripts/ifcfg-* > Le 28 janv. 2019 à 09:09, Alexandre PIERRET > a écrit : > > De mémoire, en RH6 et avant, le système nomme initialement les ethX dans > l’ordre d’apparition, puis un script vient les renommer (pour suivre le > fichier de conf) par un jeu de taquin. Le problème est que ce script n’est > pas atomique et pendant le jeu de taquin, si une interface est détecté elle > peut prendre la place d’une interface cible (du jeu de taquin) pendant le > renommage. Et donc l'interface 'en cours de renommage' n'a pas de nom car > la place a déjà été prise entre temps. > > En RH7, par défaut, les interfaces sont nommées en fonction de leur > emplacement physique et donc elles ont leur nom définitif dès la détection. > Etant donné ce fonctionnement par défaut, il n’y a plus le script de > renommage dans RH7, le nom est donné par ordre d'apparition. > > Si on repasse au nommage legacy (ethX) sur du RH7, les interfaces sont donc > nommées uniquement suivant leur ordre de détection. Donc à chaque reboot, > elles peuvent changer de nom, on a eu le cas sur une sonde réseau notamment > qui possède un grand nombre d'interfaces. > > Sauf à vouloir implémenter un système maison de nommage d'interface, il est > fortement déconseillé de repasser en nommage legacy sur une machine qui > possède plus d'une interface à partir de la RH7. > > Alex > > On Sun, Jan 27, 2019 at 6:34 PM Jonathan Leroy > wrote: > >>> Le dim. 27 janv. 2019 à 16:54, Johan Fleury a écrit : >>> Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il faut >> reconnaître que ce dernier a des features intéressantes : validation >> DNSSEC, DNS over TLS avec fallback, etc. >> >> Oh la la malheureux, je te conseille de retirer ça, de présenter >> tes excuses, de dire que la journée n’avait pas été facile, etc... :) >> >> La dernière fois que j’ai dit publiquement du bien de systemd (sur >> FRSAG, pas ici), les gens d’accord avec moi sont venus me le dire >> majoritairement *en privé*, parce que tu comprends, l’avouer >> publiquement c’est prendre le risque de se faire traiter de tous les >> noms (j’exagère à peine). >> >> systemd, toutes les distribs y sont passées pour une raison : le tas >> de script bash utilisés précédemment est une horreur à maintenir et >> dans certains cas à utiliser. Ceux qui s’y opposent le font soit pour >> suivre le mouvement, soit parce qu’ils ne veulent pas trop remettre en >> question tout ce qu’ils ont appris il y a des années. Sûrement les >> mêmes qui t’expliquent qu’il n’y a pas de souci à utiliser qmail en >> 2019. >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On 27/01/2019 18:33, Jonathan Leroy wrote: La dernière fois que j’ai dit publiquement du bien de systemd (sur FRSAG, pas ici), les gens d’accord avec moi sont venus me le dire majoritairement *en privé*, parce que tu comprends, l’avouer publiquement c’est prendre le risque de se faire traiter de tous les noms (j’exagère à peine). Je pense que l'on peut avoir une discussion modéré même sur systemd. systemd, toutes les distribs y sont passées pour une raison : le tas de script bash utilisés précédemment est une horreur à maintenir et dans certains cas à utiliser. Ceux qui s’y opposent le font soit pour suivre le mouvement, soit parce qu’ils ne veulent pas trop remettre en question tout ce qu’ils ont appris il y a des années. Sûrement les mêmes qui t’expliquent qu’il n’y a pas de souci à utiliser qmail en 2019. Je suis assez d'accord pour dire que l'ensemble des scripts initV utilisées dans les distros linux pre-systemd étaient globalement assez bordéliques et difficile à maintenir. On a notamment eu quelques horreurs coté Debian quand ils ont commencé à introduire le parallélisme. Comme je disais systemd aura quand même apporté un format standard de configuration, un jeu de commande cohérent pour gérer l'initialisation des services (encore que sur ce point on pourrait discuter), l'ajout de quelques fonctionnalités intéressantes coté sandboxing. Personne ne l'avoue en effet mais personne ne reviendrais en arrière sur ces points. En revanche on peut tout de même critiquer de nombreux points. Premièrement mais ce n'est pas spécifiquement lié à systemd, mais l'intégration dans les différentes distos est très disparate (debian tu te reconnaîtras); Deuxièmement : systemd et son écosystème ont effectivement un coté agaçant et prendre en charge des parties qui n'ont rien a voir avec l'init (alors qu'il existe des démons qui le font très bien, ntpd, unbound me semble ok). Il existe aussi de nombreuses alternatives qui seraient à considérer. Openrc et ses dérivés, runit, s6, etc... Vous l'aurez compris ma préférence va toujours à l'init des BSD (simple, clair, Kiss). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Hello, Si c’est des machines virtuelles, tu as aussi un filtre possible au niveau de l’hyperviseur dans les EBtables. j’en ai meme vu dans des swiths/AP (ubiquiti) .. a debug une galère… y’a pas qu’IPtables qui rend fou… Ebtables aussi ^^ On 25 January 2019 at 17:07:47, Kevin Thiou (kevinth...@gmail.com) wrote: Bonjour, bonsoir, depuis quelques temps je me bats avec iptables pour un accès tout con mais que je ne parviens pas à faire fonctionner. ce que je souhaite : -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour je vois les paquets arriver sur l'interface de la machine iptables avec un tcpdump : tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes 16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr 0,nop,wscale 7], length 0 16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr 0,nop,wscale 7], length 0 tous les prerouting (raw, mangle, nat) sont à accept. iptables -vL -t mangle -n Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 17G packets, 13T bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes) pkts bytes target prot opt in out source destination iptables -vL -t raw -n Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes) pkts bytes target prot opt in out source destination iptables -vL -t raw -n Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes) pkts bytes target prot opt in out source destination j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à l'autoriser, j'ai donc mis les lignes suivantes : iptables -S FORWARD -P FORWARD DROP -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO -A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO et j'ai rien dans les logs. Où peuvent donc passer ces paquets ? Merci de votre aide. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On dim. 27 janv. 10:53:51 2019, Johan Fleury wrote: > Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il > faut reconnaître que ce dernier a des features intéressantes : > validation DNSSEC, DNS over TLS avec fallback, etc. Mais aussi 8.8.8.8 en dur… Pour le DNSSEC et DoT, unbound le fait déjà depuis des années. -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
De mémoire, en RH6 et avant, le système nomme initialement les ethX dans l’ordre d’apparition, puis un script vient les renommer (pour suivre le fichier de conf) par un jeu de taquin. Le problème est que ce script n’est pas atomique et pendant le jeu de taquin, si une interface est détecté elle peut prendre la place d’une interface cible (du jeu de taquin) pendant le renommage. Et donc l'interface 'en cours de renommage' n'a pas de nom car la place a déjà été prise entre temps. En RH7, par défaut, les interfaces sont nommées en fonction de leur emplacement physique et donc elles ont leur nom définitif dès la détection. Etant donné ce fonctionnement par défaut, il n’y a plus le script de renommage dans RH7, le nom est donné par ordre d'apparition. Si on repasse au nommage legacy (ethX) sur du RH7, les interfaces sont donc nommées uniquement suivant leur ordre de détection. Donc à chaque reboot, elles peuvent changer de nom, on a eu le cas sur une sonde réseau notamment qui possède un grand nombre d'interfaces. Sauf à vouloir implémenter un système maison de nommage d'interface, il est fortement déconseillé de repasser en nommage legacy sur une machine qui possède plus d'une interface à partir de la RH7. Alex On Sun, Jan 27, 2019 at 6:34 PM Jonathan Leroy wrote: > Le dim. 27 janv. 2019 à 16:54, Johan Fleury a écrit : > > Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il faut > reconnaître que ce dernier a des features intéressantes : validation > DNSSEC, DNS over TLS avec fallback, etc. > > Oh la la malheureux, je te conseille de retirer ça, de présenter > tes excuses, de dire que la journée n’avait pas été facile, etc... :) > > La dernière fois que j’ai dit publiquement du bien de systemd (sur > FRSAG, pas ici), les gens d’accord avec moi sont venus me le dire > majoritairement *en privé*, parce que tu comprends, l’avouer > publiquement c’est prendre le risque de se faire traiter de tous les > noms (j’exagère à peine). > > systemd, toutes les distribs y sont passées pour une raison : le tas > de script bash utilisés précédemment est une horreur à maintenir et > dans certains cas à utiliser. Ceux qui s’y opposent le font soit pour > suivre le mouvement, soit parce qu’ils ne veulent pas trop remettre en > question tout ce qu’ils ont appris il y a des années. Sûrement les > mêmes qui t’expliquent qu’il n’y a pas de souci à utiliser qmail en > 2019. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Le dim. 27 janv. 2019 à 16:54, Johan Fleury a écrit : > Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il faut > reconnaître que ce dernier a des features intéressantes : validation DNSSEC, > DNS over TLS avec fallback, etc. Oh la la malheureux, je te conseille de retirer ça, de présenter tes excuses, de dire que la journée n’avait pas été facile, etc... :) La dernière fois que j’ai dit publiquement du bien de systemd (sur FRSAG, pas ici), les gens d’accord avec moi sont venus me le dire majoritairement *en privé*, parce que tu comprends, l’avouer publiquement c’est prendre le risque de se faire traiter de tous les noms (j’exagère à peine). systemd, toutes les distribs y sont passées pour une raison : le tas de script bash utilisés précédemment est une horreur à maintenir et dans certains cas à utiliser. Ceux qui s’y opposent le font soit pour suivre le mouvement, soit parce qu’ils ne veulent pas trop remettre en question tout ce qu’ils ont appris il y a des années. Sûrement les mêmes qui t’expliquent qu’il n’y a pas de souci à utiliser qmail en 2019. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On Sun, Jan 27, 2019 at 10:53:51AM -0500, Johan Fleury wrote: > Pour le nommage des interfaces, c’est la même saloperie que sous les BSD > pourtant je ne vois personne faire d’appel au meurtre de leur développeurs. > Pourrais-tu élaborer là-dessus ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On 27/01/2019 16:53, Johan Fleury wrote: Pour le nommage des interfaces, c’est la même saloperie que sous les BSD pourtant je ne vois personne faire d’appel au meurtre de leur développeurs. Et puis bon, pour le désactiver c’est une histoire de 13 caractères à rajouter dans la configuration de Grub. OK pour la partie c'est facile à désactiver. Par contre personnelemnt je trouve cela très bien la manière de faire BSD, tant le nommage que l'init (KISS quoi). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Le 26/01/2019 à 10:33, Jérôme Nicolle a écrit : > Bon, on est plus exactement trolldi > Dis le mec qui passe le reste de son mail à écrire SytemD/Linux. Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il faut reconnaître que ce dernier a des features intéressantes : validation DNSSEC, DNS over TLS avec fallback, etc. D’ailleurs resolved n’est pas activé par défaut dans Debian, pas plus que networkd et de son côté, timesyncd est désactivé dès qu’un autre service NTP est installé. Pour le nommage des interfaces, c’est la même saloperie que sous les BSD pourtant je ne vois personne faire d’appel au meurtre de leur développeurs. Et puis bon, pour le désactiver c’est une histoire de 13 caractères à rajouter dans la configuration de Grub. Au passage, ça s’écrit en lowercase : systemd. -- Johan Fleury PGP Key ID : 0x5D404386805E56E6 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] iptables me rendra fou
Le 26/01/2019 à 20:48, Raphael Mazelier a écrit : On 26/01/2019 20:37, Alarig Le Lay wrote: J’ai récemment découvert que l’on peut passer net.ifnames=0 et biosdevname=0 au kernel pour désactiver ça : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-disabling_consistent_network_device_naming Intéressant... y'a moyen de virer networkd dans debian9 et de retrouver le réseau 'normal' ? Vu l'heure et le jour, en cas de repas de famille, je propose une palika pour la digestion (enfin pour ceux qui sont pas de permanence ou d'astreinte :) PS Le détail de l'histoire et ça peut aussi donner des idées (dans les deux sens)... Me suis fait un setup des fagots sous debian 8 pour utiliser toutes les IP d'un bloc (sans en perdre 3 à chaque fois) avec n domU Xen+xl (donc tout le setup réseau à la mano + des n intranets de communication inter domus). Le network/interfaces fait quelques lignes et c'est idem pour le script iptables, j'en ai un peu ch... à débugguer la partie réseau, n'étant pas un pro (plus 2/3 rescues :). Par contre le résultat est là, j'évite une vm pour un routeur : maniper trois fichiers interfaces, iptables et sysctl.conf dans l'hyperviseur, et ça roule. Chaque VM a son propre firewall sur ses interfaces. Les débits extranet et intranet sont furieux. C'est fiable et projetable. Dernièrement (n'ayant rien contre la nouveauté) j'ai réussi à comprendre comment faire avec debian9/networkd avec n domU Xen+xl (donc encore tout le setup réseau à la mano) mais là c'était une seule IP en frontal (pour l'hyperviseur et toutes les vm, ce qui n'est pas mon cas général). J'appréhende (par manque de temps) la galère pour passer au niveau suivant avec networkd (soit toutes les IP d'un bloc utilisables sans en perdre 3 à chaque fois) pour autant de domu. Cette manip est un peu verbeuse dans interfaces (on pourrait la scripter pour de plus gros blocs) mais je ne retrouve pas toutes les fonctions d'interface dans networkd... En particulier, comme ça, je vois pas comment implémenter avec networkd un paramètre zarbi (et indispensable dans ce cas) comme "pointopoint". Donc... ...s'il y avait moyen de virer proprement networkd sans péter systemd en restant fiable pour de la prod, ça serait très intéressant (en attendant d'avoir un peu plus de temps... surtout que dans pas longtemps, on va aussi se retrouver avec un autre remue-méninges pour ne pas vieillir : le remplaçant d'iptables :) ou (bonus extraballe, pardon... extrabouteille) ...une bonne âme pour me donner la soluce avec networkd (auquel cas, un soudoyage aggravé à base de wodka à la pomme de terre de l'île de ré ou de gin à base d'algues d'oléron -selon dispo et goût- est furieusement prévu, et ce sont des produits très goûtus :) Copie ci-dessous du netword/interfaces et du bout correspondant dans iptables. Une IP pour l'hyperviseur : *.*.140.63 UN /28 pour les VMs *.*.150.160 -> *.*.150.175 # # Interfaces - Configuration réseau pour v2 # # # Interface locale # auto lo iface lo inet loopback # # Interface physique du serveur et de l'hyperviseur dom0 # auto eth0 iface eth0 inet static address *.*.140.63 netmask 255.255.255.0 network *.*.140.0 broadcast *.*.140.255 gateway *.*.140.254 pointopoint *.*.140.254 # # Interfaces ponts pour les eth0 des domUs - bloc de /28 # auto br001 iface br001 inet static address 192.168.175.1 <- fake ip netmask 255.255.255.0 pre-up brctl addbr $IFACE post-up route add -host *.*.150.175 $IFACE post-down brctl delbr $IFACE ... ==== 14 définitions de ponts coupées auto br240 iface br240 inet static address 192.168.167.1 netmask 255.255.255.0 pre-up brctl addbr $IFACE post-up route add -host *.*.150.167 $IFACE post-down brctl delbr $IFACE # # Interfaces virtuelles pour les eth1, eth2, ethX des domUs # auto dummy0 iface dummy0 inet manual auto veth1 iface veth1 inet static address 192.168.1.254 netmask 255.255.255.0 network 192.168.1.0
Re: [FRnOG] [TECH] iptables me rendra fou
Dès que je peux je dégage systemd http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_Stretch_installation > Le 27 janv. 2019 à 16:26, Emmanuel DECAEN a > écrit : > > Bonjour, > >> Le 27/01/2019 à 10:07, Guillaume Tournat a écrit : >> Ça fonctionne. Sur Debian ca me permet de conserver des noms à l’ancienne : >> eth0, eth1... > C'est effectivement une bonne idée pour faire du debug et isoler cet aspect > dont le comportement est parfois surprenant. > D'autant que ce renommage avec systemd (240-2) peut aboutir à des choses pour > le moins inattendues côté réseau. > > Si on prend l'exemple ci-dessous, la partie L2 (VLAN 40) monte comme il faut > : xgbe1.40. > Malheureusement elle se trouve renommée en "rename5", et la partie L3 (IP) > échoue bêtement car le nom de l'interface a changé :-( > > Définition de l'interface: > iface xgbe1.40 inet static > address 192.168.40.218/24 > > $ sudo ifup xgbe1.40 > Cannot find device "xgbe1.40" > ifup: failed to bring up xgbe1.40 > > $ sudo dmesg > [ 56.446861] 8021q: adding VLAN 0 to HW filter on device xgbe1 > [ 56.449675] rename5: renamed from xgbe1.40 > > $ ip link > 3: xgbe1: [...] > 5: rename5@xgbe1: [...] > > Pour les curieux, le détail est ici: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917128 > > Bon Week-End. > -- > Emmanuel DECAEN > E-Mail: e...@xsalto.com > > www.xsalto.com > Tél: 04 92 36 60 06 > Support: 04 92 36 60 07 > Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Bonjour, Le 27/01/2019 à 10:07, Guillaume Tournat a écrit : > Ça fonctionne. Sur Debian ca me permet de conserver des noms à l’ancienne : > eth0, eth1... C'est effectivement une bonne idée pour faire du debug et isoler cet aspect dont le comportement est parfois surprenant. D'autant que ce renommage avec systemd (240-2) peut aboutir à des choses pour le moins inattendues côté réseau. Si on prend l'exemple ci-dessous, la partie L2 (VLAN 40) monte comme il faut : xgbe1.40. Malheureusement elle se trouve renommée en "rename5", et la partie L3 (IP) échoue bêtement car le nom de l'interface a changé :-( Définition de l'interface: iface xgbe1.40 inet static address 192.168.40.218/24 $ sudo ifup xgbe1.40 Cannot find device "xgbe1.40" ifup: failed to bring up xgbe1.40 $ sudo dmesg [ 56.446861] 8021q: adding VLAN 0 to HW filter on device xgbe1 [ 56.449675] rename5: renamed from xgbe1.40 $ ip link 3: xgbe1: [...] 5: rename5@xgbe1: [...] Pour les curieux, le détail est ici: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917128 Bon Week-End. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Ça fonctionne. Sur Debian ca me permet de conserver des noms à l’ancienne : eth0, eth1... > Le 26 janv. 2019 à 20:37, Alarig Le Lay a écrit : > > Hello, > >> On sam. 26 janv. 16:33:37 2019, Jérôme Nicolle wrote: >> On peut pas builder des appliances NFV de façon industrielle >> (virtualisées ou dockerisées) avec un adressage et comportement >> déterministe en terme de stack et services réseau - au moins kernel-land >> à cause de son tas de merde. > > J’ai récemment découvert que l’on peut passer net.ifnames=0 et > biosdevname=0 au kernel pour désactiver ça : > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-disabling_consistent_network_device_naming > > Par contre, je n’ai encore jamais essayé de le faire. > > -- > Alarig > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On 26/01/2019 20:37, Alarig Le Lay wrote: J’ai récemment découvert que l’on peut passer net.ifnames=0 et biosdevname=0 au kernel pour désactiver ça : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-disabling_consistent_network_device_naming Oui cela fonctionne. Dans le cadre d'un projet récent on a terminé avec un nommage d'interface ala BSD sur du centos, pour rendre les choses plus claires. Ex : ixgbe0, ixgbe1, mlnx0, etc... -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Hello, On sam. 26 janv. 16:33:37 2019, Jérôme Nicolle wrote: > On peut pas builder des appliances NFV de façon industrielle > (virtualisées ou dockerisées) avec un adressage et comportement > déterministe en terme de stack et services réseau - au moins kernel-land > à cause de son tas de merde. J’ai récemment découvert que l’on peut passer net.ifnames=0 et biosdevname=0 au kernel pour désactiver ça : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-disabling_consistent_network_device_naming Par contre, je n’ai encore jamais essayé de le faire. -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On 26/01/2019 16:33, Jérôme Nicolle wrote: Plop, plof. Allez tenter de monter deux VRF dans un NS, c'est bien coton… En tout cas sous SystemD/Linux (debian). D'une manière générale l'init du réseau sous linux est globalement super mal foutu. Même avant Systemd on avait le choix entre la méthode redhat qui franchement est disons "originale", et la méthode debian qui avait au moins le mérite de tout rassembler sous un fichier, ou enfin presque mais qui dans le détail n'est pas très flexible. Je ne parle même pas des complications ajouté par le consistent naming et autre régle udev. Merci OpenRC et sa souplesse légendaire qui ne présume jamais des usages qui en seront fait… Oui. Que ce soit pour l'init des services et du système les BSD auront toujours ma préférence. (petite préférence à OpenBSD, simple, clair, efficace). p.s. je maintiens encore une fois - et pour probablement toujours - ma position : SystemD c'est de la grosse daube, et que Poettering brûle en enfer - arrosé à la bière après avoir été enduit de moutarde. SystemD est une mauvaise réponse à un vrai problème. On ne devrait pas nier que les scripts initV c'était le souk. Systemd aura tout de même apporté un format (les unitfiles) compréhensible et facile à créer. Y avait il de meilleure alternative ? certainement. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Plop, Le 26/01/2019 à 01:54, Yanick Delarbre a écrit : > c'est devenu plus compliqué avec systemd Je l'attendais celle là. Bon, on est plus exactement trolldi, mais globalement, que ce soit au niveau du nommage des interfaces, de l'ordre d'activation, du résolver hardcodé sur 8.8.8.8, des soucis d'applications et de logging de règles iptables d'apparence simple (un seul NS, une seule VRF…), SystemD est impropre à tout usage réseau sérieux / maîtrisé et sécurisé. Allez tenter de monter deux VRF dans un NS, c'est bien coton… En tout cas sous SystemD/Linux (debian). Autant j'ai pas eu de problème à mix'n'match des NS (docker oblige) et des VRFs (vrai réseau oblige) sous Gentoo… Autant sous SystemD/Linux(debian) j'ai l'impression que c'est impossible à avoir en boot-config activé correctement et dans le bon ordre, voire va les mélanger et casser l'isolation… Merci OpenRC et sa souplesse légendaire qui ne présume jamais des usages qui en seront fait… @+ p.s. je maintiens encore une fois - et pour probablement toujours - ma position : SystemD c'est de la grosse daube, et que Poettering brûle en enfer - arrosé à la bière après avoir été enduit de moutarde. On peut pas builder des appliances NFV de façon industrielle (virtualisées ou dockerisées) avec un adressage et comportement déterministe en terme de stack et services réseau - au moins kernel-land à cause de son tas de merde. (j'aime la palette à la diable, à base de bon gros cochon de codeur… désolé). -- Jérôme Nicolle +33 6 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Hello, Pour ma première contribution, voici quelques pistes: * Sauf erreurs de ma part, pas vu la règle retour, au cas où, et voir si ça tombe en marche: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT * Activer les logs "martians", parfois ça donne des pistes: sudo sysctl -w 'net.ipv4.conf.all.log_martians=1' Pour les logs de netfilter, c'est devenu plus compliqué avec systemd et ne fonctionne pas par défaut, comme avec journaltctl -k. Voici un lien expliquant comment faire avec ulogd2: https://blog.sleeplessbeastie.eu/2018/08/01/how-to-log-dropped-connections-from-iptables-firewall-using-netfilter-userspace-logging-daemon/ Cordialement, Le ven. 25 janv. 2019 à 23:12, Faustin Lammler a écrit : > > Dominique Rousseau , > 25/01/2019 - 17:15:30 (+0100): > > > Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [ > kevinth...@gmail.com] a écrit: > > > Bonjour, bonsoir, > > > > > > depuis quelques temps je me bats avec iptables pour un accès tout con > mais > > > que je ne parviens pas à faire fonctionner. > > > > > > ce que je souhaite : > > > > > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour > > > > Juste au cas, où... que dit : sysctl net.ipv4.ip_forward > Oui, faut commencer par là. > > Et si tu as la possibilité de nous mettre le contenu de iptables-save > histoire qu'on voit d'un seul coup d'œil la totalité des règles... Là il > y a tellement de choses qui peuvent bloquer qu'il est difficile de > t'aider. > > En général ce que je conseille : > 1/ sysctl > 2/ routage > 3/ iptables > 4/ un petit coup d'œil au schéma de fonctionnement de iptables permet en > général de se poser les bonnes questions. Par exemple: > http://www.system-rescue-cd.org/images/dport-routing-02.png > > Mes 2 pesos, > Faust > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Dominique Rousseau , 25/01/2019 - 17:15:30 (+0100): > Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [kevinth...@gmail.com] > a écrit: > > Bonjour, bonsoir, > > > > depuis quelques temps je me bats avec iptables pour un accès tout con mais > > que je ne parviens pas à faire fonctionner. > > > > ce que je souhaite : > > > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour > > Juste au cas, où... que dit : sysctl net.ipv4.ip_forward Oui, faut commencer par là. Et si tu as la possibilité de nous mettre le contenu de iptables-save histoire qu'on voit d'un seul coup d'œil la totalité des règles... Là il y a tellement de choses qui peuvent bloquer qu'il est difficile de t'aider. En général ce que je conseille : 1/ sysctl 2/ routage 3/ iptables 4/ un petit coup d'œil au schéma de fonctionnement de iptables permet en général de se poser les bonnes questions. Par exemple: http://www.system-rescue-cd.org/images/dport-routing-02.png Mes 2 pesos, Faust --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
On Fri, Jan 25, 2019 at 05:15:30PM +0100, Dominique Rousseau wrote: > Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [kevinth...@gmail.com] > a écrit: > > Bonjour, bonsoir, > > > > depuis quelques temps je me bats avec iptables pour un accès tout con mais > > que je ne parviens pas à faire fonctionner. > > > > ce que je souhaite : > > > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour > > Juste au cas, où... que dit : sysctl net.ipv4.ip_forward j'allais poser la meme question ! Sinon, au nx des log, j'ai eu le tour hier : impossible de faire marcher LOG. Je m'en suis sorti en utilisant NFLOG/ulogd (apres c'etait un lxc, ceci explique p-e cela). a+, -- Julien << Vous n'avez rien a dire... Parlons-en! >> --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Bonsoir, Les paquets retour ne sont pas source NATé par hasard et ne match donc pas ton ACL ? Cdlt, Jugurta On 25/01/2019 17:07, Kevin Thiou wrote: Bonjour, bonsoir, depuis quelques temps je me bats avec iptables pour un accès tout con mais que je ne parviens pas à faire fonctionner. ce que je souhaite : -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour je vois les paquets arriver sur l'interface de la machine iptables avec un tcpdump : tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes 16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr 0,nop,wscale 7], length 0 16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr 0,nop,wscale 7], length 0 tous les prerouting (raw, mangle, nat) sont à accept. iptables -vL -t mangle -n Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 17G packets, 13T bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes) pkts bytes target prot opt in out source destination iptables -vL -t raw -n Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes) pkts bytes target prot opt in out source destination iptables -vL -t raw -n Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes) pkts bytes target prot opt in out source destination j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à l'autoriser, j'ai donc mis les lignes suivantes : iptables -S FORWARD -P FORWARD DROP -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO -A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO et j'ai rien dans les logs. Où peuvent donc passer ces paquets ? Merci de votre aide. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jugurta Yennek smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] [TECH] iptables me rendra fou
Salut, Est-ce que la table de routage de la machine sur 192.168.0.0/24 est correcte ? Ce genre d'oubli m'arrive assez souvent... Le ven. 25 janv. 2019 à 17:16, Dominique Rousseau a écrit : > Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [ > kevinth...@gmail.com] a écrit: > > Bonjour, bonsoir, > > > > depuis quelques temps je me bats avec iptables pour un accès tout con > mais > > que je ne parviens pas à faire fonctionner. > > > > ce que je souhaite : > > > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour > > Juste au cas, où... que dit : sysctl net.ipv4.ip_forward > > > -- > Dominique Rousseau > Neuronnexion, Prestataire Internet & Intranet > 6 rue des Hautes cornes - 8 Amiens > tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [kevinth...@gmail.com] a écrit: > Bonjour, bonsoir, > > depuis quelques temps je me bats avec iptables pour un accès tout con mais > que je ne parviens pas à faire fonctionner. > > ce que je souhaite : > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour Juste au cas, où... que dit : sysctl net.ipv4.ip_forward -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Salut, as tu vérifié que tu n'avais pas de soucis de paquets malformés ? J'ai paumé quelques heures sur un problème similaire. https://mastodon.xyz/@gduchaussois/100990651773639166 pour jouer avec ta capture et tshark pour vérifier Hope this helps Gaëtan Le 25/01/2019 à 17:07, Kevin Thiou a écrit : > Bonjour, bonsoir, > > depuis quelques temps je me bats avec iptables pour un accès tout con mais > que je ne parviens pas à faire fonctionner. > > ce que je souhaite : > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour > > je vois les paquets arriver sur l'interface de la machine iptables avec un > tcpdump : > > tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes > 16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq > 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr > 0,nop,wscale 7], length 0 > 16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq > 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr > 0,nop,wscale 7], length 0 > > tous les prerouting (raw, mangle, nat) sont à accept. > > iptables -vL -t mangle -n > Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes) > pkts bytes target prot opt in out source > destination > Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes) > pkts bytes target prot opt in out source > destination > Chain FORWARD (policy ACCEPT 17G packets, 13T bytes) > pkts bytes target prot opt in out source > destination > Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes) > pkts bytes target prot opt in out source > destination > Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes) > pkts bytes target prot opt in out source > destination > > iptables -vL -t raw -n > Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes) > pkts bytes target prot opt in out source > destination > Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes) > pkts bytes target prot opt in out source > destination > > iptables -vL -t raw -n > Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes) > pkts bytes target prot opt in out source > destination > Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes) > pkts bytes target prot opt in out source > destination > > j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à > l'autoriser, j'ai donc mis les lignes suivantes : > > iptables -S FORWARD > -P FORWARD DROP > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO > -A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO > > et j'ai rien dans les logs. > > Où peuvent donc passer ces paquets ? > > Merci de votre aide. > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
