Gateway ist Teil der statischen Route

[Bob.Dig]

Netzwerknoob fragt sich folgendes:

Ich habe eine statische Route angelegt für
172.17.0.0/20
dabei habe ich
172.17.0.1
als das Gateway definiert.

Dieses Gateway ist Teil von
172.17.0.0/24.

Wäre es Teil von
172.17.0.0/31
gewesen, wäre es vermutlich kein Problem.

Einschätzungen, Zurechtweisungen, etc. willkommen. 😀 @riversource @Raijin

 

[till69]

Und warum nicht die IP in Deinem Netz, über den 172.17.0.0/20 erreichbar ist?

 

[Kapsler]

Was ist jetzt die Frage bzw. das Problem?

 

[Bob.Dig]

@Kapsler Ob man das so machen kann oder eher bad practice ist.

 

[TheCadillacMan]

Da sehe ich eigentlich kein Problem dran.
Die Routen zu direkt verbundenen Netzen (hier 172.17.0.0/24) werden ja bevorzugt zu statischen Routen behandelt. Also bleibt der Gateway und damit auch das Supernetz 172.17.0.0/20 erreichbar.
Bei VPNs mit Split Tunneling habe ich das schon öfter gemacht wobei die VPN-Clients z. B. in 10.10.200.0/24 sind und eine Route für 10.10.0.0/16 gepusht bekommen um die anderen Subnetze hinterm Gateway erreichen zu können.

Bei einem lokalen Netz würde ich allerdings fragen wieso es für das Supernetz eine statische Route braucht und es nicht über die Default Route erreichbar ist. Wenn das Routing in ein über- oder nebengeordnetes (hier z. B. 172.17.1.0/24) Netz gehen soll finde den Weg über den Default Gateway i. d. R. etwas übersichtlicher.

 

[Kapsler]

Ich verstehe ehrlich gesagt nicht ganz, wie die einzelnen Aussagen zusammenhängen, aber gut

Wenn du eine Route für 172.17.0.0/20 anlegst, wirst du dir bei der Dimensionierung des Netzes ja was gedacht haben oder es war eben Vorgabe. Aus meiner Erfahrung legt man das Gateway entweder auf die .1 des ersten Netzes oder .254 des letzten. Also 172.17.0.1 oder 172.17.15.254. Deine Wahl passt also.

Wo ist jetzt das Problem in Zusammenhang mit dem Subnetz 172.17.0.0/24? Falls du tatsächlich eine weitere Route für dieses Class C Netz erstellen willst, das über einen anderen Hop erreichbar ist, kannst du das theoretisch machen. Da diese Route spezifischer bzw. enger gefasst ist als /20 wird diese zuerst ausgewertet. Dann bräuchtest du allerdings tatsächlich ein anderes Gateway. Wirklich sinnvoll ist ein derartiges Konstrukt aber nicht.

Mit 172.17.0.0/31 hast du im Prinzip keine freien IP-Adressen zur Verfügung, da .0 der Netzidentifikation dient und .1 die Broadcast-Adresse wäre. Für Transfernetze zwischen zwei Hosts nutzt man idR einen /30-Adressbereich.

 

[Raijin]

Es ist immer bad practice, wenn die Subnetzmaske nicht übereinstimmt. Für ein Gerät mit der IP 172.17.1.234/20 läge das Gateway 172.17.0.1 im selben Subnetz und würde direkt angesprochen werden. Für das Gateway mit 172.17.0.1/24 liegt die IP des anderen Geräts jedoch nicht im selben Subnetz und dann schickt das Gateway die Antwort an diese IP tendenziell nicht direkt, sondern über das Gateway des Gateways sozusagen. Hintergrund ist folgender:


Innerhalb desselben Subnetzes macht der Absender einen ARP-Request und fragt wer die gewünschte Ziel-IP hat. Dieser ARP geht als Broadcast ins Netz. Das Gerät mit der angefragten IP fühlt sich angesprochen und antwortet direkt an den Absender, also Unicast und nicht mehr Broadcast. Damit hat der Absender die MAC des Ziels und schickt die eigentlichen Datenpakete auf die Reise. Im L3-Header steht die IP des Ziels und im L2-Header die MAC des Ziels.

Liegt die Ziel-IP jedoch ausserhalb des eigenen Subnetzes, läuft das anders. Der Absender macht sich nicht mehr die Mühe, per ARP nach dem Ziel zu fragen, weil es ja in einem anderen Subnetz liegt und das heißt -----> Das Gateway weiß wie man da hinkommt. Folglich startet der Absender einen ARP-Request nach der IP des Gateways, Das Gateway antwortet und der Absender schickt die Datenpakete los. Dieses Mal steckt jedich im L3-Header zwar immer noch die Ziel-IP, aber im L2-Header steht die MAC des Gateways.

Wenn jetzt die Geräte und das Gateway in unterschiedlichen btw sich überschneidenden Subnetzen liegen, kann dieser Prozess durcheinanderkommen. Es funktioniert womöglich trotzdem, aber es ist bestenfalls eine Grauzone.

