Routing: zwei Subnetze & Gateways

[PhilAd]

Ich hatte verstanden, dass ein Ping vom Default-GW zum anderen funktioniert hat, aber nicht von einem Client zu einem anderen Client im jeweiligen Subnet? Das scheint ja nur zu funktionieren, wenn der Default-GW ignoriert wird und eine Route existiert die für das jeweilige Subnet direkt den ERx anwählt.
Mit dem ER kann man über den Befehl 'capture' oder auch 'sudo tcpdump' mit den bekannten Optionen verwenden. Wenn ein Client dann sein Paket loschickt über dein bekanntes Default-GW und es dort nicht aufschlägt, kann man sicher sein, dass man in der Konfiguration des Default-GW nachsehen muss. Sieht man das Paket schaut man, ob man auch die passende Antwort dazu findet und falls nicht captured man auf der anderen Seite mit bis man die Stelle gefunden hat, wo die Pakete 'verschluckt' werden.
Funktioniert denn ein Ping eines Clients aus dem Netz der FB an einen Client auf der anderen Seite? (FW des jweiligen Empfängers sollte testweise ganz deaktiviert sein).

 

[Tranceport]

Bin gerade nur am Handy. Tut mir leid, hätte es klarer formulieren sollen. Ping/trace funktioniert 1A zwischen allen Geräten über die Subnetze. Hier ein trace von meinem Handy im 0.x er Netz auf einen Mac im 178er Netz:

 

[PhilAd]

Dann dürfte das Routing ja eig. stehen ... Schonmal gezielt UDP/TCP Pakete getestet? Falls das auffällig ist könnte es auch ein MTU/MSS Problem sein

 

[Raijin]

Das ist ja gerade das merkwürdige.

Ich würde an dieser Stelle mal mit WireShark genau gucken was auf der Ethernetleitung abläuft, wenn Windows meint, dass der Ping geht, der Zugriff auf die Fritzbox aber nicht. @PhilAd hat da vielleicht gar nicht so unrecht mit seiner Vermutung..

Auf jeden Fall habe ich gerade erfolgreich über Option 121 eine Route via DHCP im ERX (dnsmasq) an meinen Windows 10 PC geschickt. Bei meinem Android Handy (Note 10) hat es hingegen nicht geklappt.

Nichtsdestotrotz halte ich das vermeintliche Routingproblem auch nur für einen Seiteneffekt. Diesen Weg habe ich daher nur aus Neugier verfolgt, weil ich das selbst noch nie ausprobiert habe. Deswegen wäre besagter Check mit WireShark interessant, um zu sehen was genau nu im Netzwerk das Problem bzw. der Unterschied zwischen Ping und Zugriff auf die Router-GUI ist. Statische Routen in jedem Client sind nämlich so oder so nicht wirklich zielführend - sei es automatisch via DHCP oder händisch eingetragen -, weil man gar nicht bei allen Geräten überhaupt Routen eintragen kann. Sobald embedded devices im Spiel sind, haben die beispielsweise gar keine Routing-Tabelle bzw. selbige ist fix auf die Standardroute beschränkt, hard coded.

 

[Tranceport]

Ich habe Wireshark eben angeworfen (den Eintrag in die Windowsroutingtabelle habe ich nicht persistent gemacht, d.h. nach dem Neustart heute komme ich wieder nicht drauf) und einen Ping von 0.80 auf 1.10 geschickt, gefolgt von einem Tracert (beide erfolgreich). Dann wollte ich auf die Weboberfläche der Diskstation (1.10:5000) zugreifen:

Wireshark:

