Posts by frank_m

    Um die Sache hier zu einem möglichst friedlichen Ende zu bringen: Es hat alles wie vorgesehen funktioniert. Ich hab zwar nach wie vor keine Ahnung, warum das CCP die manuell erstellten Einträge nicht akzeptieren wollte. Aber die bei der automatischen Signierung durch bind9 erstellten Einträge ließen sich auf Anhieb eintragen und nun sind auch alle gängigen DNS Validierer glücklich, inkl. der Überprüfung mit "dig".

    Das DNSSEC bezieht sich auf deine Top-Level-Domain und die Subdomains bzw. alles was darunterliegt, erbt diese Einstellungen.

    Aber nur solange für diese Sub Domain kein eigener Nameserver angegeben wird. Wenn es einen Nameserver gibt, dann muss der auch wieder dnssec lernen.


    Möglicherweise hab ich das Problem nun gelöst. Ich habe noch mal neu angefangen und habe das offizielle Howto der bind Seite befolgt:

    https://bind9.readthedocs.io/en/v9_18_2/dnssec-guide.html


    Da purzelte am Ende ein DS Eintrag heraus, der direkt vom Netcup CCP akzeptiert wurde. Jetzt warte ich darauf, dass der Eintrag exportiert wird, und dann werde ich mal einige der üblich verdächtigen DNS Validierer drauf loslassen.

    Hallo,


    Vorgeschichte:

    Ich betreibe einen eigenen kleinen DNS Server für meine dyndns Hosts. Dafür gibt es eine Subdomain für eine bei netcup registrierte .com domain:

    dyn.example.com


    Die einzelnen Hosts heißen demnach

    hostX.dyn.example.com


    Dafür läuft ein bind9 in einem lxd Container auf einem RS bei netcup, für den eine kleine API exportiert wird, damit die Clients ihre Adressen aktualisieren können. Im CCP bei netcup gibt es einen entsprechenden Nameserver Eintrag:

    dyn NS ddns.example.com (vereinfacht)

    ddns ist der Hostname des DNS Servers (bzw. des entsprechenden lxd Containers). Das funktioniert soweit super und war in den letzten Monaten sehr stabil.


    Vorhaben:

    Das ganze soll nun dnssec lernen. Entsprechend hab ich mir dieses Know-How angesehen:

    https://doku.lrz.de/display/PUBLIC/DNSSEC+mit+BIND+9.9


    Die Vorgehensweise funktioniert augenscheinlich, bis auf ein Problem: Ich kriege den DS Eintrag für den Parent NS nicht ins Netcup CCP. Die dsset Datei wird wie beschrieben erzeugt, da drin ist aber nur ein Eintrag (nur der für RSASHA2):

    dyn.example.com. IN DS 34939 8 2 BEB40DC948274BD637720B77694564B6C785283F1F89C3FF901466A3 B1BB5D25


    Wenn ich nun aber einen DNS Eintrag im Netcup CCP vornehmen möchte, mit Host "dyn", Type "DS" und der Destination "34939 8 2 BEB40DC948274BD637720B77694564B6C785283F1F89C3FF901466A3 B1BB5D25", dann kriege ich einen Fehler:


    Destination des DS-Records falsch


    Was lauft da schief? Fehlt ein Eintrag für RSASHA1? Wird der Algorithmus für .com nicht unterstützt? Oder die Länge von 2048 Bit?

    Hier auf einem RS 2000 G9 und einem RS Ostern M 22 ebenfalls kein Problem.

    umgekehrt erreicht ich vom Heimnetzt bereits das VPN-Gateway.

    Vom gesamten Heimnetz? Oder nur vom VPN Client?



    In einem ersten Schritt möchte ich gerne vom Heimnetz auch den zweiten VPS im Netcup VLAN erreichen

    Siehe mein Bild oben, dafür braucht es eine Route im Heimnetz, eine im VLAN VPS und eine entsprechende VPN Konfiguration.


    Der erste deiner Links funktioniert nicht. NAT kann evtl. die Route im VLAN VPS sparen, aber alles andere muss trotzdem passen.

    Muss ich hier jetzt überhaupt keine Routen setzen, damit mein VPS dem VPN-Gateway sagt, wie es die IP des anderen VPS findet? So verstehe ich deine Erklärung.

    Vorsicht, das kann man so nicht sagen. Einige Routen auf Seiten des VPN Clients braucht man trotzdem noch. Durch die NAT Regeln tauchen die IPs deines VPN Netzes bzw. aus dem Netz des VPN Clients nicht im VLAN des VPS auf. Der antwortet nur auf IP-Anfragen, die er kennt. Für den Zugriff aus dem Netz des VPN Clients auf die Ressourcen im VLAN ist das super. Aber der Rückweg funktioniert dann nicht, damit ist es praktisch keine Site-to-Site Verbindung mehr. Man kann von den VLAN Rechnern nicht auf die Geräte im Netz des VPN Clients zugreifen, weil NAT das verhindert. Dafür müsstest du vollwertig routen, und dann brauchst du wieder Routen auf beiden Seiten, wie oben bereits beschrieben.

    Oben hatte ich ja bereits das Vorhandensein von NAT als mögliche Problemursache beshrieben. Das würde nämlich zuverlässig erklären, warum du von einem Netz aufs andere zugreifen kannst, aber nicht vom anderen aufs eine.


    Ob das Fehlen von PostUp das Problem ist müsste ich doch mittels kurzzeitigen Ausschaltens der Firewall prüfen können?

    Nein, NAT macht mehr. Der ändert Adress- und Portinformationen in den Paketen. Nur durch Ausschalten der Firewall erreichst du kein vergleichbares Verhalten.


    Bevor ich weitermache, würde ich das gerne grundsätzlich verstehen.

    Ja, das würde ich auch empfehlen. Fang oben mit dem Bild an. Was ist daran unklar? Oder was davon entspricht nicht deiner Zielvorstellung?

    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.

    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?

    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.

    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).

    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.

    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.

    Beim VLAN NIC habe ich z.B. kein Standardgateway angelegt und bin nicht sicher, ob dies so richtig ist.

    Das hat erst mal gar nichts mit VPN zu tun. Hier musst du dich nur fragen: Soll der Server sämtlichen Internetdatenverkehr über das VLAN abwickeln? Wenn ja, dann gehört da eine Defaultroute hin, sonst nicht.


    Aber wenn dein VPN schon erreichbar ist, dann wird eine Defaultroute daran nichts ändern oder verbessern. Gegen Paketverluste helfen keine Routen.

    Ich kann aus dem Heimnetz beide Rechner am Ziel anpingen, also insbesondere auch den VPS, auf dem nicht der VPN Server läuft. Wie gesagt: In diese Richtung gibt es keine Probleme. In die andere kann ich aber nicht pingen, wenn der Tunnel aktiv ist.

    Dann würde ich Geld drauf wetten, dass NAT aktiv ist.



    Mein Problem mit Ubuntu ist schon, dass ich es nicht hinbekomme, dass das richtige Keyboard-Layout verwendet wird. Das ist bei jedem Schritt mit dem Terminal frustrierend.

    Ich hoffe inständig, du nutzt das System nicht über die Console im SCP? Und am Ende wahrscheinlich noch mit einer grafischen Oberfläche auf dem Server und xterm?


    Das wird ein weiter Weg. So viel steht fest.


    Mal ne blöde Frage: Wie sicherst du den Server ab gegen Fremdzugriffe und Attacken? Wie ich hier woanders schon mal dargelegt habe, hab ich einen unerwünschten Zugriff pro Sekunde auf meinen Server IPs - also zigtausende pro Tag. Und der OpenVPN Access Server öffnet ja ein Webinterface ...

    Allerdings fehlt mir das Verständnis zum Thema VLAN.

    Das VLAN ist im netcup Kontext ja nur eine zusätzliche "Netzwerkkarte", die im Linux genau so auftaucht, wie alle anderen auch, also die "physikalische" Karte ins Internet und das VPN Interface.


    Also ich soll dann den VPN-Server als Default Gateway bzw. in meinem Fall wohl eher Routen einstellen.

    Den VPN Server als Default-Gateway zu benutzen, ist eine Möglichkeit. Eine andere ist, eine passende Subnetzroute im VLAN Rechner einzurichten.


    Dann sprechen wir nur vom Host des VPN Servers (bereits von dort habe ich ja keine Verbindung ins Heimnetz) - dort trage ich dann was genau ein?

    Wenn alles richtig konfiguriert ist, dann kümmert sich OpenVPN um das Anlegen der Routen. Wenn das nicht passiert, dann hast du die Subnetz-Informationen des VPN Clients noch nicht richtig eingetragen. Wie gesagt - ein iroute Eintrag an der richtigen Stelle. Oder es ist NAT im Spiel.

    Willst du nicht mal ernsthaft in Erwägung ziehen, auf die Community Variante von OpenVPN zu wechseln? Da weiß man wenigstens, was passiert.


    Der VPN-Server hat ja die gleiche IP wie der Host.

    Über das Transport-Netz von OpenVPN hat er auf seinem Host-Interface, seinem VLAN-Interface und seinem VPN Interface durchaus unterschiedliche IPs. Auf dem VPN Server muss das in den Routen berücksichtigt werden (was OpenVPN automatisch macht - eigentlich). Auf den Rechnern im VLAN ist es aber so, dass man die VLAN-IP des Servers als Routing Ziel angeben muss.


    Bisher habe ich mit VPN ja immer nur in eine Richtung gearbeitet und nicht wieder zurück. Da ist dann klar, dass die Route am Default-Gateway zum VPN Server gesetzt werden muss.

    Beides hat eigentlich gar nichts miteinander zu tun. Und VPN Datenverkehr ist immer bidirektional. Der zweite Satz gilt so eigentlich nur, wenn für die Geräte im Netz das Defaultgateway über VPN geleitet werden soll.


    Wenn ich aber eine Verbindung vom Client zum Server aufbaue, verstehe ich nicht wirklich, welche Routen ich setzen muss, damit mein Default Gateway am Ziel weiß, wie es ins entfernte Netz zurück kommt.

    Muss es denn das Default Gateway sein? Im netcup Netz ist das Defaultgateway für deine Server ja irgendein Rechner in der Infrastruktur, auf den du gar keinen Zugriff hast. Du solltest eher dafür sorgen, dass deine Server über alle Routen verfügen, die sie brauchen.


    Wie baut das Zielsystem überhaupt den Tunnel in die andere Richtung auf, wenn ich von dort aus ja gar nichts mache - sagt dann der VPN Server: Bitte baue auch eine Verbindung in die Gegenrichtung auf?

    Nein. Dafür reicht ein Tunnel.


    Folgende Frage: Kannst du aus deinem Heimnetz den Rechner im VLAN bei Netcup anpingen? Oder kannst du nur den VPN Server anpingen?

    - Wenn ersteres geht, dann ist vermutlich NAT im Spiel, denn sonst müsste auch der Rückweg funktionieren

    - Wenn nur zweiteres geht, dann ist die Frage, welche IP des Servers du erreichen kannst. Die vom VPN Transportnetz? Oder auch die des VLAN Interfaces?