Ein Netzwerk, ein Subnetz. Das ist der übliche Weg. Ungleiche Subnetzmasken sollte man vermeiden, weil es gegebenenfalls noch weitere Dinge gibt, die durcheinanderkommen können. Ethernet-Broadcasts, also MAC FF:FF:FF:FF bzw limited Broadcasts mit IP 255.255.255.255 mögen noch klappen, aber beim directed Broadcast, der letzten IP des jeweiligen Subnetzes funktioniert es dann nicht mehr, weil diese IP eben nur für jene getriggert wird, deren Subnetzmaske dazu passt. Für alle anderen ist es entweder eine beliebige Host-IP im Subnetz oder sie liegt gar außerhalb des Subnetzes.


Fazit: Lass es lieber...

 

[Bob.Dig]

@Raijin Um das klarzustellen, das Gateway ist ein Router und dieser hat verschiedene /24-Netze aus dem Bereich /20, aber nicht ein großes /20-Netz.

Ich hab hier bisher nur "Transfernetze" genutzt, die nicht selbst Teil der Routen waren und es jetzt einmal anders gemacht. Bin mir aber noch nicht sicher, ob ich weitere Hosts in dieses packen kann.

@TheCadillacMan Du siehst da eher kein Problem, danke für deine Einschätzung.

Ergänzung (13. Oktober 2023)

Für Transfernetze zwischen zwei Hosts nutzt man idR einen /30-Adressbereich.

Ich habe oft /31 gesehen und auch selbst genutzt, das hat bisher geklappt (WireGuard bzw. kein VPN). Aber das war ja nicht die Frage, denn eigentlich soll das mehr als ein reines Transfernetz sein.

Ergänzung (13. Oktober 2023)

Vielleicht noch etwas zu dem Hintergrund, auch wenn es hier nicht das Thema sein soll. Ich habe daheim auf einem Hyper-V Host eine pfSense-VM als Router für das gesamte Netz am Laufen. Nun habe ich auf eine weitere VM Proxmox VE installiert und in diesem weitere, nested VMs. Dies soll quasi eine Vorlage für andere PVE Installationen auf externen VPSen sein. Jedes PVE erhält dabei eine eigene pfSense-VM. Nun muss ich halt diese hintereinander betreiben. So soll z.B. das Proxmox Mail Gateway als LXC hinter der zweiten pfSense auf dem PVE laufen. Email kommt dann durch die erste Sense auf die zweite Sense und dan zum vorläufigen Ziel. Den PVE Part möchte ich dann so auf einen externen VPS quasi spiegeln.
Aber wurscht, soll und ist nicht das Thema.

 

[Raijin]

Um das klarzustellen, das Gateway ist ein Router und dieser hat verschiedene /24-Netze aus dem Bereich /20, aber nicht ein großes /20-Netz

Aha. Und was bezweckst du damit? Dein Konzept verstehe ich offengestanden 0,garnicht aber es ist 2 Uhr nachts und ich bin müde.. Das klingt aber ziemlich strange, um es vorsichtig auszudrücken.

Fakt ist und bleibt, dass ungleiche Subnetzmasken problematisch sind und je nachdem ob

• Quelle und Ziel in der Schnittmenge beider Subnetze liegen
• Die Quelle innerhalb des Bereichs des Ziel-Subnetzes liegt, aber nicht andersherum
• Das Ziel innerhalb des Bereichs des Quell-Subnetzes liegt, aber nicht andersherum

können unerwartete Phänomene auftreten, und zwar dann, wenn eigenlich unnötig geroutet wird oder eben (directed) Broadcasts aneinander vorbeigehen.

Ein Subnetz, eine Subnetzmaske - auf allen Netzwerkteilnehmern. So ist es gedacht. Prinzipiell sieht man die zugrundeliegende Problematik ganz einfach in der Situation, wenn man zB einen Netzwerkdrucker mit statischer IP aus einem anderen Subnetz ins Netzwerk klinkt. Weder kann man den Drucker dann pingen, noch kann man auf ihm drucken, obwohl er ggfs im Switchport direkt neben dem PC steckt. Der PC versucht aber gar nicht erst, den Drucker direkt zu kontaktieren, weil anderes Subnetz -> Routingtabelle -> Gateway. Kennt das Gateway das Subnetz des Druckers auch nicht, geht der Ping eben ins Gateway des Gateways usw.

Liegen PC und Drucker hingegen in überschneidenden Subnetzen, kommt es wie oben dargelegt darauf an in welcher Teilmenge sie konkret liegen.

Alles in allem ist das kein wünschenswerter Zustand und kann zu beliebig unzuverlässigem Kommunikationsverhalten führen. WENN man das unbedingt so machen will, sollte der Router jedes der 16 /24er Subnetze des /20er Subnetzes bedienen können, um wenigstens die Basiskommunikation zu gewährleisten, unabhängig von etwaigen Subnetz-Broadcasts, welche zwischen diesen Geräten in keinem Fall funktionieren würden.. .. das heißt nein, das letzte /24er Subnetz hätte dieselbe Broadcast-Adresse wie das /20er Netz, das könnte sogar gehen, aber nur da.

 

[Bob.Dig]