439    16.972395    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=97/24832, ttl=128 (reply in 440)
457    17.974982    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=98/25088, ttl=128 (reply in 459)
532    18.977877    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=99/25344, ttl=128 (reply in 533)
578    19.980171    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=100/25600, ttl=128 (reply in 579)
725    27.127830    192.168.0.80    192.168.1.10    NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
727    27.164056    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=101/25856, ttl=1 (no response found!)
837    31.143478    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=102/26112, ttl=1 (no response found!)
839    31.144413    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=103/26368, ttl=1 (no response found!)
869    32.148634    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=104/26624, ttl=2 (no response found!)
871    32.149843    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=105/26880, ttl=2 (no response found!)
873    32.150724    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=106/27136, ttl=2 (no response found!)
1091    37.656165    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=107/27392, ttl=3 (reply in 1092)
1093    37.657513    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=108/27648, ttl=3 (reply in 1094)
1095    37.658565    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=109/27904, ttl=3 (reply in 1096)
1099    37.661781    192.168.0.80    192.168.1.10    NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
1651    44.157002    192.168.0.80    192.168.1.10    TCP    66    53059 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
1653    44.158846    192.168.0.80    192.168.1.10    TCP    54    53059 → 80 [ACK] Seq=1 Ack=1 Win=262656 Len=0
1654    44.159003    192.168.0.80    192.168.1.10    HTTP    610    GET / HTTP/1.1
1662    44.459405    192.168.0.80    192.168.1.10    TCP    610    [TCP Retransmission] 53059 → 80 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=556
1671    45.059549    192.168.0.80    192.168.1.10    TCP    610    [TCP Retransmission] 53059 → 80 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=556
1686    45.553070    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 1653#1] 53059 → 80 [ACK] Seq=557 Ack=1 Win=262656 Len=0 SLE=0 SRE=1
1754    46.267229    192.168.0.80    192.168.1.10    TCP    610    [TCP Retransmission] 53059 → 80 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=556
1789    47.551783    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 1653#2] 53059 → 80 [ACK] Seq=557 Ack=1 Win=262656 Len=0 SLE=0 SRE=1
1812    48.667374    192.168.0.80    192.168.1.10    TCP    610    [TCP Retransmission] 53059 → 80 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=556
1872    51.549157    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 1653#3] 53059 → 80 [ACK] Seq=557 Ack=1 Win=262656 Len=0 SLE=0 SRE=1
2433    53.467539    192.168.0.80    192.168.1.10    TCP    610    [TCP Retransmission] 53059 → 80 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=556
2447    54.158705    192.168.0.80    192.168.1.10    HTTP    55    [TCP Spurious Retransmission] Continuation
2463    55.158930    192.168.0.80    192.168.1.10    HTTP    55    [TCP Spurious Retransmission] Continuation
2486    56.159189    192.168.0.80    192.168.1.10    HTTP    55    [TCP Spurious Retransmission] Continuation

Hier nochmal als Bild, durch die Einfärbung hoffentlich etwas leichter lesbar:

Edit: habe gerade festgestellt, dass auch noch Verkehr mit den Routern dabei ist, ich versuche mal besser zu filtern. Habe alle relevanten Sätze in der Wireshark.csv gesichert.

 

[Raijin]

Schreib bitte auch dazu welchen Filter du verwendet hast oder lade ggfs das pcap File hoch. Es ist sonst schwierig zu beurteilen was fehlt. So sieht es beispielsweise aus als wenn du die eingehenden Pakete bzw. Antworten komplett rausfilterst. Das ist natürlich suboptimal, weil man dann nicht sieht ob die Antwort nur gefiltert wurde oder eben gar nicht erst angekommen ist.

Idealerweise lässt man nebenher übrigens WireShark/tcpdump auch auf dem Ziel mitlaufen und wenn dort gar nicht erst etwas ankommt oder man dort nicht mitschneiden kann, dann eben im ERX mitschneiden. So kann man den Weg von A über den ERX zu B verfolgen und sieht an welcher Stelle Schluss ist.

 

[Tranceport]

Filter war:

(ip.src == 192.168.0.80 or ip.dst == 192.168.0.80) and (ip.src > 192.168.0.0) and ip.dst > 192.168.0.0 and ip.dst != 192.168.0.10 and ip.src != 192.168.0.10 and ip.src < 192.168.178.255

Ich starte später einen neuen Versuch Zum Thema TCPDump im ERx muss ich mich leider erst einlesen.

 

[Raijin]

Kleiner Tip: ip.addr evaluiert ip.src und ip.dst gleichermaßen.


Statt

ip.src==A or ip.dst==A

kann man also einfach

ip.addr==A

schreiben. Machst du das für jeden Teilnehmer der gewünschten Verbindung, bekommst du auch nur diese Pakete mit:

ip.addr==A and ip.addr=B

Damit bekommst du alles was von A nach B oder von B nach A gesendet wird und kannst den Rest deines Filters weglassen

 

[Tranceport]

vielen Dank, sehr praktisch =)
Habes jetzt mal aufgeteilt, hier der komplette Ping von 0.80 auf 1.10:

10    3.287109    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=142/36352, ttl=128 (reply in 11)
11    3.288635    192.168.1.10    192.168.0.80    ICMP    74    Echo (ping) reply    id=0x0001, seq=142/36352, ttl=63 (request in 10)
16    4.289217    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=143/36608, ttl=128 (reply in 18)
17    4.289831    192.168.0.1        192.168.0.80    ICMP    102    Redirect             (Redirect for host)
18    4.290614    192.168.1.10    192.168.0.80    ICMP    74    Echo (ping) reply    id=0x0001, seq=143/36608, ttl=63 (request in 16)
22    5.292088    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=144/36864, ttl=128 (reply in 23)
23    5.293243    192.168.1.10    192.168.0.80    ICMP    74    Echo (ping) reply    id=0x0001, seq=144/36864, ttl=63 (request in 22)
33    6.294745    192.168.0.80    192.168.1.10    ICMP    74    Echo (ping) request  id=0x0001, seq=145/37120, ttl=128 (reply in 34)
34    6.295916    192.168.1.10    192.168.0.80    ICMP    74    Echo (ping) reply    id=0x0001, seq=145/37120, ttl=63 (request in 33)

Hier tracert mit Filter:

ip.addr == 192.168.0.80 and (ip.addr == 192.168.0.1 or ip.addr == 192.168.0.3 or ip.addr == 192.168.1.10 or ip.addr == 192.168.1.1)

um alle Pakete zu erhalten, die mein PC mit meinem DefGateway, dem Gateway ins Nachbarnetzt und der Diskstation austauscht:

41    5.429464    192.168.0.80    192.168.1.10    NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
42    5.442685    192.168.1.10    192.168.0.80    NBNS    235    Name query response NBSTAT
43    5.448304    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=146/37376, ttl=1 (no response found!)
101    8.999911    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=147/37632, ttl=1 (no response found!)
102    9.000483    192.168.0.1        192.168.0.80    ICMP    134    Time-to-live exceeded (Time to live exceeded in transit)
103    9.000873    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=148/37888, ttl=1 (no response found!)
104    9.001360    192.168.0.1        192.168.0.80    ICMP    134    Time-to-live exceeded (Time to live exceeded in transit)
151    10.006000    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=149/38144, ttl=2 (no response found!)
152    10.007028    192.168.0.3        192.168.0.80    ICMP    134    Time-to-live exceeded (Time to live exceeded in transit)
153    10.007402    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=150/38400, ttl=2 (no response found!)
154    10.007958    192.168.0.3        192.168.0.80    ICMP    134    Time-to-live exceeded (Time to live exceeded in transit)
155    10.008286    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=151/38656, ttl=2 (no response found!)
156    10.008781    192.168.0.3        192.168.0.80    ICMP    134    Time-to-live exceeded (Time to live exceeded in transit)
159    10.011363    192.168.0.80    192.168.0.3        NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
160    10.011540    192.168.0.3        192.168.0.80    ICMP    120    Destination unreachable (Port unreachable)
182    11.511287    192.168.0.80    192.168.0.3        NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
183    11.511625    192.168.0.3        192.168.0.80    ICMP    120    Destination unreachable (Port unreachable)
203    13.017826    192.168.0.80    192.168.0.3        NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
204    13.018138    192.168.0.3        192.168.0.80    ICMP    120    Destination unreachable (Port unreachable)
218    15.520178    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=152/38912, ttl=3 (reply in 219)
219    15.521346    192.168.1.10    192.168.0.80    ICMP    106    Echo (ping) reply    id=0x0001, seq=152/38912, ttl=63 (request in 218)
220    15.521714    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=153/39168, ttl=3 (reply in 221)
221    15.522415    192.168.1.10    192.168.0.80    ICMP    106    Echo (ping) reply    id=0x0001, seq=153/39168, ttl=63 (request in 220)
222    15.522759    192.168.0.80    192.168.1.10    ICMP    106    Echo (ping) request  id=0x0001, seq=154/39424, ttl=3 (reply in 223)
223    15.523414    192.168.1.10    192.168.0.80    ICMP    106    Echo (ping) reply    id=0x0001, seq=154/39424, ttl=63 (request in 222)
226    15.526053    192.168.0.80    192.168.1.10    NBNS    92    Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
227    15.526964    192.168.1.10    192.168.0.80    NBNS    235    Name query response NBSTAT

