Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Je ne sais pas si Linux le fait par défaut. Je sais que ça s'active par défaut si tu mets deux prefix dans ton RAD. Je sais aussi que la plupart des gens qui s'essayent à faire du advanced router oublient généralement un ou deux trucs, sont surpris que ça marche pas et finissent par passer en DHCP6 qui est une horreur.
Bien sûr que ça marche...
C'est contraire à la norme, un jour tu vas tomber sur un router/switch/firewall ou autre qui va juste t'envoyer balader, ou qui refusera carrément de dialoguer avec toi. Il y a pas que du Linux sur un réseau.
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Le script qui est donné sur la home page de avahi.org n'utilise pas les pseudo-scopes, il est en scope link (donc le prefered de l'interface). Donc si tu fais ip address add sans scope tu vas gicler l'adresse avahi-autoipd CF :
However it has the disadvantage of breaking existing TCP connections to IPv4LL hosts if suddenly a routable address is configured. Nonetheless we decided to make this behaviour the default.
Si tu repasses le script à la main (qui est toujours en scope link) tu vas regicler ta nouvelle adresse et remettre une adresse en 169.x à la place. Fais le test si tu ne me crois pas (avec le script de la home page d'avahi hein).
Maintenant si ta distrib a décidé de lancer quoi qu'il arrive un script autoipd avec un pseudo-scope local, ça la regarde. Mais bon a part du du zero conf à la sauce Apple je vois pas l’intérêt.
Non ?
Si, si.
Non plus. Avahi-autoipd va directement taper sur netlink et observer les interfaces voulues en regardant si elles deviennent up ou pas.
Avahi-autoipd il est aveugle et sourd. Tu l'invoque et il s’exécute, tu l'invoques pas et il ne bouge pas. (En tout cas c'était le cas la dernière fois que j'ai regardé et c'est aussi ce qui est marqué dans la doc, maintenant c'est vrai qu'avec Linux ça a pu changer trois fois depuis sans que la donc bouge d'un iota).
La bonne façon de l'invoquer c'est en fin de script dhclient suite à un echec. Maintenant tu peux aussi l'invoquer sur des événements DBus lié à netlink j'imagine. Je ne vois pas ce que ça apporterait une fois de plus.
Pas du tout, c'est plutôt le contraire : les mécanismes d'alias sont utilisés pour rendre ifconfig compatible avec ip.
Ca fait 10 ans que ifconfig est "deprecated", il fait la course avec OSS.
Maintenant mettons les choses à plat sur ce qui se passe :
ifconfig utilise inet. Quand on créé un alias avec ifconfig, il y a un hint qui est fichu dans un socket inet, le noyau reçoit le message et créé un alias. Quand ifconfig SOUS LINUX interroge une interface physique, il interroge en fait les sockets inet rattachés à cette interface et récupère les alias des sockets inet.
iproute faisait exactement la même chose avec les sockets netlink.
Donc au niveau noyau les alias étaient en place, mais iproute ne voyait pas les alias créé par ifconfig et réciproquement.
Après moults trolls et autre combats pour que Linux fasse comme le reste du monde (à savoir demander au noyau plutôt qu'aux sockets, mais ça a un cout en terme de perfs et ça aurait entrainé la réécriture d'une partie de la pile IP), il a été décidé qu'iproute lirait aussi les infos d'ifconfig , mais qu'ifconfig étant deprecated il pouvait aller se faire voir (on est alors en 2001).
Dans la plus pure tradition linux, 11 plus tard les scripts d'init réseau n'ont toujours pas été réécrit et utilisent toujours ifconfig. Il a donc bien fallu trouver des gruikeries pour que les sockets inet et les sockets netlink représentent à peu près la même chose.
C'est juste que ifconfig affichait seulement la première adresse IP que le noyau trouvait
Non, en fait le format de socket inet ne permettait pas au noyau de donner une réponse complète, à savoir toute les alias sur iptables nommées partaient à la poubelle. Faut dire que la dernière mise à jour de ifconfig sous linux ca date de 1999...
Mauvaise configuration, changer configuration ?
J'ai déjà changé, je suis sous BSD maintenant pour toutes ces sortes de choses. Avec un ifconfig qui est mis à jour régulièrement et qui marche très bien (cf mon tout premier post). Sous les différents Unix Like ifconfig a évolué pas mal au court des 14 dernières années contrairement à Linux. Maintenant si tu veux je peux te donner une série de commandes à passer sous un linux, qui utilise iproute2 sur une machine qui a deux interfaces physiques et qui ont pour effet de péter en morceau l'arbre de recherche ARP de tous les switchs un peu cheap du marché. Bonne ou mauvaise chose ça se discute, mais les BSD ne te laissent pas faire ce genre de clowneries.
Ça doit être génial pour les performances, non ?
De quoi de passer par une règle firewall pour les forwards de paquets depuis une autre IP ou une autre interface que l'IP ou l'interface naturelle ? Non pas du tout.
Et tant bien même ça aurait un impact, il serait toujours nettement plus faible que celui que pourrait générer un logiciel de configuration qui créé une règle firewall nommée par alias et par route comme le fait iproute2.
Le seul défaut est de devoir les palucher à la main là ou iproute2 les créé en automatique, mais vu les dommages collatéraux potentiels je fais partie des gens qui pensent que ce genre de config doivent être faite par un être humain avec un niveau de connaissance assez élevé sur ce qu'il est en train de bidouiller. Mais après ça se discute.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Je ne sais pas si Linux le fait par défaut. Je sais que ça s'active par défaut si tu mets deux prefix dans ton RAD. Je sais aussi que la plupart des gens qui s'essayent à faire du advanced router oublient généralement un ou deux trucs, sont surpris que ça marche pas et finissent par passer en DHCP6 qui est une horreur.
Bien sûr que ça marche...
C'est contraire à la norme, un jour tu vas tomber sur un router/switch/firewall ou autre qui va juste t'envoyer balader, ou qui refusera carrément de dialoguer avec toi. Il y a pas que du Linux sur un réseau.
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Le script qui est donné sur la home page de avahi.org n'utilise pas les pseudo-scopes, il est en scope link (donc le prefered de l'interface). Donc si tu fais ip address add sans scope tu vas gicler l'adresse avahi-autoipd CF :
Si tu repasses le script à la main (qui est toujours en scope link) tu vas regicler ta nouvelle adresse et remettre une adresse en 169.x à la place. Fais le test si tu ne me crois pas (avec le script de la home page d'avahi hein).
Maintenant si ta distrib a décidé de lancer quoi qu'il arrive un script autoipd avec un pseudo-scope local, ça la regarde. Mais bon a part du du zero conf à la sauce Apple je vois pas l’intérêt.
Avahi-autoipd il est aveugle et sourd. Tu l'invoque et il s’exécute, tu l'invoques pas et il ne bouge pas. (En tout cas c'était le cas la dernière fois que j'ai regardé et c'est aussi ce qui est marqué dans la doc, maintenant c'est vrai qu'avec Linux ça a pu changer trois fois depuis sans que la donc bouge d'un iota).
La bonne façon de l'invoquer c'est en fin de script dhclient suite à un echec. Maintenant tu peux aussi l'invoquer sur des événements DBus lié à netlink j'imagine. Je ne vois pas ce que ça apporterait une fois de plus.
Non le problème est là en fait :
https://bugzilla.redhat.com/show_bug.cgi?id=132925
https://bugzilla.redhat.com/show_bug.cgi?id=65114
Ca fait 10 ans que ifconfig est "deprecated", il fait la course avec OSS.
Maintenant mettons les choses à plat sur ce qui se passe :
ifconfig utilise inet. Quand on créé un alias avec ifconfig, il y a un hint qui est fichu dans un socket inet, le noyau reçoit le message et créé un alias. Quand ifconfig SOUS LINUX interroge une interface physique, il interroge en fait les sockets inet rattachés à cette interface et récupère les alias des sockets inet.
iproute faisait exactement la même chose avec les sockets netlink.
Donc au niveau noyau les alias étaient en place, mais iproute ne voyait pas les alias créé par ifconfig et réciproquement.
Après moults trolls et autre combats pour que Linux fasse comme le reste du monde (à savoir demander au noyau plutôt qu'aux sockets, mais ça a un cout en terme de perfs et ça aurait entrainé la réécriture d'une partie de la pile IP), il a été décidé qu'iproute lirait aussi les infos d'ifconfig , mais qu'ifconfig étant deprecated il pouvait aller se faire voir (on est alors en 2001).
Dans la plus pure tradition linux, 11 plus tard les scripts d'init réseau n'ont toujours pas été réécrit et utilisent toujours ifconfig. Il a donc bien fallu trouver des gruikeries pour que les sockets inet et les sockets netlink représentent à peu près la même chose.
Non, en fait le format de socket inet ne permettait pas au noyau de donner une réponse complète, à savoir toute les alias sur iptables nommées partaient à la poubelle. Faut dire que la dernière mise à jour de ifconfig sous linux ca date de 1999...
J'ai déjà changé, je suis sous BSD maintenant pour toutes ces sortes de choses. Avec un ifconfig qui est mis à jour régulièrement et qui marche très bien (cf mon tout premier post). Sous les différents Unix Like ifconfig a évolué pas mal au court des 14 dernières années contrairement à Linux. Maintenant si tu veux je peux te donner une série de commandes à passer sous un linux, qui utilise iproute2 sur une machine qui a deux interfaces physiques et qui ont pour effet de péter en morceau l'arbre de recherche ARP de tous les switchs un peu cheap du marché. Bonne ou mauvaise chose ça se discute, mais les BSD ne te laissent pas faire ce genre de clowneries.
De quoi de passer par une règle firewall pour les forwards de paquets depuis une autre IP ou une autre interface que l'IP ou l'interface naturelle ? Non pas du tout.
Et tant bien même ça aurait un impact, il serait toujours nettement plus faible que celui que pourrait générer un logiciel de configuration qui créé une règle firewall nommée par alias et par route comme le fait iproute2.
Le seul défaut est de devoir les palucher à la main là ou iproute2 les créé en automatique, mais vu les dommages collatéraux potentiels je fais partie des gens qui pensent que ce genre de config doivent être faite par un être humain avec un niveau de connaissance assez élevé sur ce qu'il est en train de bidouiller. Mais après ça se discute.