Collegamento della macchina Linux al router / ISP secondario: come impostare correttamente il routing?

Astratto:

Ho dei problemi (presumo il routing) quando aggiungo un ISP secondario alla mia configurazione di rete esistente: il traffico in entrata Router1non riceve risposta, ma il traffico locale e quello in entrata Router0funzionano correttamente.

Come posso mantenere funzionanti le parti che attualmente funzionano bene, facendo funzionare il traffico in entrata Router1?

Elaborazione:

Di seguito ho tracciato uno schema con gli elementi essenziali essenziali della situazione (in pratica ci sono più dispositivi su ciascuna LAN, ma non contano).

Questa è la situazione:

Ho due reti interne: LAN0è 192.168.x.0/24ed LAN1è 192.168.y.0/24. Entrambi funzionano bene per il traffico interno (ad esempio http utilizzando cURL ).
LAN0è sempre stato collegato attraverso Router0e ISP0al Internet.
LAN1sempre avuto Router1, ma ora è collegato ISP1al Internet.
Le macchine solo attive LAN0e con un percorso predefinito Router0funzionano correttamente per il traffico in uscita e in entrata.
Le macchine solo attive LAN1e con un percorso predefinito Router1funzionano correttamente per il traffico in uscita e in entrata.
Il traffico interno è attivo LAN0e LAN1ha sempre funzionato bene.
Il traffico in entrata per Router1for WindowsBarriva correttamente: posso collegarmi tramite RDP da WindowsC.
Il traffico in entrata per Router1for LinuxBarriva (secondo tcpdump ), ma non risponde come un curl http://e.f.g.hfrone LinuxCmostra con un tcpdump negli LinuxB spettacoli:

Mostra solo i pacchetti che - in base al formato di output di tcpdump - hanno un flag SYN impostato:

LinuxB:/tmp/LinuxB.eth1.80 # tcpdump -i eth1 'port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:35:19.489779 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287047182 ecr 0,sackOK,eol], length 0
13:35:19.788841 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287047478 ecr 0,sackOK,eol], length 0
13:35:19.888835 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287047578 ecr 0,sackOK,eol], length 0
13:35:19.989412 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287047678 ecr 0,sackOK,eol], length 0
13:35:20.089685 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287047778 ecr 0,sackOK,eol], length 0
13:35:20.190836 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287047877 ecr 0,sackOK,eol], length 0
13:35:20.392123 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1287048072 ecr 0,sackOK,eol], length 0
13:35:20.693692 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,sackOK,eol], length 0
13:35:21.197162 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,sackOK,eol], length 0
13:35:22.204134 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,sackOK,eol], length 0
13:35:24.115961 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,sackOK,eol], length 0
13:35:27.852374 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,sackOK,eol], length 0
13:35:31.967049 IP i.j.k.l.57512 > 192.168.y.2.http: Flags [S], seq 816356596, win 65535, options [mss 1460,sackOK,eol], length 0

Questa è la LinuxBtabella dei percorsi:

LinuxB:/tmp/LinuxB.eth1.80 # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.x.1     0.0.0.0         UG    0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
link-local      *               255.255.0.0     U     0      0        0 eth0
192.168.x.0     *               255.255.255.0   U     0      0        0 eth0
192.168.x.0     *               255.255.255.0   U     0      0        0 eth1

Dal momento che il collegamento su RDP da WindowsCa WindowsBfunziona benissimo, riprendo che questo è davvero un problema di routing. Questa è la WindowsBtabella dei percorsi:

C:\temp>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 35 77 e1 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport
0x3 ...00 0c 29 35 77 eb ...... VMware Accelerated AMD PCNet Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.x.1     192.168.x.4      10
          0.0.0.0          0.0.0.0      192.168.y.1     192.168.y.4       5
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.x.0    255.255.255.0      192.168.x.4     192.168.x.4      10
      192.168.x.4  255.255.255.255        127.0.0.1       127.0.0.1      10
    192.168.x.255  255.255.255.255      192.168.x.4     192.168.x.4      10
      192.168.y.0    255.255.255.0      192.168.y.4     192.168.y.4      10
      192.168.y.4  255.255.255.255        127.0.0.1       127.0.0.1      10
    192.168.y.255  255.255.255.255      192.168.y.4     192.168.y.4      10
        224.0.0.0        240.0.0.0      192.168.x.4     192.168.x.4      10
        224.0.0.0        240.0.0.0      192.168.y.4     192.168.y.4      10
  255.255.255.255  255.255.255.255      192.168.x.4     192.168.x.4       1
  255.255.255.255  255.255.255.255      192.168.y.4     192.168.y.4       1