Und mit demselben Filter der Zugriff auf 192.168.1.10:5000:

15    4.036838    192.168.0.80    192.168.1.10    TCP    66    55651 → 5000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
16    4.038351    192.168.1.10    192.168.0.80    TCP    66    5000 → 55651 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
17    4.038390    192.168.0.80    192.168.1.10    TCP    54    55651 → 5000 [ACK] Seq=1 Ack=1 Win=262144 Len=0
18    4.038493    192.168.0.80    192.168.1.10    HTTP    466    GET / HTTP/1.1
66    4.338882    192.168.0.80    192.168.1.10    TCP    466    [TCP Retransmission] 55651 → 5000 [PSH, ACK] Seq=1 Ack=1 Win=262144 Len=412
67    4.339374    192.168.0.1        192.168.0.80    ICMP    494    Redirect             (Redirect for host)
69    4.938934    192.168.0.80    192.168.1.10    TCP    466    [TCP Retransmission] 55651 → 5000 [PSH, ACK] Seq=1 Ack=1 Win=262144 Len=412
70    4.939533    192.168.0.1        192.168.0.80    ICMP    494    Redirect             (Redirect for host)
72    5.232805    192.168.1.10    192.168.0.80    TCP    66    [TCP Retransmission] 5000 → 55651 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
73    5.232830    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 17#1] 55651 → 5000 [ACK] Seq=413 Ack=1 Win=262144 Len=0 SLE=0 SRE=1
74    5.233471    192.168.0.1        192.168.0.80    ICMP    94    Redirect             (Redirect for host)
81    6.138992    192.168.0.80    192.168.1.10    TCP    466    [TCP Retransmission] 55651 → 5000 [PSH, ACK] Seq=1 Ack=1 Win=262144 Len=412
82    6.139463    192.168.0.1        192.168.0.80    ICMP    494    Redirect             (Redirect for host)
90    7.231850    192.168.1.10    192.168.0.80    TCP    66    [TCP Retransmission] 5000 → 55651 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
91    7.231880    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 17#2] 55651 → 5000 [ACK] Seq=413 Ack=1 Win=262144 Len=0 SLE=0 SRE=1
92    7.232411    192.168.0.1        192.168.0.80    ICMP    94    Redirect             (Redirect for host)
96    8.539032    192.168.0.80    192.168.1.10    TCP    466    [TCP Retransmission] 55651 → 5000 [PSH, ACK] Seq=1 Ack=1 Win=262144 Len=412
97    8.539641    192.168.0.1        192.168.0.80    ICMP    494    Redirect             (Redirect for host)
109    11.228885    192.168.1.10    192.168.0.80    TCP    66    [TCP Retransmission] 5000 → 55651 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
110    11.228911    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 17#3] 55651 → 5000 [ACK] Seq=413 Ack=1 Win=262144 Len=0 SLE=0 SRE=1
111    11.229409    192.168.0.1        192.168.0.80    ICMP    94    Redirect             (Redirect for host)
115    13.339201    192.168.0.80    192.168.1.10    TCP    466    [TCP Retransmission] 55651 → 5000 [PSH, ACK] Seq=1 Ack=1 Win=262144 Len=412
149    19.223678    192.168.1.10    192.168.0.80    TCP    66    [TCP Retransmission] 5000 → 55651 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
150    19.223703    192.168.0.80    192.168.1.10    TCP    66    [TCP Dup ACK 17#4] 55651 → 5000 [ACK] Seq=413 Ack=1 Win=262144 Len=0 SLE=0 SRE=1
151    19.224402    192.168.0.1        192.168.0.80    ICMP    94    Redirect             (Redirect for host)
158    22.939729    192.168.0.80    192.168.1.10    TCP    54    55651 → 5000 [RST, ACK] Seq=413 Ack=1 Win=0 Len=0

In den Anhang habe ich den kompletten Wiresharklog für den Zugriff auf 1.10:5000 gespeichert.

 

[PhilAd]

Ich sehe jede Menge TCP Retranmissions ... ich würde mal im ERx MSS Clamping, um die Pakete dort zu 'normalisieren', konfigurieren ...

set firewall options mss-clamp interface-type all
set firewall options mss-clamp mss 1300

Anstelle von all kannst du auch die beiden ports angeben. Für TCP sollten 40bytes berücksichtigt werden, so wie es aussieht auch erstmal korrekt bei einer MTU von 1500 auf beiden Seiten. Er nimmt nämlich MSS 1460 bei IPv4 ... bei IPv6 wären es nochmal 20 weniger.
Verwendest du MSS Clamping mit unterschiedlichen Werten lässt sich auch pro Interface eine Modify Regel anwenden z.B.:

set firewall modify deinemss rule 1 action modify
set firewall modify deinemss rule 1 modify tcp-mss 1300
set firewall modify deinemss rule 1 protocol tcp
set firewall modify deinemss rule 1 tcp flags 'SYN,!RST'
set interfaces ethernet ethX firewall in modify deinemss
set interfaces ethernet ethX firewall out modify deinemss

Wäre nur ein Test, weil es bei einer 1500er MTU - und ich gehe davon aus das keine zusättlichen header verwendet werden - eigentlich bereits korrekt wäre.

 

[Tranceport]

vielen Dank für eure Beiträge =). Habe überlegt, wie ich das Problem mit zwei ISPs zufriedenstellend lösen kann: meinen Server wollte ich eh auf 10Gbit mittels SFP+ umrüsten. Viele Karten haben zwei Ports, wenn ich also den Lichtwellenleiter direkt in meinen Server stecke (den ERx auf der anderen Seite) können beide Netze auf meinen Server zugreifen, und der Server auf beide Internetgateways. Dann hat sich auch das Problem mit den Routen erledigt, zumindest in der Theorie?

 

