J'ai récemment rencontré une situation où j'avais besoin de deux adresses IP sur le même sous-réseau attribué à un hôte Linux afin de pouvoir exécuter deux sites SSL / TLS. Ma première approche a été d'utiliser l'alias IP, par exemple en utilisant eth0: 0, eth0: 1, etc., mais nos administrateurs réseau ont mis en place des paramètres de sécurité assez stricts qui ont écrasé cette idée:
- Ils utilisent l'espionnage DHCP et n'autorisent généralement pas les adresses IP statiques. L'adressage statique est réalisé à l'aide d'entrées DHCP statiques, de sorte que la même adresse MAC obtient toujours la même affectation IP. Cette fonctionnalité peut être désactivée par switchport si vous le demandez et que vous avez une raison (heureusement, j'ai une bonne relation avec les gars du réseau et ce n'est pas difficile à faire).
- Avec l'espionnage DHCP désactivé sur le port de commutation, ils ont dû mettre une règle sur le commutateur selon laquelle ladite adresse MAC X est autorisée à avoir l'adresse IP Y. Malheureusement, cela a eu pour effet secondaire de dire également que l'adresse MAC X n'est autorisée qu'à avoir Adresse IP Y. Le pseudonyme IP exigeait que l'adresse MAC X reçoive deux adresses IP, donc cela n'a pas fonctionné.
Il y avait peut-être un moyen de contourner ces problèmes sur la configuration du commutateur, mais dans une tentative de préserver de bonnes relations avec les administrateurs réseau, j'ai essayé de trouver un autre moyen. Avoir deux interfaces réseau semblait être la prochaine étape logique. Heureusement, ce système Linux est une machine virtuelle, j'ai donc pu facilement ajouter une deuxième interface réseau (sans redémarrer, je pourrais ajouter - plutôt cool). Quelques frappes plus tard, j'ai eu deux interfaces réseau opérationnelles et les deux ont tiré les adresses IP du DHCP.
Mais le problème est venu: les administrateurs réseau pouvaient voir (sur le commutateur) l'entrée ARP pour les deux interfaces, mais seule la première interface réseau que j'ai évoquée répondait aux pings ou à tout type de trafic TCP ou UDP.
Après beaucoup de fouilles et de fouilles, voici ce que j'ai trouvé. Cela semble fonctionner, mais cela semble aussi être beaucoup de travail pour quelque chose qui semble être simple. Des idées alternatives là-bas?
Étape 1: activez le filtrage ARP sur toutes les interfaces:
# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf
Depuis le fichier networking / ip-sysctl.txt dans la documentation du noyau Linux:
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.
arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise
Étape 2: implémenter le routage basé sur la source
J'ai simplement suivi les instructions de http://lartc.org/howto/lartc.rpdb.multiple-links.html , bien que cette page ait été écrite avec un objectif différent à l'esprit (traitant de deux FAI).
Supposons que le sous-réseau est 10.0.0.0/24, la passerelle est 10.0.0.1, l'adresse IP pour eth0 est 10.0.0.100 et l'adresse IP pour eth1 est 10.0.0.101.
Définissez deux nouvelles tables de routage nommées eth0 et eth1 dans / etc / iproute2 / rt_tables:
... top of file omitted ...
1 eth0
2 eth1
Définissez les itinéraires pour ces deux tables:
# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1
Définissez les règles pour savoir quand utiliser les nouvelles tables de routage:
# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1
La table de routage principale a déjà été prise en charge par DHCP (et il n'est même pas clair que son strictement nécessaire dans ce cas), mais cela équivaut essentiellement à ceci:
# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101
Et le tour est joué! Tout semble bien fonctionner. L'envoi de pings aux deux adresses IP fonctionne correctement. L'envoi de pings de ce système à d'autres systèmes et le forçage du ping à utiliser une interface spécifique fonctionne très bien ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). Et surtout, tout le trafic TCP et UDP vers / depuis l'une des adresses IP fonctionne comme prévu.
Encore une fois, ma question est: existe-t-il une meilleure façon de procéder? Cela semble beaucoup de travail pour un problème apparemment simple.
Mise à jour: la solution ci-dessus s'est révélée incomplète. Les choses fonctionnaient bien si le trafic restait sur le même sous-réseau, mais les communications avec d'autres sous-réseaux utilisant la 2ème interface ne fonctionneraient pas correctement. Plutôt que de creuser un trou plus grand, j'ai fini par parler avec les administrateurs réseau et je leur ai demandé d'autoriser plusieurs adresses IP pour la même interface et d'utiliser l'alias IP (par exemple eth0 et eth0: 0).
ipfromiproute2pour ajouter plusieurs adresses à la même interface.Réponses:
Oui, la meilleure façon est de créer une analyse de rentabilisation appropriée et de leur faire assouplir les règles sur les commutateurs afin que vous puissiez avoir plusieurs adresses IP sur une seule carte réseau.
la source