Default Gateway:       192.168.y.1
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      192.168.y.1       5
          0.0.0.0          0.0.0.0      192.168.x.1      10

Quindi, come posso ottenere il routing LinuxBper essere così:

mantenere percorso di default su LinuxBper 192.168.x.1così il traffico in uscita mantiene utilizzando Router0/ISP0
continua a rispondere alle richieste in arrivo provenienti da LAN0onLAN0
continua a rispondere alle richieste in arrivo provenienti da LAN1onLAN1
continuare a rispondere alle richieste in arrivo tramite Router0( a.b.c.d/ 192.168.x.1) tramite192.168.x.1
iniziare a rispondere alle richieste in arrivo tramite Router1( e.f.g.h/ 192.168.y.1) tramite192.168.y.1
bonus: avere il Router1failover o il bilanciamento del carico conRouter0

poscritto:

L' immagine PNG seguente è generata sul testo UML attraverso il motore PlantUML online gratuito . Se vuoi vedere il testo UML originale, incolla il link immagine PNG in questo modulo PlantUML , quindi premi Submit.

inserisci qui la descrizione dell'immagine

— Jeroen Wiert Pluimers
fonte

Ho appena trovato una risposta interessante su unix.stackexchange.com/a/23345/69111 che sto esaminando per vedere se si applica al mio caso e come implementarlo utilizzando yast.

— Jeroen Wiert Pluimers,

Yastsembra fuori per fare il routing complesso e routesembra essere deprecato a favore di ip. Vedi opensuse.14.x6.nabble.com/yast2-advanced-routing-td3083578.html e suse.com/documentation/sles11/book_sle_admin/data/…

— Jeroen Wiert Pluimers

La tua soluzione collegata su unix.stackexchange sta andando nella giusta direzione e risolverà il problema di linux: il nodo linux ha due tabelle di routing separate e usa la tabella appropriata a seconda dell'interfaccia su cui è stata avviata la connessione. Non sono a conoscenza di tale soluzione per Windows. A meno che non vi sia una reale necessità di due sottoreti, ne eliminerei una e utilizzerei un router per entrambi gli ISP. È possibile acquistare router in grado di gestire correttamente due WAN oppure è possibile utilizzare un altro sistema Linux per farlo, semplificando il routing sui sistemi sottostanti.

— David Mackintosh,

@DavidMackintosh in futuro lo farò. Questo è temporaneo: la fibra è in realtà DSL e si sposterà su un indirizzo di fibra diverso. La macchina è DNS e MX, quindi voglio che sia accessibile da due ISP per avere continuità in quanto non sono sicuro se DSL verrà arrestato prima o dopo che la fibra diventa attiva.

— Jeroen Wiert Pluimers,

Avevo una sceneggiatura di shell per fare qualcosa del genere molto tempo fa ma, mi dispiace, l'ho trovata. Quindi posso solo darti i suggerimenti per le soluzioni che ho implementato allora. Sto scrivendo principalmente dalla memoria, quindi mancano alcuni esempi:

Avevo una tabella di routing per uplink (route ip ... tabella 101, route ip ... tabella 102). Questo va in / etc / iproute2 / rt_tables.

101 isp1 102 isp2

È necessario impostare anche quelle tabelle:

ip route aggiungi default tramite $ Gateway1 dev $ Interface1 tabella isp1 ip route aggiungi default con $ Gateway2 dev $ Interface2 tabella isp2

# Non dimenticare la tabella predefinita:

ip route aggiungi default tramite $ DefaultGateway dev $ DefaultInterface
Abilita tracciamento connessione iptables (modprobe nf_conntrack)
Impostare una regola iptables per NUOVE connessioni in entrata su -j MARK i pacchetti in qualche modo (cioè: 0x201, 0x202)
Imposta una regola ip che assicuri che il traffico in uscita attraverso un'interfaccia utilizzi la tabella di routing corretta

Aggiunta regola ip da $ Ip1 tabella isp1 Aggiunta regola ip da $ Ip2 tabella isp2
Impostare una regola ip (ip rule add ...) indicante che "i pacchetti contrassegnati 0x201 dovranno cercare la tabella di routing 201", una regola per ogni uplink.

Con tutto in atto dovresti essere in grado di ricevere e avviare connessioni con qualsiasi uplink wan e persino bilanciare le connessioni in uscita.

Quelle sarebbero le basi. Iptables + "ip route" + "ip rule" e sei a posto.

— marc.fargas
fonte