Linux-Rechner an sekundären Router/ISP anschließen: Wie richte ich das Routing richtig ein?

Linux-Rechner an sekundären Router/ISP anschließen: Wie richte ich das Routing richtig ein?

Abstrakt:

Ich habe (ich nehme an, Routing-)Probleme, wenn ich einen sekundären ISP zu meiner vorhandenen Netzwerkkonfiguration hinzufüge: Eingehender Datenverkehr Router1wird nicht beantwortet, aber lokaler und eingehender Datenverkehr Router0funktioniert einwandfrei.

Wie kann ich die Teile, die derzeit gut funktionieren, in Betrieb halten und gleichzeitig den eingehenden Verkehr durch Router1die Arbeit leiten?

Ausarbeitung:

Ich habe unten ein Diagramm skizziert, das die wesentlichen Aspekte der Situation darstellt (in der Praxis gibt es in jedem LAN mehr Geräte, aber das spielt keine Rolle).

Dies ist die Situation:

  • Ich habe zwei interne Netzwerke: LAN0is 192.168.x.0/24und LAN1is 192.168.y.0/24. Beide funktionieren gut für internen Datenverkehr (zum BeispielhttpmitcURL).
  • LAN0ist seit jeher durch Router0und ISP0mit dem verbunden Internet.
  • LAN1hatte immer Router1, ist jetzt aber über verbunden ISP1mit Internet.
  • Für ausgehenden und eingehenden Datenverkehr funktionieren nur eingeschaltete Maschinen LAN0mit einer Standardroute einwandfrei .Router0
  • Für ausgehenden und eingehenden Datenverkehr funktionieren nur eingeschaltete Maschinen LAN1mit einer Standardroute einwandfrei .Router1
  • Der interne Verkehr ist eingeschaltet LAN0und LAN1hat immer gut funktioniert.
  • Eingehender Datenverkehr über Router1kommt WindowsBkorrekt an: Ich kann von aus über RDP eine Verbindung dazu herstellen WindowsC.
  • Eingehender Verkehr durch Router1für LinuxBkommt an (nachtcpdump), aber nicht zurückgeantwortet, wie eine curl http://e.f.g.hFront LinuxCzeigt mit einemtcpdump ein LinuxBzeigt an:

Es werden nur Pakete angezeigt, die - gemäß derTCPdump-Ausgabeformat- habe einenSYNFlag gesetzt:

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

Dies ist die LinuxBRoutentabelle:

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

Da die Verbindung über RDP von WindowsCnach WindowsBproblemlos funktioniert, gehe ich davon aus, dass es sich tatsächlich um ein Routing-Problem handelt. Dies ist die WindowsBRoutentabelle:

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

Wie kann ich das Routing LinuxBso einrichten:

  • Standardroute beibehalten LinuxB, damit 192.168.x.1ausgehender Verkehr weiterhin Router0/ verwendetISP0
  • Beantworten Sie weiterhin eingehende Anfragen LAN0vonLAN0
  • Beantworten Sie weiterhin eingehende Anfragen LAN1vonLAN1
  • Beantworten Sie weiterhin eingehende Anfragen über Router0( a.b.c.d/ 192.168.x.1) via192.168.x.1
  • Beginnen Sie mit der Beantwortung eingehender Anfragen über Router1( e.f.g.h/ 192.168.y.1) via192.168.y.1
  • Bonus: Router1Failover oder Lastausgleich mitRouter0

Nachtrag:

DerPNG-Bild untenwird generiert amUMLText über das kostenlose OnlinePflanzeUMLWenn Sie den ursprünglichen UML-Text sehen möchten, fügen Sie denPNG-Bildlinkdas mögenPlantUML-Formular, dann drücken Submit.

Bildbeschreibung hier eingeben

Antwort1

Ich hatte vor langer, langer Zeit ein Shell-Skript, um so etwas zu tun, aber ich konnte es leider nicht finden. Ich kann Ihnen also nur Hinweise auf die Lösungen geben, die ich damals implementiert habe. Ich schreibe größtenteils aus dem Gedächtnis, daher fehlen einige Beispiele:

  1. Ich hatte eine Routing-Tabelle pro Uplink (IP-Route ... Tabelle 101, IP-Route ... Tabelle 102). Das kommt in /etc/iproute2/rt_tables.

    101 isp1 102 isp2

    Sie müssen auch diese Tabellen einrichten:

    IP-Route standardmäßig hinzufügen über $Gateway1 dev $Interface1 Tabelle isp1 IP-Route standardmäßig hinzufügen über $Gateway2 dev $Interface2 Tabelle isp2

    #Vergessen Sie die Standardtabelle nicht:

    IP-Route standardmäßig hinzufügen über $DefaultGateway dev $DefaultInterface

  2. Aktivieren Sie die iptables-Verbindungsverfolgung (modprobe nf_conntrack).

  3. Legen Sie eine iptables-Regel für NEUE eingehende Verbindungen fest, um die Pakete irgendwie mit -j zu MARKIEREN (z. B.: 0x201, 0x202).
  4. Legen Sie eine IP-Regel fest, die sicherstellt, dass der über eine Schnittstelle ausgehende Datenverkehr die richtige Routing-Tabelle verwendet.

    IP-Regel aus $Ip1-Tabelle ISP1 hinzufügen. IP-Regel aus $Ip2-Tabelle ISP2 hinzufügen.

  5. Legen Sie eine IP-Regel (IP-Regel hinzufügen ...) fest, die besagt, dass „Pakete mit der Markierung 0x201 in der Routing-Tabelle 201 nachschlagen sollen“, eine Regel für jeden Uplink.

Wenn alles eingerichtet ist, sollten Sie in der Lage sein, Verbindungen mit jedem WAN-Uplink zu empfangen und herzustellen und sogar ausgehende Verbindungen auszugleichen.

Das wären die Grundlagen. Iptables + „IP-Route“ + „IP-Regel“ und schon kann es losgehen.

verwandte Informationen