Due interfacce, due indirizzi, due gateway?

15

Ho un sistema che ha due interfacce di rete con indirizzi IP diversi, entrambi compresi nell'intervallo di indirizzi pubblici (anche se tramite NAT nel caso del primo) ed entrambi con gateway diversi. (Lunga storia, è a scopo di test)

Il problema è che in questo momento, se provo a eseguire il ping dell'indirizzo sulla seconda interfaccia, il percorso predefinito indica tramite la prima interfaccia e non arriva mai correttamente.

È possibile assicurarsi che le risposte escano sempre attraverso la stessa interfaccia di rete (e con lo stesso IP di origine) in cui sono entrate? E se sì, come?

debian networking ipv4

— Shadur
fonte

1

Forse una variante su questo: unix.stackexchange.com/questions/4420/…

— Shawn J. Goff,

17

Stai fraintendendo il problema. Non tutti i pacchetti sono una risposta e non tutti i pacchetti possono essere abbinati ad altri pacchetti in modo tale che "la stessa interfaccia di rete in cui sono entrati" abbia senso. Quello che vuoi fare è selezionare il gateway per un pacchetto in base al suo indirizzo IP di origine.

Questo si chiama routing basato sull'origine o routing delle politiche. Puoi farlo con una semplice iptablesregola , ma il modo migliore è impostare due tabelle di routing, una per ciascun indirizzo di origine pubblico:

Innanzitutto, crea due tabelle (sostituisci <NOME1> e <NOME2> con nomi sensibili per i tuoi due provider, lo stesso con IP1, DEV1 e così via):

echo 200 <NAME1> >> /etc/iproute2/rt_tables
echo 201 <NAME2> >> /etc/iproute2/rt_tables

Aggiungi un gateway a ciascuna tabella di routing (se necessario):

ip route add <NET1> dev <DEV1> src <SRC1> table <NAME1>
ip route add <NET2> dev <DEV2> src <SRC2> table <NAME2>

Quindi una route predefinita:

ip route add default via <IP1> table <NAME1>
ip route add default via <IP2> table <NAME2>

Quindi le regole per selezionare la tabella di route in base all'indirizzo di origine:

ip rule add from <IP1> table <NAME1>
ip rule add from <IP2> table <NAME2>

Vedi Routing per più uplink / provider per maggiori dettagli.

— David Schwartz
fonte

Hai scritto: 'Non tutti i pacchetti sono una risposta e non tutti i pacchetti possono essere abbinati ad altri pacchetti in modo tale che "la stessa interfaccia di rete in cui sono entrati" abbia senso. 'Puoi spiegarlo ulteriormente? Comprendo che non tutti i pacchetti sono una risposta e non tutti i pacchetti possono essere abbinati a un altro pacchetto "sorgente". Se escludiamo questi pacchetti dalla considerazione, perché non causano problemi e quindi non ci riguardano, perché i pacchetti rimanenti non possono essere indirizzati alla "stessa interfaccia di rete come sono entrati"?

— Andrew Savinykh,

@AndrewSavinykh Questo non risolverebbe tutto il problema. In particolare, si interromperebbe ogni volta che un pacchetto in uscita originato localmente (come una richiesta di ping in uscita) esce dall'interfaccia errata per il suo indirizzo IP di origine e viene eliminato dal gateway. Il problema è, come ho spiegato, in realtà quello di assicurarsi che i pacchetti escano dal gateway corrispondente al loro indirizzo IP di origine.

— David Schwartz,

David, voglio ottenere la stessa cosa di OP ma non ci riesco. Ho pubblicato una domanda qui: serverfault.com/questions/992624/… , sarebbe fantastico se potessi dare un'occhiata

— Housemd

6

La risposta di David Schwartz è eccellente, ma puoi semplificare un po 'le regole di routing disponendo di una tabella aggiuntiva e utilizzando la route predefinita per l'altra. Ho un server che si trova dietro due gateway NAT e di recente ho attraversato il processo di ricreare quello scenario tra un gruppo di macchine virtuali. Il mio /etc/network/interfacesassomiglia a questo:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.13.13
    netmask 255.255.255.0
    up ip route add table optus default via 192.168.13.10
    up ip rule add from 192.168.13.213 table optus
    up ip route add default via 192.168.13.11

auto eth0:0
iface eth0:0 inet static
    address 192.168.13.213
    netmask 255.255.255.0

(questo è per una configurazione in cui i due ISP sono Optus e iiNet, da cui il nome della tabella 'optus')

Questo, oltre alla linea nella /etc/iproute2/rt_tablescreazione della tabella, dovrebbe essere tutto ciò di cui hai bisogno. Avrai due indirizzi IP; il traffico da 192.168.13.13 uscirà da 192.168.13.11 e il traffico da 192.168.13.213 uscirà da 192.168.13.10. Configurare quei due gateway per eseguire il port forwarding in modo appropriato (192.168.13.11 inoltra roba a 192.168.13.13 e 192.168.13.10 inoltra roba a 192.168.13.213) e il resto dovrebbe occuparsi di se stesso.

Potrebbe essere necessario modificare un po 'le cose per la tua situazione, poiché stai usando direttamente gli IP pubblici, ma qualcosa del genere dovrebbe comunque funzionare. Inoltre, è molto più facile fare queste cose /etc/network/interfacese poi gestire git quel file, piuttosto che provare a ricordare come lo hai impostato, due anni dopo, quando il sistema deve essere riavviato!

— rosuav
fonte

1

Esempio di doppia rete

Questo esempio mostra come è possibile rendere disponibile un ulteriore eth1con 10.130.0.2maschera di rete 255.255.255.255e gateway 10.130.0.1ai servizi che si associano ad esso comeping -I eth1 8.8.8.8

Tecnicamente siamo:

Aggiunta di un altro gateway con una metrica maggiore
Aggiunta / utilizzo della tabella 100 e impostazione
Aggiunta di una regola per instradare il traffico verso / da eth1 attraverso di essa

ip addr add 10.130.0.2/32 broadcast 10.130.0.2 dev eth1
ip link set eth1 up
ip route add 10.130.0.1 src 10.130.0.2 dev eth1
ip route add 10.130.0.1 src 10.130.0.2 dev eth1 table 100
ip route add default via 10.130.0.1 dev eth1 metric 10
ip route add default via 10.130.0.1 dev eth1 table 100
ip rule add from 10.130.0.2/32 table 100
ip rule add to 10.130.0.2/32 table 100
curl --interface eth1 ifconfig.co
curl --interface eth0 ifconfig.co
ping -I eth1 8.8.8.8

— intika
fonte