[PhilAd]

Wenn du das Routing zwischen den beiden Netzen rausnimmst und den Server zweibeinig anbindest sehe ich da kein Problem.

 

[Raijin]

Was den Server selbst angeht, wäre das Problem gelöst, in der Tat. Man muss dann aber zwei Szenarien unterscheiden:

a) Server in beiden Netzen und ERX verbleibt als Router zwischen den Netzen
--> Server darf NICHT routen (IP Forwarding deaktiviert), weil der ERX das tut und etwaige Regeln definiert.

b) Server in beiden Netzen und ERX fliegt raus
--> Server muss auch als Router fungieren

 

[Tranceport]

So, tut mir leid dass meine Antwort so spät kommt, ich bin wegen Jobwechsels leider nicht dazu gekommen.

Die SFP+ Karte steckt jetzt im Server, und ist über ein 1G Modul (welches davor im UnifiSwitch48 gesteckt hat) mit dem ERx verbunden. Im ERx habe ich die beiden Ports zwischen den Netzten (und den Port an dem die Diskstation hängt) auf den Switch gehängt (Port4 zur Konfiguration übrig gelassen). Der Zugriff auf meinen Server geht jetzt erwartungsgemäß problemlos aus beiden Netzen.

Aktuell hänge ich noch daran, einen Docker Container zu überreden über eth1 (SFP mit Internetgateway 178.1) ins Internet zu gehen, statt eth0 (StandardGateway des Servers 192.168.0.1) UND gleichzeitig über ServerIP 192.168.0.10 mit Port x ansprechbar zu bleiben.

An der Stelle ein dickes Dankeschön an euch für die vielen Beiträge und Denkanstöße, habe viel gelernt =)

 

[Ebrithil]

Aktuell hänge ich noch daran, einen Docker Container zu überreden über eth2 (SFP mit Internetgateway 178.1) ins Internet zu gehen, statt eth0 (StandardGateway des Servers 192.168.0.1) UND gleichzeitig über ServerIP 192.168.0.10 mit Port x ansprechbar zu bleiben.

AFAIK müsste das gehen, wenn du den Container per MACVLAN ins eth2 netz hängst und den Port ganz normal auf die ServerIP mappst

 

[Tranceport]

AFAIK müsste das gehen, wenn du den Container per MACVLAN ins eth2 netz hängst und den Port ganz normal auf die ServerIP mappst

Das war auch mein erster Gedanke & Versuch, allerdings bekommt ein Container im MACVLAN Netz eine eigene Adresse im jeweiligen Subnetz (in diesem Fall 178.x) und das Portmapping verschwindet (in Portainer nachgeprüft) Von 0.x komme ich dann nicht mehr drauf

 