Und was bezweckst du damit?

Moin, es handelt sich um eine Site2Site Verbindung zwischen zwei Sensen (hätte ich anfangs erwähnen sollen), auch wenn quasi alles lokal bei mir zuhause steht. Die Sense der Site 2 soll mehrere Netze bedienen. Um nicht für jedes einzelne dieser Netze eine Route anlegen zu müssen, gibt es stattdessen eine "große" Route. GeNATet wird nichts von dem, was geroutet wird.

So weit, so normal würde ich vermuten. Vielleicht liege ich aber auch komplett daneben? 🤔

Nur das diesmal das Transfernetz auch Teil der Route ist. Und möglicherweise auch mehr als zwei Hosts enthält.

Sense 1:

Wenn es aber eh priorisiert wird, sehe ich kein Problem.

Nicht desto trotz habe ich bisher eher separate Transfernetze gesehen. Da das hier aber lokal stattfindet, wollte ich keine VPN-Verbindung nutzen und werde es jetzt so versuchen (natürlich könnte ich dennoch ein separates Netz dafür nutzen).

Ich werde jetzt noch mal @Raijin s Beiträge hoch und runter lesen, ob ich etwas übersehen habe, sofern ich es verstehen kann. Edit: Mein Eindruck ist, dass Raijin tatsächlich über etwas anderes geschrieben hat. Überlappende Subnetze sind sicher schlecht, hier ist aber nur eine Route überlappend.

 

[Bob.Dig]

Mir ist eingefallen, dass wenn ich noch weitere Hosts in diesem Transfernetz habe, es ohne NATing zu asymmetrischem Routing kommen kann, welches natürlich unerwünscht ist. Beispiel: Rechner hinter der Sense 1 spricht mit dem Proxmox Host, welcher auch im Transfernetz ist. Da dieser die Route nicht kennt, geht der Traffic erst mal zur Sense 2, die ihn dann wieder an Sense 1 leitet.

Also sollte es bei nur zwei Teilnehmern bleiben.

Daher eine andere Frage hinterher, was @Kapsler schon angeschnitten hat. Ist ein /31-Subnetz auf einem vLAN (kein VPN) schlecht? Broadcasting etc. funktioniert dann vermutlich nicht, würde aber eh keinem Zweck dienen. Fachkundige Meinungen erwünscht!

 

[Kapsler]

Daher eine andere Frage hinterher, was @Kapsler schon angeschnitten hat. Ist ein /31-Subnetz auf einem vLAN (kein VPN) schlecht? Broadcasting etc. funktioniert dann vermutlich nicht, würde aber eh keinem Zweck dienen. Fachkundige Meinungen erwünscht!

Da ich das Thema aufgeworfen habe, noch mal 1-2 Sätze dazu.

Konfigurationen mit /31-Maske für Verbindungen zwischen zwei Hosts (Punkt-zu-Punkt) sind grundsätzlich möglich und auch offizieller Standard (RFC3021). Allerdings wird das nicht von jedem Netzwerkgerät (besonders älteren) problemlos unterstützt. Sofern man weiß man was tut, die beteiligten Hosts unter seiner Kontrolle hat und kein Broadcast benötigt.. go for it.

Wie aus dem RFC hervorgeht war die Intention dabei primär (mal wieder) der Knappheit von öffentlichen IPv4-Adressen zu begegnen. In privaten (Heim-) Netzen kommt man dagegen eher selten an die Grenzen des Adressraums. Mir wurde damals beigebracht: Transfernetz => /30-Maske. Damit ist man auf der sicheren Seite und braucht sich keinen Kopf bzgl. möglicherweise unerwartetem Verhalten zu machen.

 

[Raijin]

Die Sense der Site 2 soll mehrere Netze bedienen. Um nicht für jedes einzelne dieser Netze eine Route anlegen zu müssen, gibt es stattdessen eine "große" Route. GeNATet wird nichts von dem, was geroutet wird.

Das wiederum ist etwas anderes. Letztendlich ist die Standardroute nichts anderes, sei es die Route des Standardgateways oder beispielsweise die /1 overrides von OpenVPN (0.0.0.0/1 + 128.0.0.0/1). Hierbei wird auch nicht davon ausgegangen, dass hinter dem Gateway dieser Route(n) zwingend ein exakt so großes Subnetz liegt. Als Sammel-Route für mehrere hinter dem Gateway liegende Subnetze ist das also kein Problem und dann gibt es auch keine Konflikte. Die oben beschriebene Problematik entsteht, wenn man innerhalb eines Layer2-Netzwerks mehrere Subnetze mit ungleichen/überlappenden Subnetzen verwendet, weil dadurch ARP und dergleichen unvorhergesehenes Verhalten aufweisen können.

Mir ist eingefallen, dass wenn ich noch weitere Hosts in diesem Transfernetz habe, es ohne NATing zu asymmetrischem Routing kommen kann, welches natürlich unerwünscht ist.

Für jede weitergehende Beurteilung wird eine vollständige Übersicht der Netzwerke mit allen beteiligten Infrastrukturgeräten benötigt, weil wir sonst erneut aneinander vorbeireden.