OpenVPN Site to Site (VPN Gateway), Ubuntu Access Server

  • Er soll nur von außen (auch) unter der IP der zweiten NIC erreichbar sein.

    Wir haben ja jetzt so einigermaßen ein Gefühl dafür, was du erreichen willst. Ansonsten wäre diese Aussage eine Vollkatastrophe, denn sie hat überhaupt nichts mit dem zu tun, was du momentan umsetzt. Und es wäre auch unmöglich, denn das VLAN Interface ist grundsätzlich von außen nicht erreichbar, sondern nur von anderen Servern, die am gleichen VLAN hängen.


    Wo könnte ich mit der Fehlersuche anfangen?

    Versuche herauszufinden, wo die Pakete verloren gehen. Ein mtr mit 100 Paketen ist ein erster Schritt. Dazu könnte es ein MTU oder MSS Problem sein, aber ob du da überhaupt dran kommst bei Zerotier, kann ich dir nicht sagen.

  • Der Großteil der Paket geht - wenn ich das richtig deute - am Ende, also beim unmittelbaren Kontakt zum heimischen Server verloren (ca. 85 %), vorher sind es knapp über 20 %. Nunmehr bin ich am Anfang bei 38 % Verlust, am Ende bei 53 % (Sprung auf der letzten Stufe).

    Einmal editiert, zuletzt von Antijurist () aus folgendem Grund: zweite Messung

  • Hier der Output


    pasted-from-clipboard.png

  • Ich bin einfach durch die Kommentare ins Grübeln geraten. Ich habe mich jetzt auch einmal an ZeroTier herangewagt. Dies scheint grundsätzlich gut zu funktionieren. Hierbei habe ich aber festgestellt, dass auf dem Netcup VPS Probleme vorhanden sind. Denn wenn ich von dort ins heimische LAN gelangen will, gelingt dies nur teilweise (Größtenteils, aber nicht immer, Paketverlust beim Pingen; kein Dateizugriff; jedoch Webzugriff). Gleichzeitig gelingt der Zugriff z.B. vom Smartphone mittels Mobilfunkverbindung ohne Probleme. Das lässt mich glauben, dass es mit den beiden NICs zu tun haben könnte. Beim VLAN NIC habe ich z.B. kein Standardgateway angelegt und bin nicht sicher, ob dies so richtig ist. Auch hatte ich in anderer Konstellation schon einmal Probleme mit der Metrik.


    Was ich machen möchte: Ich möchte meine Netcup-Server ins heimische LAN bringen.

    Ich denke nicht, dass Dein VPS Probleme hat, sondern eher Dein Internetzugang, imho. Was meinst Du mit "kein Dateizugriff"? Wenn Du einen Rechner/Server zu Hause erreichen willst, muss dieser im gleichen Zerotier Netzwerk sein. ZT gibt es als Client für alle OS und auch für NAS Systeme, von daher sollte das nicht allzuschwierig sein. Dann kann evtl die Firewall des Zielgeräts im LAN noch einen Riegel für Dateizugriffe vorschieben, oder Du hast Die Dateifreigabe auf dem Server nicht erlaubt. Ein wichtiger Punkt auch noch: im ZT Netzwerk funktioniert erst mal keine Namensauflösung. D.h. Du kannst das Ziel nicht mit "\\meinserver\Freigabe" ansprechen, sondern musst "\\123.123.123.123\Freigabe" verwenden (wobei 123.123.123.123 die Zerotier IP des Ziels ist). Unter Beachtung all dieser Punkte gehen Dateizugriffe natürlich definitiv über ZT, mach ich ja schließlich täglich.


    Wie schon gesagt: die VLAN NIC ist nur eine NIC zwischen Netcup Servern (einer Location). D.h. da können sich die beiden Server miteinander unterhalten, aber mehr nicht. Das ist auch kein "Router" oder sonst was.


    Wieso "musst" Du Deinen Netcup Server ins heimische LAN bringen, wenn Du mit jedem Gerät, das ZT drauf hat, auf den Server kommst, als wäre er lokal? Du kannst darüber ohne weiteres SMB / Windows Freigaben oder andere ungeschützte Kommunikation laufen lassen, da der Transport über ZT gesichert ist.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

  • Es ist mittlerweile geklärt, dass nicht der Dateizugriff das Problem ist, sondern generell die Kommunikation vom Netcup Server ins heimische LAN auf den heimischen Server. Das scheint nunmehr auch kein Problem von ZeroTier IP oder physischer IP zu sein, das hatte ich wegen der Unregelmäßigkeit der Erreichbarkeit nur ursprünglich falsch gedeutet. Die Probleme bestehen also auch beim Pingen der ZeroTier IP von Netcup ins heimische LAN.


    Wie gesagt: Ich kann vom Smartphone den Zugriff sowohl auf den Server nach Hause als auch auf den Netcup Server via ZeroTier herstellen. Es ist also kein generelles Problem des heimischen LAN oder dessen Internetverbindung. Die Erreichbarkeit nur vom Netcup Server bereitet Probleme. Beide Geräte haben ZeroTier natürlich installiert.


    Natürlich verwende ich hierfür auch keine DNS-Auflösung. Das wird dann erst angegangen, wenn die grundsätzliche Erreichbarkeit gegeben ist.


    Noch zur Erklärung, warum ich das benötige: Es gibt diverse wechselseitige Dienste, Software etc., welche auf IP-Einstellungen und/oder DNS beruhen. Daher müssen die Rechner sich auch hierunter sehen/kennen. Das fängt schon dabei an, dass der DC/DNS-Server ja unter seiner physischen IP bekannt ist. Es geht hier also um mehr als Dateifreigaben. Anderenfalls müsste ich ja alles auf die ZeroTier IPs umstellen. Da ich mich insofern nicht abhängig machen will und auch gar nicht durchdacht habe, ob das insgesamt überhaupt funktioniert, mache ich das nicht. Da ich aber die Probleme ja schon mit dem Ansprechen über die ZeroTier IP habe, ist das ja offenbar auch gar nicht das Problem.

  • Hast du dir mal deinen Traceroute genauer angesehen? Das ist ja total krank.


    Wenn deine Angaben stimmen, dann ist der erste Hop deine Server-IP, und zwar die externe (!). Der zweite Hop ist die IP deines Internetanschlusses zu Hause (!). Dann machen die Pakete eine halbe Weltreise durchs Internet Über Frankfurt, Paris und Marseille, um dann nach einem Hop in Grenoble direkt auf deinem Heimserver zu landen.


    Zwischen der IP deines Internetzugangs und deinem Heimserver eine halbe Weltreise? Und dann ohne weitere Hops aus dem Internet direkt auf deinen Heimserver? Wie ist das denn möglich?


    Wie ich oben schon mal sagte: Zerotier kann dir zwar den Tunnelaufbau vereinafachen, aber fürs Routing rechts und links der Tunnelenden bist du immer noch selber verantwortlich. Und das ist hier mal so richtig schief gegangen.

  • Ich habe den Fehler identifiziert. Es war eine Route, die noch auf dem heimischen Router angelegt war. Diese zu deaktivieren, hat das Problem gelöst. Routing innerhalb des LANs habe ich jetzt aber halt nicht, d.h. ich kann nicht die anderen Geräte im LAN von extern erreichen. Ich denke, ich spare mir dann weitere Routingversuche und akzeptiere, dass ich auf jedem Endgerät ZeroTier installieren muss.

  • Schwierig kann das eigentlich nicht sein. Aber gut, wie du möchtest.

    Ich möchte mir nicht wieder durch irgendwelche missglückten Versuche etwas zerschießen. Dann gestatte mir noch eine Frage:


    Die Situation ist jetzt folgende: Ich habe mehrere Geräte im Heimnetz, auf denen ZeroTier installiert ist. Wenn ich nun eine Managed Route in der ZeroTier Central anlege, könnte das nur funktionieren, wenn das Ziel ein Gateway/Router im Heimnetz ist?


    Da ich ZeroTier nicht auf dem Router selbst installieren kann, muss ich ein anderes Gerät im Heimnetz nutzen und dort wiederum eine Route zum Router anlegen? Denn sonst weiß ZeroTier ja nicht, wie es die IP im Heimnetz erreichen soll, weil das angesprochene Gerät im Heimnetz das nicht an ZeroTier vermitteln kann? Wenn ich dann auf dem Gateway der Managed Route eine Route des Inhalts 192.168.0.0 MASK 255.255.255.0 192.168.1.1 (Router) hinzufüge, müsste das Routing dann funktionieren? Oder verstehe ich hier wieder etwas komplett falsch?


    Aktuell ist in der Managed Route ein Gerät im Heimnetz angegeben. Dieses kann über seine eigene physische IP erreicht werden, andere Geräte im Heimnetz jedoch nicht, sondern nur über deren ZeroTier IP.


    Ich hatte auch überlegt, Managed Routes für einzelne Geräte anzulegen, aber das scheint nicht möglich zu sein?


    Bitte entschuldige, wenn die Formulierungen falsch sind. Ich hoffe, der Gedanke wird dennoch klar.

  • Wie ich mir schon gedacht habe, scheitert es an den IP Grundlagen. Ich empfehle dir dringend, dich damit zu befassen. Du bist dir darüber im Klaren, welche Infos du freiwillig diesem Zerotier Anbieter überlässt?


    Die Situation ist jetzt folgende: Ich habe mehrere Geräte im Heimnetz, auf denen ZeroTier installiert ist.

    Aus meiner Sicht macht es gar keinen Sinn, in einem Subnetz mehrere VPN Clients fürs gleiche VPN unterzubringen. Es gibt sogar VPN Technologien, da geht das gar nicht, und das ist auch gut so.


    Wenn ich nun eine Managed Route in der ZeroTier Central anlege, könnte das nur funktionieren, wenn das Ziel ein Gateway/Router im Heimnetz ist?

    Ich hab keine Ahnung, was diese "Managed Routen" tun, aber wenn es auch nur einigermaßen was mit einer IP Route zu tun hat, dann gilt: Das Gateway ist immer ein Rechner, der für das Gerät erreichbar sein muss, üblicherweise direkt im lokalen Netz.


    Da ich ZeroTier nicht auf dem Router selbst installieren kann, muss ich ein anderes Gerät im Heimnetz nutzen und dort wiederum eine Route zum Router anlegen?

    Jetzt denke mal zwei Sekunden nach. Warum solltest du für ein Gerät, dass bei dir im Heimnetz läuft und seinen Internetzugang über diesen Router bezieht, eine Route zum Router einrichten? Das hat schon eine Route zum Router, der ist nämlich sein Default Gateway.


    Das Gerät im Heimnetz, auf dem du den VPN Client installierst, ist das Gateway für alle anderen. Du musst also allen Geräten klar machen, dass sie dort das VPN-Netz zu suchen haben. Dafür gibt es zwei Möglichkeiten: Du richtest auf jedem Gerät eine Subnetzroute ein, mit dem VPN Netz als Ziel und dem VPN Client als Gateway. Oder du richtest im Router eine Subnetz Route ein, mit dem VPN Netz als Ziel und dem VPN Client als Gateway. Mit der zweiten Variante hast du das Problem für alle Geräte im Netz gelöst, denn die schicken ihre Pakete zum Router, und der weiß dann, wohin damit: Nämlich zum VPN Client, wenns fürs VPN ist.


    Denn sonst weiß ZeroTier ja nicht, wie es die IP im Heimnetz erreichen soll, weil das angesprochene Gerät im Heimnetz das nicht an ZeroTier vermitteln kann?

    Zerotier findet einen passenden VPN Client für ein oder mehrere Subnetze. Der Rest ist Sache des VPN Knotens. Da müssen die Routen für den weiteren Transfer sein. Wenn es ums Heimnetz geht, dann hat der VPN Knoten die schon von allein.


    Wenn ich dann auf dem Gateway der Managed Route eine Route des Inhalts 192.168.0.0 MASK 255.255.255.0 192.168.1.1 (Router) hinzufüge, müsste das Routing dann funktionieren?

    Das kommt drauf an, welche Subnetze du wo mit welchen Geräten verwendest. Die Route kann goldrichtig oder totaler Nonsens sein.

    Aktuell ist in der Managed Route ein Gerät im Heimnetz angegeben. Dieses kann über seine eigene physische IP erreicht werden, andere Geräte im Heimnetz jedoch nicht, sondern nur über deren ZeroTier IP.

    Ich verstehe kein Wort.

    Ich hatte auch überlegt, Managed Routes für einzelne Geräte anzulegen, aber das scheint nicht möglich zu sein?

    Das macht garantiert keinen Sinn.


    Ich hab im Anhang mal ein kleines Schaubild dargestellt, wie ich mir dein Setup vorstelle, und wo man an der Stelle Routen unterbringen muss. Ich habe vorausgesetzt, dass die VPN Konfiguration passt, also dass alle Subnetze, die übers VPN verfügbar gemacht werden sollen, in der VPN Konfiguration entsprechend eingetragen sind (192.168.100.0/24 und 192.168.178.0/24). Weitere Routen müssen nicht von Hand eingetragen werden, denn die kennen die jeweiligen Geräte schon (z.B. kennt der VPS1 eine Route ins VLAN Netz und der VPN Client ins Heimnetz).

  • Vielen Dank für deine Mühe mit dem Schaubild. Auf der Heimnetz-Seite habe ich genau das schon einmal gemacht und jetzt wieder gemacht. Es hat jedoch keine Auswirkung. Laut tracert wird der VPN-Client aus deinem Schaubild erreicht und dann geht es nicht weiter (Zeitüberschreitung). Die von dir beschriebe Funktionsweise ist mir grundlegend klar und das Routing hatte auf diese Weise auch mit anderen VPN-Lösungen bereits funktioniert. Da hatte ich aber auch einen VPN-Server im Heimnetz. Das soll jetzt ja das Gateway übernehmen, was aber aus irgendeinem Grund nicht funktioniert.


    Im Router habe ich als Routen sowohl xxx.xxx.0.0 (VPN-Netz) 255.255.255.0 192.168.1.221 (VPN-Client im Heimnetz) als auch

    xxx.xxx.0.0 (Remote-Subnetz) 255.255.255.0 192.168.1.221 eingetragen. Das ist doch, was du skizziert hast?

  • Laut tracert wird der VPN-Client aus deinem Schaubild erreicht und dann geht es nicht weiter (Zeitüberschreitung)

    Das deutet darauf hin, das die Routen für den Rückweg nicht bekannt sind. Da schon der VPN Server nicht mehr antwortet, stimmt die Konfiguration der erlaubten Subnetze im VPN schon nicht.

    Im Router habe ich als Routen sowohl xxx.xxx.0.0 (VPN-Netz) 255.255.255.0 192.168.1.221 (VPN-Client im Heimnetz) als auch

    xxx.xxx.0.0 (Remote-Subnetz) 255.255.255.0 192.168.1.221 eingetragen

    Zwei mal das gleiche Netz? Das wird nicht funktionieren. Das VPN Transportnetz muss sich grundlegend von allen anderen beteiligten Netzen unterscheiden.

  • Sorry, die Verwendung von Platzhaltern war doof. Natürlich ist es nicht das gleiche Subnet. Ich zweifele aber langsam an allem, ob evtl. die Fritzbox schuld ist. Habe mal testweise einen anderen VPN-Server (basierend auf OpenVPN) im Heimnetz aufgesetzt die Route hierzu angelegt und das Routing funktioniert hier auch nicht. Ich weiß wirklich nicht mehr, was hier schief läuft.


    Edit: Das zweite hat sich erledigt: Konfiguationsfehler auf dem VPN-Server.

  • Habe mal testweise einen anderen VPN-Server (basierend auf OpenVPN) im Heimnetz aufgesetzt die Route hierzu angelegt und das Routing funktioniert hier auch nicht. Ich weiß wirklich nicht mehr, was hier schief läuft.


    Edit: Das zweite hat sich erledigt: Konfiguationsfehler auf dem VPN-Server.

    Und das Szenario ist identisch mit deinem anderen Szenario? Also der VPN Client bringt auch ein eigenes Sub-Netz mit ins VPN?, das vom Server aus erreicht werden kann?

  • Nein, so weit bin ich noch nicht. Ich habe nur mal zum Ausschluss von Fehlern eine einseitige Konfiguration getestet. In diesem Szenario ist der VPS als normaler Client verbunden. VPN Gateway auf der netcup Seite, also Site to site, werde ich dann vielleicht testen. Jedenfalls funktioniert point to Site schon einmal und ich kann darauf aufbauen. Ich weiß noch nicht, wann ich diese Woche dazu komme. Aber da brauche ich dann ggf. wegen der anzulegen Routen auf den VPS wieder Hilfe.


    Ich glaube, dass ich den ZeroTier Versuch dann aufgebe und mich an einer cloudlosen Konfiguration versuche. Da gibt es zumindest nichts, wo ich nicht weiß, was die Software (ich nenne es jetzt einmal so) mitunter macht oder nicht macht. ZeroTier bringt mir jetzt auch nicht so viele Vorteile, da die Zahl der Clients überschaubar ist und ich nur zwei Sites sowie mobile Clients habe.


    Selbst wenn ich Site to Site nicht hinbekomme, dann sollte ich zur Not auch mit einer Dauerverbindung der netcup Server als Client leben können oder ist das technisch gesehen naiv? Sicherheitsrelevant sollte das ja auch nicht sein, da OpenVPN zertifikatbasiert ja sehr sicher sein soll und es dann egal ist, wie viele Tunnel es da gibt. Oder nicht?

  • Wie ich mir schon gedacht habe, scheitert es an den IP Grundlagen. Ich empfehle dir dringend, dich damit zu befassen. Du bist dir darüber im Klaren, welche Infos du freiwillig diesem Zerotier Anbieter überlässt?

    Da werden keine Daten überlassen, das einzige was die ZT Rootserver machen, ist beim Hole Punching zu unterstützen.


    Aus meiner Sicht macht es gar keinen Sinn, in einem Subnetz mehrere VPN Clients fürs gleiche VPN unterzubringen. Es gibt sogar VPN Technologien, da geht das gar nicht, und das ist auch gut so.

    Bei ZT funktioniert das aber genau so. Man erstellt auf dem Controller ein Netzwerk auf und hängt da alle Clients ein. Dann macht ZT eine eigene virtuelle Netzwerkkarte / interface an dem dieses Netz anliegt und fertig. Keine Routen, kein gar nichts. Einfach nur ansprechen der anderen Geräte im gleichen Netzwerk wie wenn sie in einem gleichen Subnetz im LAN wären. Imho kann man damit sehr viele Usecases abdecken, k.A. was der TE hier spezielles macht, so dass das nicht reicht.

    Normalerweise reicht es, auf allen Geräten ZT zu installieren und fertig. ZT arbeitet auf OSI Layer 1 und 2, alles darüber kann man agnostisch und ohne Anpassung einfach verwenden.


    Ich hab keine Ahnung, was diese "Managed Routen" tun, aber wenn es auch nur einigermaßen was mit einer IP Route zu tun hat, dann gilt: Das Gateway ist immer ein Rechner, der für das Gerät erreichbar sein muss, üblicherweise direkt im lokalen Netz.

    Managed Routen sind ein ZT Ding, man kann über den Controller Routen auf die Clients pushen, wenn diese den Haken gesetzt haben und dies erlauben. Sehr praktisch, wenn man größere Netze mit Routen versorgen will.


    Wenn Du Dich noch nicht mit ZT beschäftigt hast, ist es schwierig, Funktionsweise und Wording einzuschätzen. Auch sich darüber ein (negatives) Urteil zu erlauben ist evtl etwas vorschnell.


    Auf https://zerotier.atlassian.net…ier+and+Physical+Networks hat ZT übrigens das Routing zwischen ZT und physischen Netzen selbst beschrieben.


    Antijurist Das planlose Herumspringen zwischen verschiedenen Lösungen, ohne eine mal bis zum Ende durchzugehen, ist nicht zielführend. Definitiv scheint es auch an grundlegenden Kenntnissen hinsichtlich IP / Routing / VPNs etc. zu fehlen. Da wäre es erst einmal hilfreich, sich diese Kenntnisse zu verschaffen. Sonst dokterst Du an Deinem Setup herum, ohne überhaupt zu verstehen, was Du eigentlich machst.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    2 Mal editiert, zuletzt von TBT ()

  • Ich denke, die Verwirrung ist dadurch entstanden, dass ich und Frank_M bezüglich ZeroTier wohl auch aneinander vorbei kommuniziert haben, also fehlendes Wissen zu der Lösung bei ihm, lückenhafte Netzwerkkenntnisse bei mir. Ich habe mir das mit ZeroTier unkomplizierter vorgestellt. Eventuell liegen die Probleme auch in Windows System (Firewall, Routing) an der Endstelle. Jedenfalls klappt das nicht so unkompliziert bei mir, obwohl - nach dem, was du oben schreibst - meine Routen korrekt sein dürften. Aber wie gesagt: Vielleicht sind auch nicht die Routen selbst, sondern deren Umsetzung ein Problem. Hier konnten wir dann offenbar bislang schwer zum Ziel kommen.


    Ich verstehe, dass ein Hin- und Herwechseln grundsätzlich nicht sinnvoll ist. Allerdings ist nach meinem Eindruck die Funktionsweise von ZeroTier für einen Anfänger schwieriger verständlich. Mir reicht eigentlich auch ein oberflächliches Verständnis (was muss ich machen, um was zu erreichen). Denn ich habe abseits des VPN diverse andere Themen, mit denen ich mich beschäftigen will. Und das ist zumindest in Grundlagen bei einem simplen Server-Client-Setup on premise gegeben. Vieles lernt man aber auch erst, wenn man auf Probleme stößt.


    Von daher bin ich auch sehr dankbar über die vielen wertvollen Kommentare, aus denen ich auf jeden Fall schon einiges mitnehmen konnte.

  • Da werden keine Daten überlassen, das einzige was die ZT Rootserver machen, ist beim Hole Punching zu unterstützen.

    Auch das erfordert Meta- und Vermittlungsdaten. Also gerade der interessante Teil. ZT bietet ein SDN, und wer einem SDN beitritt, entscheidet ZT, und niemand sonst. Ich will das gar nicht schlecht reden, aber man sollte sich darüber klar sein. Es ist gut denkbar, dass das im jeweiligen Anwendungsfall völlig unkritisch ist.


    Imho kann man damit sehr viele Usecases abdecken, k.A. was der TE hier spezielles macht, so dass das nicht reicht.

    Der TE will Subnetze an den Endpunkten mit einbinden. Sicher kein Hexenwerk, erfordert aber auch bei ZT ein geeignetes Routensetup. Sei es über "Managed Routes" oder von Hand.


    Managed Routen sind ein ZT Ding, man kann über den Controller Routen auf die Clients pushen, wenn diese den Haken gesetzt haben und dies erlauben. Sehr praktisch, wenn man größere Netze mit Routen versorgen will.

    Ja, also genau das, was Wireguard über "Allowed IPs" und OpenVPN über iroute macht.


    Mal ne blöde Frage: IP Forwarding ist ja eingeschaltet auf allen relevanten VPN Knoten? Darüber haben wir nie explizit gesprochen, da es ja eigentlich selbstverständlich, dass ein Router IP Forwarding braucht. Aber man muss es eben sowohl in Windows als auch in Linux explizit aktivieren.