Und woher weiß das Server- VLAN Netz, wo das Heimnetz zu finden ist? Dafür brauchst du ebenfalls eine statische Route, oder es muss übers Default Gateway abgewickelt werden, wenn das möglich ist. Außerdem muss die VPN Konfiguration das Subnetz beinhalten (iroute Einträge).
Beiträge von frank_m
-
-
Also, wo genau stehen wir? Du hast die OpenVPN Konfigs auf beiden Seiten eingerichtet. Die Verbindung klappt vom Heimnetz auf den Server und das VLAN dahinter, aber nicht vom Server aufs Heimnetz.
Frage: Wie ist das Routing aufgesetzt? Ist NAT aktiv auf der Serverseite? Und wie routet der VPN Client ins Heimnetz?
-
Wer der Client ist, ist im Grunde ja egal. Das wird beim OpenVPN Access Server über den "Gateway-User" gesteuert. In meinem Beispiel irgendein Windows Client. Der ist austauschbar.
Solange es um die reine VPN-Verbindung geht, ja. Aber beim Routing ist die Frage natürlich entscheidend. Wenn der VPN Client nicht auf der Fritzbox ist, hast du plötzlich ein Gateway abseits des Defaut-Gateways im Netz. Das musst du in der Konfiguration natürlich berücksichtigen. Typische Symptome bei falschem oder fehlenden Routensetup können sein, dass die Verbindung in eine Richtung funktioniert, und in die andere nicht.
Das ist der Teil, um den du dich bei Zerotier auch selber kümmern musst.
Unter "VPN Gateway" ist das private Subnetz des Clients einzutragen, welches ja der anderen Site bereitgestellt werden soll. Wie gesagt: Ich bin über die Funktionsweise auch etwas verwundert.
Mit der regulären OpenVPN Konfig kann man ja relativ einfach sicherstellen, dass alles da steht, wo es hingehört.
-
Das VLAN Netz ist das geringste Problem. Da der Server ja direkt Zugriff drauf hat, ist das genau ein "push route" Eintrag an der richtigen Stelle.
- Standort A: Heimisches LAN mit Fritzbox, dahinter diverse Endpoints (derzeit kein VPN-Server). Das Subnet folgt dem Router, sagen wir 192.168.1.0/24 (das ist es nicht!).
Was ist denn da der VPN Client? Die Fritzbox?
Diese habe auf der zweiten Netzwerkkarte jeweils das gleiche Subnet, sagen wir 100.100.1.1 und 100.100.1.2.
Ganz schlechtes Beispiel, da keine private IP. Irgendjemand wird es lesen und sich dann wundern, warum nichts funktioniert.
Auf einem der VPS ist Ubuntu mit OpenVPN Access Server eingerichtet.
Warum denn kein richtiges OpenVPN?
Was ich bisher gemacht habe:
Ich hab keine Ahnung, was man in diesem Access Server wo anklicken muss. Aber einige der Einträge lesen sich für mich wie kompletter Unsinn. Warum solltest du unter "VPN Gateway" das Subnetz von der Gegenseite eintragen? Das klingt völlig daneben.
Das ganze wird ja am Ende zu den üblichen OpenVPN Konfigurationsdateien führen. Deren Inhalt brauche ich, dann kann ich dir sagen, was fehlt oder falsch ist. Du kannst sie ja anonymisieren.
- Testweise (da ich das Site to Site Routing-Szenario noch nicht so ganz verstehe) auf der Fritzbox eine statische Route mit dem OpenVPN Netzwerk und der Fritzbox als Gateway eingetragen. Das war wahrscheinlich völliger Unsinn.
In dieser Form auf jeden Fall. Ob man da was eintragen muss, kommt drauf an, was der VPN Client im Fritzbox Netz ist.
Bei Zerotier solltest du dich vorab mit der Funktionsweise vertraut machen. Dort werden Meta-Informationen über die Infrastruktur des Anbieters ausgetauscht. Ich will das nicht grundsätzlich schlecht reden, aber man sollte sich darüber klar sein, wie viel Vertrauen man der Organisation entgegen bringen will. Mir kommt das nicht ins Haus. Aber ich kriege das auch von Hand hin, was Zerotier mir abnehmen könnte.
-
Hast du das über netcup als Site-to-Site am laufen?
Hatte ich über Jahre, bis auf das VLAN Netz. Inzwischen macht Wireguard den Job. Zwei Sites verbinden sich mit gegenseitigem Zugriff, und weitere Road Warrior können mobil Zugriff erhalten und in beide Netze.
Das ist ja dann aber jeweils point to point, so ich das bisher lese?
Was meinst du mit "jeweils point-to-point"? Jeder VPN Client verbindet sich auf den Server, und der routet dann zwischen den Netzen. Wenn das gemeint ist: Ja. Wobei ein einzelner Client natürlich einer großen Zahl von Endgeräten Zugriff geben kann.
Kannst du beschreiben, wie das - im Gegensatz zu herkömmlichem VPN - funktioniert?
Das ist ein herkömmliches VPN. Mehr können Wireguard, ipsec oder die kostenpflichtige Variante von OpenVPN auch nicht.
-
Mir ist das Setup noch nicht ganz klar.
Also du hast einen Server bei netcup, der den Internetzugang zur Verfügung stellt und auch der OpenVPN Server ist, auf den sich die VPN Clients verbinden (OpenVPN Transport Netz). Einige dieser Clients (Sites) bringen ein eigenes Netz mit. Einige nicht (Road Warriors). Dazu gibt es ein Netz, dass hinter einem netcup VLAN hängt (VLAN Netz).
Im Grunde ist die Konfiguration recht einfach. Ich hab das bei mir über CCDs gelöst. Damit kann man serverseitig für jeden verbundenen Client eine spezifische Konfiguration ablegen, was sich natürlich besonders für Routing Informationen anbietet. In Kürze: ein Netz, dass ein Client über VPN erreichen können soll, wird mit
Codepush "route a.b.c.0 255.255.255.0" push "route-ipv6 x:y:z::/64"bekannt gegeben. Stellt ein Client selber ein Netz fürs VPN zur Verfügung, muss ein Eintrag
Codeiroute d.e.f.0 255.255.255.0in seiner CCD Konfig vorhanden sein.
Sollen alle Clients Zugriff aufs VLAN Netz haben? Dann kannst du die entsprechenden Routen fürs VLAN direkt in die server.conf eintragen . Ansonsten kommen die Einträge in die ccd Konfig für die Clients, die den Zugriff haben sollen.
Ebenfalls in die ccd Konfig kommt der Eintrag für die lokalen Netze der Sites. Stellt eine Site zum Beispiel das Netz 192.168.178.0/24 zur Verfügung, dann kriegt die ccd einen Eintrag "iroute 192.168.178.0 255.255.255.0".
Über die geeignete Kombination aus iroute und push route kannst du auch dafür sorgen, dass die Clients ihre Netze gegenseitig erreichen können.
-
Grundsätzlich für das weitere Vorgehen in diesem Thread: Vergiss die Weboberfläche. Die kann sonstwas anzeigen. Arbeite ausschließlich mit den ip- oder net-tools auf der Kommandozeile.
Dennoch ist die Ausgabe interessant, denn da steht, dass die 2a03:4000:20:275::1 dem Loopback Interface zugeordnet ist. Das kann natürlich nicht funktionieren. Überprüfe das anhand der Kommandozeile und korrigiere es, wenn es stimmt.
-
Ja, das hab ich erwartet. Die neighbor solicitation kommt an, aber es gibt keine Antwort darauf. Entweder fühlt sich die OpenSense nicht angesprochen, oder sie schickt die Antwort an ein anderes Interface.
Jetzt ist es Zeit, das IP-Setup der OpenSense zu analysieren, also:
- wie sind die IP-Adressen verteilt auf die Interfaces?
- Welche Routen mit welcher Metric sind eingerichtet?
- Gibt es sowas wie Policy Based Routing?
- Was passiert, wenn man auf der OpenSense Pings auf lokale oder entfernte Adressen absetzt?
-
Du lauscht auf der OpenSense auf dem falschen Interface.
Und wenn du anfängst, Adressen zu anonymisieren, dann musst du es überall machen. Wie sollen wir denn sonst die Zuordnung zu deinen Adressen ableiten?
Bei der Gelegenheit: Was passiert, wenn du auf der OpenSense ihre beiden lokalen IPv6 Adressen anpingst? Was passiert, wenn du von der OpenSense die VM IP anpingst? Wieder mit tcpdump auf allen beteiligten Geräten (auf den richtigen Interfaces).
-
Den interessanten Teil hast du weg gelassen: Was kommt von der neighbor solicitation bei der OpenSense an, und vor allem: Wie antwortet sie darauf? Ich könnte mir vorstellen, dass sie die Antwort auf dem falschen Interface raussendet.
-
mit tcpdump -i kannst du gezielt das Interface angeben, auf dem gelauscht werden soll. "-i any" lauscht auf allen Interfaces, das macht später auf der Opensense wahrscheinlich Sinn, da die Pakete auf dem Weg ins Internet durch mehrere Interfaces müssen.
Wenn du als Filter "icmp" angibst, dann ist auch klar, warum du keine IPv6 Pakete siehst. Für ICMPv6 wäre das Filter "icmp6". Anstatt "-q" würde ich eher "-n" in Betracht ziehen, das macht in deinem Fall die Zuordnung wesentlich einfacher.
-
Du hast wirklich ein Talent, dich äußerst unklar und widersprüchlich auszudrücken.
Eines aber scheint klar zu sein: tcpdump fängt von dem Interface ens4 keine IPv6-Pakete ab,
Auf welchem Rechner? VM oder Opensense? Und was heißt "fängt keine IPv6 Pakete ab"? Werden keine angezeigt? Werden keine gecaptured? Wie sieht der Aufruf aus? Und was ist das Ergebnis, auch nach Beendigung von tcpdump (Statistik)?
-
Ping auf Gateway-Adresse 2a03:4000::1 funktioniert schon nicht mehr
Und die tcpdump Ergebnisse von beiden Instanzen zu der Zeit?
Ebenso: Was meinst du mit voller Adresse?
Die Adresse, die du eingestellt hast auf dem Interface.
-
Auf der OpenSense muss IP Forwarding für IPv6 via sysctl aktiv sein. Kann sein, dass OpenSense das automatisch macht, aber prüfe das noch mal.
Und dann immer in kleinen Schritten arbeiten. Nachdem du das IP-Setup eingerichtet hast, fang auf einer VM an:
- Ping auf die lokale Adresse (XXXX:XXXX:b:XXX::10)
- Ping auf die Gateway-Adresse (XXXX:XXXX:b:XXX::1)
- Ping auf die Gateway-Adresse der OpenSense (XXXX:XXXX:a:XXX:XXXX:XXXX:XXXX:XXXX)
- Ping ins Internet.
Dabei sowohl auf der VM als auch auf der OpenSense mittels tcpdump prüfen, welche Pakete wo ankommen. Das Problem bei Ping kann ja der Hinweg oder Rückweg sein, und letzterer wird gern mal vergessen.
-
Was sind denn bei dir LAN und WAN Interface?
Von meinen VM aus dem entsprechend konfigurierten LAN geht das allerdings nicht.
Was sind denn das für VMs? Wo liegen die?
Hier erhalte ich Fehlermeldungen:
Was hast du denn da angepingt?
Ist ip_forwarding an?
Diese anonymisierten XXX Schlangen sind die Hölle. Da schreib lieber a1 und a2, da erkennt man den Unterschied schneller. Wir wissen schon, wie lang so eine IPv6 Adresse ist.
-
Code
Alles anzeigenfio Disk Speed Tests (Mixed R/W 50/50): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 168.79 MB/s (42.1k) | 1.97 GB/s (30.8k) Write | 169.23 MB/s (42.3k) | 1.98 GB/s (30.9k) Total | 338.03 MB/s (84.5k) | 3.95 GB/s (61.7k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 3.49 GB/s (6.8k) | 3.54 GB/s (3.4k) Write | 3.67 GB/s (7.1k) | 3.77 GB/s (3.6k) Total | 7.16 GB/s (14.0k) | 7.31 GB/s (7.1k)Bis gestern hatte ich auf meinem RS 2000 G9 vergleichbare Werte. Heute haben sie sich wieder halbiert, wie vor dem Wechsel auf virtio:
Code
Alles anzeigenfio Disk Speed Tests (Mixed R/W 50/50): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 119.42 MB/s (29.8k) | 1.22 GB/s (19.1k) Write | 119.74 MB/s (29.9k) | 1.23 GB/s (19.2k) Total | 239.16 MB/s (59.7k) | 2.45 GB/s (38.3k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 1.59 GB/s (3.1k) | 1.58 GB/s (1.5k) Write | 1.68 GB/s (3.2k) | 1.69 GB/s (1.6k) Total | 3.27 GB/s (6.4k) | 3.28 GB/s (3.2k)Ist das nur bei mir so?
-
Total Commander auf Windows nicht, weiß nicht, da hat sich für mich die GUI überholt. Ist aber nur mein Gusto, ich hab nen Kollegen, der schwört nach wie vor drauf.
Am Total Commander führt kein Weg vorbei. So wie es das "apt install mc net-tools" auf Ubuntu ist, so ist es die TC Installation auf Windows: Der absolut erste Schritt. - noch vor der Firewall
-
In einem Site-to-Site-Szenario benötigt man diese Lizenz.
Nein. Braucht man definitiv nicht. Ich hab jahrelang Site-to-Site Konfigurationen mit der kostenlosen Variante betrieben. Und wie gesagt, mit etlichen zusätzlichen Roadwarriern. Also im Grunde genau das, was du suchst.
-
OpenVPN ist doch komplett Open Souce. Ich hatte über Jahre einen Access Server auf einem Netcup RS mit 2 angebundenen Sites und etlichen Road Warriors. Kein Problem, und keine Kosten. Clients waren auf Windows, Linux oder mobilen Endgeräten, also bunt gemischt.
Inzwischen macht Wireguard den Job, was über die AllowedIPs ebenfalls recht einfach zu realisieren ist.
-
Wundern tut mich da eher die Anzeige von whatsmydns, der bei fast jedem Nameserver die richtige IP zeigt, außer eben bei DE.
Vermutlich hatten alle anderen keine gecachten Einträge dafür. Da musst du auf jeden Fall auf den Ablauf der eingestellten TTL warten.
