Di recente mi sono imbattuto in una situazione in cui avevo bisogno di due indirizzi IP sulla stessa sottorete assegnati a un host Linux in modo da poter eseguire due siti SSL / TLS. Il mio primo approccio è stato quello di utilizzare l'aliasing IP, ad esempio utilizzando eth0: 0, eth0: 1, ecc., Ma i nostri amministratori di rete hanno alcune impostazioni abbastanza rigide per la sicurezza che hanno schiacciato questa idea:
- Usano lo snooping DHCP e normalmente non consentono indirizzi IP statici. L'indirizzamento statico viene realizzato utilizzando voci DHCP statiche, quindi lo stesso indirizzo MAC ottiene sempre la stessa assegnazione IP. Questa funzione può essere disabilitata per switchport se lo chiedi e ne hai una ragione (per fortuna ho un buon rapporto con i ragazzi della rete e questo non è difficile da fare).
- Con lo snooping DHCP disabilitato sullo switchport, hanno dovuto inserire una regola nello switch secondo cui l'indirizzo MAC X può avere l'indirizzo IP Y. Sfortunatamente questo ha avuto l'effetto collaterale di dire che l'indirizzo MAC X può SOLO avere Indirizzo IP Y. L'aliasing IP richiedeva che l'indirizzo MAC X ricevesse due indirizzi IP, quindi non funzionava.
Potrebbe esserci stato un modo per aggirare questi problemi sulla configurazione dello switch, ma nel tentativo di preservare buone relazioni con gli amministratori di rete ho cercato di trovare un altro modo. Avere due interfacce di rete sembrava il passo logico successivo. Per fortuna questo sistema Linux è una macchina virtuale, quindi sono stato in grado di aggiungere facilmente una seconda interfaccia di rete (senza riavviare, potrei aggiungere - piuttosto interessante). Alcuni tasti dopo ho avuto due interfacce di rete attive e funzionanti ed entrambe hanno estratto gli indirizzi IP dal DHCP.
Ma poi è arrivato il problema: gli amministratori di rete potevano vedere (sullo switch) la voce ARP per entrambe le interfacce, ma solo la prima interfaccia di rete che avevo richiamato rispondeva ai ping o a qualsiasi tipo di traffico TCP o UDP.
Dopo molte ricerche e ricerche, ecco cosa mi è venuto in mente. Sembra funzionare, ma sembra anche lavorare molto per qualcosa che sembra dovrebbe essere semplice. Qualche idea alternativa là fuori?
Passaggio 1: abilitare il filtro ARP su tutte le interfacce:
# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf
Dal file networking / ip-sysctl.txt nei documenti del kernel 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
Passaggio 2: implementare il routing basato sull'origine
Fondamentalmente ho appena seguito le indicazioni da http://lartc.org/howto/lartc.rpdb.multiple-links.html , anche se quella pagina è stata scritta con un obiettivo diverso in mente (trattare con due ISP).
Supponiamo che la sottorete sia 10.0.0.0/24, il gateway sia 10.0.0.1, l'indirizzo IP per eth0 sia 10.0.0.100 e l'indirizzo IP per eth1 sia 10.0.0.101.
Definire due nuove tabelle di routing denominate eth0 ed eth1 in / etc / iproute2 / rt_tables:
... top of file omitted ...
1 eth0
2 eth1
Definire i percorsi per queste due tabelle:
# 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
Definire le regole per quando utilizzare le nuove tabelle di routing:
# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1
La tabella di routing principale è già stata curata da DHCP (e non è nemmeno chiaro che sia strettamente necessario in questo caso), ma sostanzialmente equivale a questo:
# 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
E voilà! Tutto sembra funzionare bene. L'invio di ping ad entrambi gli indirizzi IP funziona correttamente. L'invio di ping da questo sistema ad altri sistemi e forzando il ping a utilizzare un'interfaccia specifica funziona correttamente ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). E, soprattutto, tutto il traffico TCP e UDP verso / da entrambi gli indirizzi IP funziona come previsto.
Quindi, ancora una volta, la mia domanda è: c'è un modo migliore per farlo? Sembra molto lavoro per un problema apparentemente semplice.
Aggiornamento: la soluzione sopra è risultata incompleta. Le cose funzionavano bene se il traffico rimaneva sulla stessa sottorete, ma le comunicazioni con altre sottoreti che utilizzavano la seconda interfaccia non funzionavano correttamente. Invece di scavare una buca più grande, ho finito per parlare con gli amministratori di rete e ho ottenuto loro di consentire più indirizzi IP per un'unica interfaccia e ho usato l'aliasing IP (ad esempio eth0 ed eth0: 0).
ipda iproute2per aggiungere più di un indirizzo alla stessa interfaccia.