oder auch nicht!

Ich war so froh drum, dass das mit NAT (Network Adress Translation) funktioniert hat, dass ich ganz übersehen hatte… f..k ich hab ja jetzt NAT!

Was macht NAT eigentlich… nuja die Maschinen kommen mit ihren Anfragen ans Internet über die default Route irgendwann bei puffy-lab-1 an der behauptet jetzt gegenüber dem Netzwerk in dem sich der Router befindet… ER wolle die Daten. Sobald er die Daten erhält gibt er sie an die Maschine welche die Daten abgefragt hat. Warum macht man sowas? Damit man weniger machen muss. Während die Routing Tabellen auf puffy-lab-{2,3} und raspi-lab-{1,2} immer nur auf den nächsten Router in der Liste verweisen. Verweist puffy-lab-1 in der Richtung zu den anderen Netzen auf beide Router oder, je nachdem wieviele reinkommen auf alle anderen Router/Gateway, die so genannte Rückroute. Soweit so gut.
Nachteil ist halt, für Komponenten die etwas weiter hinten liegen sind die Routen unschärfer, weil diese ja „glauben“ sie Kommunizieren mit puffy-lab-1 und somit funktionieren vorherige Routen ggf. nicht mehr.
Genau das ist bei mir passiert. Ich kam von links unten (eigentlich muss das Bild spiegeln, der SSH Endpunkt sitzt afaik in Jena) nicht mehr zu den raspi-lab’s

Es gibt natürlich Möglichkeiten das zu umgehen: Etwa Ports umleiten oder ein zweites Kabel verlegen und die Routen dementsprechend anpassen…
Das will man beides nicht wirklich… hier zwar kein wirkliches Problem, aber IRL will man das auch nicht.
Mein erster Gedanke war die physische Netzwerk Karte oder kurz NIC (Network Interface Card) in 2 virtuelle NICs umzuwandeln, um dann den Internet (externe) Teil über das eine und den internen Teil über das andere zu leiten. Und hatte mit dieser Idee und einem schlechten Wortwitz dazu, auch schon Forumskollegen genervt ob das machbar sei. Aber mal wieder viel zu kompliziert gedacht.
Einfacher kommt man mit einem VLAN oder besser SVLAN (Stacked VLAN nach IEEE 802.1ad) weg… dort werden zwar auch NIC’s aufgeteilt, aber in n virtuelle auf eine physikalische NIC. Das ganze muss n+1 mal gemacht werden. Einmal auf jedem Gateway das mit dem VLAN (Virtual Lacal Area Network) verbunden werden soll.
z.B. auf puffy-2 (dem lokalen SSH Tunnel Endpunkt)

ifconfig svlan0 create #man kann einem svlan Gerät nur eine IP Adresse zuordnen, will man mehrere haben kann die Zahl abweichen
ifconfig svlan0 parent em0 vnetid 20 #parent gibt eine NIC an, das sollte die sein, die sich im ISP Router Netzwerk treffen. vnetid könnte man mit einem Switch vergleichen der die Enden mehrer NIC's miteinander verbindet
ifconfig svlan0 172.16.56.1/27 #das ist wie der Aufbau eines physischen Netzwerkes 

Die Routen dann natürlich über das neue svlan legen.

Auf puffy-2:

route add 172.16.71.0/24 172.16.56.2
route add 172.16.65.0/24 172.16.56.2
route add 172.16.79.0/24 172.16.56.2

Auf puffy-lab-1:

route add <tunnel netzwerk> 172.16.56.1

Jetzt sieht das Netzwerk so aus:

Und jetzt kommen ich auch wieder aus Jena nach München, ohne dass ich irgendeinen Port blöd durch den ISP und andere Router umleiten muss.

Dieser Beitrag wurde unter APU4b4, Hardware, Netzwerk, OpenBSD, routing veröffentlicht. Setze ein Lesezeichen auf den Permalink.