Routingfrage

[just2enjoy]

Ich bin ein wenig ratlos, welche Einstellungen ich im Router 1 und dem NAS1 vornehmen muss, wenn ich vom Desktop aus auf den NAS2 zugreifen möchte und zwar über den VPN-Tunnel zwischen NAS1 und NAS2.
Der NAS1 und der Desktop sind lokal im gleichen Netz.

 

[dil88]

Ich bin kein VPN-Experte, aber meiner Ansicht nach müsstest Du den Tunnel zwischen den beiden Routern laufen lassen, damit Du vom Desktop durch den Tunnel auf NAS 2 zugreifen kannst. Es mag auch so gehen, aber ein NAS ist von Haus aus kein Router.

 

[just2enjoy]

Die VPN Verbindung zwischen den beiden NAS steht permanent.

Der Router 1 kann leider keine VPN Verbindung aufbauen und die vom Router 2 aus zum Router 1 ist leider auch nicht besonders stabil und schnell.

 

[jugi]

In Router1 musst du eine statische Route eintragen, Ziel ist das interne Netz von Router2 und Gateway ist das NAS1.
In NAS1 musst du dann openVPN so konfigurieren, dass das NAS die Anfragen anderer Rechner weiterleitet. Google dazu mal nach site2site oder ccd (ist nix synology-spezifisches, wobei es auch hier im Forum glaub ich ein paar Anleitungen gibt [ich meine jahlives schrieb da mal was?])

Willst du auch von Netz2 in Netz1? Dann das ganze auch andersrum machen (bei suche nach site2site wird das dann eh erklärt)

 

[jahlives]

auf dem Desktop eine Route für das VPN Netz von NAS2. Ich geh mal davon aus, dass Desktop und NAS1 im selben Subnetz sind. Wobei ich es komisch finde, dass NAS2, das nicht der VPN Server ist, die 1-er IP aus dem 10-er Netz haben soll. Normalerweise ist die 1-er IP der VPN Server

 

[jahlives]

In Router1 musst du eine statische Route eintragen, Ziel ist das interne Netz von Router2 und Gateway ist das NAS1.

da bin ich nicht sicher, dass es (zuverlässig) geht. Denn wie ist der Weg der Pakete? Sie gehen an den Router1 und von da an NAS1 und durch den Tunnel an NAS2. Das geht mit der Route am Router problemlos. Kritisch werden die Antworten. Denn die landen beim NAS1 und das befindet sich im selben Subnetz die der Desktop ergo wird die Antwort direkt an den Desktop geschickt und nicht via Router1. Das ist dann asymetrisch und viele Firewalls schiiessen sowas gleich ab. Das ginge nur dann zuverlässig wenn der Router1 für diese Pakete ein SourceNAT macht und die IP des Desktops mit seiner LAN IP ersetzt

 

[jugi]

Ah ok, ich hatte nur mal kurz damit rumgespielt und hatte mit sowas wie ping keine Probleme, hab das dann aber nicht weiter verfolgt. (steht noch auf meiner "will ich irgendwann mal machen"-Liste)

 

[just2enjoy]

vielen Dank für eure Tipps. Werde es mal ausprobieren.

 

[jahlives]

Ah ok, ich hatte nur mal kurz damit rumgespielt und hatte mit sowas wie ping keine Probleme,...

