aaron2222
Goto Top

Mehrere default routen, ausgehende pakete über selbe route schicken

Ich habe momentan 2 verschiedene Router um ins Internet zu kommen: Einen Linux Router und einen von LANCOM. Beide Router machen NAT und sind intern am 10.10.0.0/16er Netz.

Meine Frage:
Auf dem LANCOM Router gibt es eine Portweiterleitung für mich. Ich mochte jedoch nicht explizit bei mir alles so umlegen, dass es über diesen geht, sondern möchte, dass eine Verbindung, welche über den LANCOM reingeht auch über diesen beantwortet wird. Wie ist dies möglich.

Beispiel:
Portweiterleitung auf dem LANCOM: Port 22 extern an meinen Rechner Port 22
Default route auf dem rechner jedoch über 10.10.5.8

Will ich nun per ssh auf meinen Rechner funktioniert es nicht, da die Antwort von einer anderen IP kommt und somit vom Router verworfen wird.

Bürorechner aktuelles Linux (Arch Linux).

Mir ist klar, dass es möglich ist einfach die Defaulte-Route auf den LANCOM zu legen und alles funktioniert. Jedoch gibt es andere dienste die nur vom Linux Router kommen und somit über diese Verbindung weitergeleitet werden müssen.

Eine mögliche lösung wäre ein Seperates Netz zu nehmen (Beispielsweise 10.11.0.0/16). Jedoch würde mich interresieren ob es nicht einen anderen Weg gibt.

Gruß Aaron

Content-Key: 190213

Url: https://administrator.de/contentid/190213

Printed on: April 19, 2024 at 21:04 o'clock

Member: 2hard4you
2hard4you Aug 26, 2012 at 21:37:59 (UTC)
Goto Top
Zitat von @Aaron2222:


Mir ist klar, dass es möglich ist einfach die Defaulte-Route auf den LANCOM zu legen und alles funktioniert. Jedoch gibt es
andere dienste die nur vom Linux Router kommen und somit über diese Verbindung weitergeleitet werden müssen.


Moin,

der Sinn vom VPN ist doch, von außerhalb auf das gesamte Netz zugreifen zu können, damit auch Du, wenn Du über den LANCOM kommst und dann INTERN auf den Linuxrouter zugreifst....

Entweder hast Du nen Denkfehler oder der Zusammenhang mit dem Linuxrouter noch nicht genug erläutert....

Gruß

24
Member: danielfr
danielfr Aug 26, 2012 at 21:44:19 (UTC)
Goto Top
So wie ich das verstanden habe lässt er sich Port 22 weiterleiten, also kein VPN...
Nach meinem Verständnis sollte das aber funktionieren, da ja eine Portweiterleitung die Quelladresse ebenfalls ändert und somit auch nichts über den 10.10.5.8 geroutet werden sollte? Ich hatte jedenfalls auch schon zwei Router in einem Subnetz im Einsatz und hatte mit diesem Szenario keine Probleme.
Member: aqui
aqui Aug 27, 2012 updated at 13:54:06 (UTC)
Goto Top
Nein, das kann so in diesem Design niemals funktionieren. Ist ja klar... er macht Port Forwarding auf Router A auf einen Port (hier 22) auf eine lokale IP Adresse. Diese hat aber Router B als Default Gateway eingetragen.
Und da nimmt das Unglück dann seinen Lauf...
Ein Paket Walkthrough sieht so aus:
Paket (TCP 22, SSH) kommt von remoter IP und wird als Zieladresse an Router A (WAN Port) gesendet, der forwardet das intern an Rechner X und der antwortet an die remote Absender IP jetzt über Router B (sein Default Gateway) Router B schickt das Paket an den remoten Absender wo es nun aber mit einer völlig anderen Absender IP ankommt (B macht wie A NAT auf die ISP Adresse am WAN Port) als die ursprüngliche Zieladresse von Router A (WAN Port).
Für den TCP/IP Stack am remoten rechner ein Absender IP Mismatch und er verwirft sofort dieses Paket !
Logisch also das das niemals geht ! Kommt man eigentlich auch leicht von selber drauf wenn man sich den Paket Weg nur mal vor Augen führt !
Dadurch das der Rechner im internen Netz fest, statisch ein anderes Default Gateway konfiguriert hat, wird das so nie gehen auch nicht mit PBR Routing, denn eine dynmaische Umschreibung des Default Gateways je nach eigehendem Paket ist natürlich Utopie und technisch so nicht möglich.
Lösen kann man es nur mit einem Dual WAN Port Router oder wenn die beiden o.a. Router VRRP supporten würden (Wenigstens der Linux Router kann das !, Lancom = Handbuch ??)) über eine virtuelle Gateway IP am LAN Port. So löst man das Problem der 2 möglichen Gateway IPs in den lokalen Endgeräten.
Der Kardinalsfehler ist also schon weit vorher im grundlegenden Design bzw. der Auswahl der verwendeten Router Hardware gemacht worden und ist dann ohne DAS zu ändern so nicht lösbar !!