[Raijin]

Ich habe jetzt ehrlich gesagt ein bischen den Faden verloren. Kannst du vielleicht eine Skizze vom Status Quo machen? Mit allen Kabeln und IPs zwischen den Netzwerken bzw. dem ERX und dem Server sowie Angaben was von wo nu wie erreicht werden soll.

Da Docker ein virtuelles Subnetz für die Container erzeugt, sind selbige nur über Portweiterleitungen aus dem Docker-Host-Prozess erreichbar. Nur dieser läuft nativ auf dem System. Wenn ein Container über zwei verschiedene IPs erreichbar sein soll, muss entweder das Hostsystem über zwei IPs verfügen und von diesen aus die Ports für den Container weiterleiten oder aber in einer Routing-Ebene weiter oben (ERX) findet ein entsprechendes NAT statt. Es kommt aber im Detail darauf an wie aktuell alles verkabelt ist, etc.

 

[Tranceport]

Ich habe jetzt ehrlich gesagt ein bischen den Faden verloren. Kannst du vielleicht eine Skizze vom Status Quo machen? Mit allen Kabeln und IPs zwischen den Netzwerken bzw. dem ERX und dem Server sowie Angaben was von wo nu wie erreicht werden soll.

Da Docker ein virtuelles Subnetz für die Container erzeugt, sind selbige nur über Portweiterleitungen aus dem Docker-Host-Prozess erreichbar. Nur dieser läuft nativ auf dem System. Wenn ein Container über zwei verschiedene IPs erreichbar sein soll, muss entweder das Hostsystem über zwei IPs verfügen und von diesen aus die Ports für den Container weiterleiten oder aber in einer Routing-Ebene weiter oben (ERX) findet ein entsprechendes NAT statt. Es kommt aber im Detail darauf an wie aktuell alles verkabelt ist, etc.

Habe das bestehende Modell angepasst, ich hoffe es ist verständlich. Es gibt keine Routen mehr, ERx hat die beiden Ports auf dem Switch.
Mein UnraidServer hat jetzt jeweils einen physischen Anschluss pro Subnetz (eth1 178.10 und eth0 0.10), das Default Gateway im System ist aber die 0.1, dh. Unraid und alle Container gehen über den DGA4132 ins Internet.

Der Plan war ja, dass Unraid aus beiden Netzen erreichbar ist (Check!) und bestimmte Dockercontainer auf dem Unraid-Host nicht über das DefaultGateway des Hosts (0.1) ins Internet gehen, sondern über die Fritzbox (178.1) UND weiterhin aus beiden Netzen über Portbinding an den Host verfügbar bleiben.

Wenn ich aber ein MACVLAN auf eth1 erstelle, bekommt der zugeordnete Container eine IP aus diesem Netz (178.x) und das Portbinding verschwindet, dh. über 192.168.0.10:xxxx ist er nicht mehr erreichbar.

 

[Raijin]

Sorry, aber hä? Jetzt hast du den ERX mit einem Switch gebrückt? Was soll der ERX für einen Zweck erfüllen, wenn er nur noch im Haus2-LAN unterwegs ist und vom Haus1-LAN abgeschnitten ist? Du kannst doch nun effektiv direkt das Kabel von Haus2 in eth1 vom Server stecken oder den ERX sonst selbst als Switch konfigurieren falls das Kabel einfach nicht lang genug ist. Switch und ERX ist aber zu viel des Guten.


Wie dem auch sei, um einzelne Container explizit über eth1 statt eth0 ins Internet gehen zu lassen, musst du PBR einrichten, Policy Based Routing. Dabei markierst du die Pakete, die den Kriterien entsprechen (zB Source container3-ip) und weist diesen Paketen eine separate Routingtabelle zu, in der dann eben 178.1 das Standardgateway ist.

 

[Tranceport]

Mit dem Bild wollte ich zeigen, dass ich die beiden ports des ERx jetzt nicht mehr als einzelne Interfaces mit eigener IP konfiguriert habe, sondern die ports auf den ERx-internen Switch0 gelegt habe. Ist mir wohl nicht so gut gelungen =(

Der ERx übersetzt jetzt quasi einfach das 178.x Netz von Kupfer auf Lichtwelle, auf den eth1 Port meines Unraid-hosts. PBR klingt gut, vielen Dank,sehe ich mir an =)