das ist das fiese daran. Zustandslose Protokolle wie icmp oder udp haben damit (fast) keine Probleme. Erst bei TCP wird haarig.
Der Client schickt sein SYN Paket via Router1, da er zu diesem Zeitpunkt noch keine Route hat für das Zielnetz. Also geht es erstmal via default Gateway. Der erstellt einen Eintrag in seiner TCP Session Tabelle für die Verbindung. Damit kann der Gateway Anfragen und Antworten den einzelnen Verbindungen zuordnen. Viele Firewalls schicken dann einen icmp-redirect an den Client, mit der IP Adresse von NAS1 als Gateway für das Zielnetz von NAS2. Ab dann kommuniziert der Client direkt mit NAS1 als Gateway. Der Server im remote LAN (NAS2) schickt seinen SYN-ACK via NAS1 zurück an den Client.
Und hier beginnt das Problem: NAS1 kann den Client direkt erreichen, also geht die Verbindung nicht via Router1 zurück zum Client. Das hat zur Folge, dass für den Router1 diese TCP Verbindung nie vollständig aufgebaut wurde. Also löscht er den Session Eintrag nach einer gewissen Zeit (viele Firewalls nach 30 Sekunden). In dem Moment passiert noch nichts tragisches, da der Client durch den icmp-redirect immer noch die korrekte (direkte) Route hat. Aber die hat auch einen Timer und läuft irgendwann ab. Dann schickt der Client sein nächstes Paket wieder an den Router1. Der hat nun aber keinen Session Eintrag mehr und lässt diese Antwort nicht mehr zu. Die Verbindung reisst ab und der Client muss die Verbindung mittels SYN erneut komplett aufbauen. Jetzt kommt es auf das Anwendungsprotokoll an was dann passiert. So wird man bei http Zugriffen, die ja eigentlich zustandlos sind nicht viel merken ausser vielleicht einer längeren Ladezeit oder einzelnen Inhalten die nicht geladen werden können. Andere Anwendungen hingegen z.B. ssh blockieren komplett

 

[Matthieu]

da bin ich nicht sicher, dass es (zuverlässig) geht. Denn wie ist der Weg der Pakete?

Ich hatte da auch Sorgen, aber zumindest bei mir geht es und das jetzt schon seit Monaten ziemlich zuverlässig. Ich möchte gar keinen expliziten Rückweg. Ich möchte dass Pakete nur "rückwärts" durchs VPN gelangen wenn sie tatsächlich "beauftragt" wurden. Setup: Statische Route auf der DS von meinem Netz hin zum fremden Netz und eine statische Route in der Fritzbox (die ja auf den Clients das Standard Gateway ist) für das fremde Subnetz auf meine DS. Auf der anderen Seite ist nichts spezielles konfiguriert, nur der VPN-Server mit nahezu Standardeinstellungen.

MfG Matthieu

 

[jahlives]

Ich hatte da auch Sorgen, aber zumindest bei mir geht es und das jetzt schon seit Monaten ziemlich zuverlässig.

mit dem OVPN der DS gab/gibt es ja ein Source NAT am OVPN Interface. Weiss ned ob's mit dem DSM 6 auch noch so ist, aber das kann solche Probleme "umgehen". Durch das Ersetzen der Source IP des Client mit der OVPN-IP der DS wird das Routing wieder eindeutig(er).
Wenn man aber keine Möglichkeit für ein NAT hat (oder will) dann wird man über kurz oder lang diese Probleme bekommen. Wirklich sauber geht es imho eigentlich nur wenn der OVPN (Server und Clients) auf dem default Gateway des jeweiligen LAN läuft.

 

[just2enjoy]

Statische Route auf der DS von meinem Netz hin zum fremden Netz...

kannst du mir bitte anhand der Daten in meinem Beispiel mitteilen, wo du da was genau eingetragen hat.

 

[Matthieu]

Statische Routen in NAS1 und Router1. Wie jahlives schon sagte muss das nicht funktionieren. Ich war selbst erstaunt. Am liebsten würde ich es mal mit Wireshark untersuchen, dafür fehlt mir aber momentan die Zeit.

MfG Matthieu

 

[jahlives]

@just2enjoy
auf der DS1 eine Route für der 50-er Netz an die DS2

route add -net 192.168.50.0/24 gw 10.2.0.1

analog dazu eine Route von der DS2 zurück zu deinem LAN (auf der DS2 setzen)

route add -net 192.168.30.0/24 gw OVPN_IP_DS1

die Route auf den Routern selber weiss ich ned ob die viel bringt. Aus Sicht des Routings wäre es besser diese Route direkt auf dem Client zu setzen, damit dieser immer direkt mit der DS redet, wenn er das Remote LAN erreichen will. So kann es nicht asymetrisch werden. Falls man einen entsprechenden DHCP Server hat (haben leider die wenigsten Homerouter) dann könnte man die Route an den Client auch als dhcp Option beim Leasereqests mitschicken.

 

[bvrulez]

Wollte mich mal bedanken für diesen interessanten Austausch hier und fragen, ob der OP das Problem denn so gelöst hat und es relativ stabil läuft, trotz der Zweifel. Habe aktuell ein Problem mit OpenVPN und lese mich durch alle möglichen Threads. Man weiß ja viel zu wenig über Routing!