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

  • Darauf zielte meine Anspielung an. Ich hatte bisher nie Windows Rechner routen lassen. Das war also mindestens Teil des Problems. Auf dem Zielrechner im Heimnetz, der routen soll, habe ich es über die Registry aktiviert, bin aber auch nicht sicher, ob ausreichend. Eventuell muss zusätzlich Routing und RAS installiert werden.Gibt dazu auch diverse Problembeschreibungen. Bei ZeroTier gab es zudem ein Firewall Problem, das ich erst erkennen musste (!). Auf netcup Seite bislang noch nicht. Das würde ich dann angehen, wenn ich mich daran mache.

  • So, es ist nun so weit.

    Ich habe folgendes gemacht: VPN-Gateway auf Netcup VPS (Ubuntu) installiert. Dieses ist mit dem VPN-Server im Heimnetz verbunden.

    Auf Ubuntu habe ich schon einmal IP-Forwarding aktiviert.

    Beide Netcup VPS haben auf der zweiten NIC das gleiche Subnetz, sagen wir 193.168.1.0. Der Ubuntu-Server hat 193.168.1.1, der andere 193.168.1.2.

    Der VPN-Server im Heimnetz hat die IP 192.168.1.56.

    Auf der heimischen Fritzbox ist eine Route 193.168.1.0, 255.255.255.0, 193.168.1.56 angelegt.


    Ich kann 193.168.1.1 auch erreichen. Allerdings erreiche ich 193.168.1.2 noch nicht. Tracert bleibt offenbar am VPN-Gateway hängen. Demnach muss ich jetzt wohl noch eine Route setzen. Mache ich das auf der NIC 1 und wie hat diese dann auszusehen - 193.168.1.0, 255.255.255.0, Gateway: [IP von NIC 1] / leer?

  • 193.168.1.1? Du verwendest hier öffentliche IP-Adressen!

    Private IP-Adressbereiche sind

    • 10.0.0.0/8 (10.0.0.0 bis 10.255.255.255)
    • 172.16.0.0/12 (172.16.0.0 bis 172.31.255.255)
    • 192.168.0.0/16 (192.168.0.0 bis 192.168.255.255)

    Du solltest dringend auf IP-Adressen aus diesen Bereichen wechseln, da du sonst Teile des öffentlichen Internets nicht mehr erreichen kannst.

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Like 5
  • 193.168.1.1? Du verwendest hier öffentliche IP-Adressen!

    Private IP-Adressbereiche sind

    • 10.0.0.0/8 (10.0.0.0 bis 10.255.255.255)
    • 172.16.0.0/12 (172.16.0.0 bis 172.31.255.255)
    • 192.168.0.0/16 (192.168.0.0 bis 192.168.255.255)

    Du solltest dringend auf IP-Adressen aus diesen Bereichen wechseln, da du sonst Teile des öffentlichen Internets nicht mehr erreichen kannst.

    Die Betonung lag auf "sagen wir mal". Es handelt sich nicht um die echten Adressbereiche. Ich habe für das Beispiel andere verwendet. Aber natürlich hast du Recht damit, dass das für das Beispiel eine unglückliche Range ist.

  • Wenn es eh um private Addressbereiche geht, macht es nicht sehr viel Sinn, diese durch andere Bereiche zu substituieren (unterschrieben) und dabei noch die o.g. Dinge hervorzurufen.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Like 1
  • Die Betonung lag auf "sagen wir mal". Es handelt sich nicht um die echten Adressbereiche. Ich habe für das Beispiel andere verwendet. Aber natürlich hast du Recht damit, dass das für das Beispiel eine unglückliche Range ist.

    Ah, dann habe ich nichts gesagt.


    Ist zwar ein WireGuard-Tutorial, aber schau dir mal die Commands hier bei "PostUp" an: https://github.com/netcup-comm…n-of-the-wireguard-server


    Hier eine kurze und ungenaue Erklärung, was die Commands tun:


    iptables -A FORWARD -i wg0 -j ACCEPT: Pakete, die auf dem VPN-Interface eintrudeln, dürfen weitergeleitet werden.

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE: Pakete, die auf dem Internet-Interface rausgehen, sollen "genattet" werden.


    Ich kann mir sehr gut vorstellen, dass es da bei dir hängt. Denn nur das IP-Forwarding zu aktivieren reicht nicht.

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Wenn es eh um private Addressbereiche geht, macht es nicht sehr viel Sinn, diese durch andere Bereiche zu substituieren (unterschrieben) und dabei noch die o.g. Dinge hervorzurufen.

    Ist ja schon in Ordnung. Es spielt aber für die Fragestellung doch keine Rolle, da es ums Prinzip geht.

  • Ich habe mich wahrscheinlich wieder einmal unklar ausgedrückt oder ich missverstehe etwas. :) Also ich habe eine Site-to-Site-Tunnel mit der Lösung Veeam PN aufgesetzt. Hier erfolgt die Konfiguration grundsätzlich über eine Weboberfläche. Wireguard ist das genutzte Protokoll hierfür. Das VPN-Gateway ist auf einem VPS, welcher zwei Netzwerkkarten hat (eine virtuelle, VLAN).


    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.


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


    Entschuldige die Frage, aber normalerweise muss ich doch eine Route setzen, damit ich aus dem VPN-Subnetz ins physische Subnetz komme? Bisher habe ich eben nur mit einer Seite (reiner Access-Server) gearbeitet. Ich habe hier einfach ein Brett vor dem Kopf...


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


    Ich würde ja in einem Ubuntu-Forum fragen, aber da laufe ich wieder Gefahr, dass die Konstellation VLAN nicht verstanden wird und man deswegen aneinander vorbei redet.

  • 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?

  • Vielleicht um auch das noch einmal klarzustellen: Ich erreiche jedenfalls vom VPN-Gateway-Host das Heimnetz, umgekehrt erreicht ich vom Heimnetzt bereits das VPN-Gateway. In einem ersten Schritt möchte ich gerne vom Heimnetz auch den zweiten VPS im Netcup VLAN erreichen. Die Problembeschreibung, ich könne vom einen Netz das andere erreichen, aber nicht umgekehrt, ist daher nicht aktuell, es sei denn, es ist der Zugriff auf die weiteren Clients gemeint. Es hakt an der Schnittstelle VPN-Gateway/Ubuntu-Host zum zweiten VPS.


    Ändert sich hierdurch etwas?

    Wäre der erste Schritt immer noch das oben von Virinum Vorgeschlagene?


    Ist das unter dem folgenden Link im zweiten Schritt Beschriebene das, was gemeint ist?


    Link


    Oder hier im letzten Schritt: Link

    (ich will natürlich keinen DHCP Server, falls jemand auf die Idee kommt, es ist nur der letzte Schritt gemeint)



    Ich will nur sichergehen, dass keine Informationen fehlen.

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

  • Ich kann vom gesamten Heimnetz ohne VPN Client auf das Gateway auf der anderen Seite zugreifen. Die Heimnetz-Seite macht insoweit also, was sie soll.


    Ich versuche dann einfach mal mein Glück mit dem Setzen von Routen auf beiden NICs am Gateway-VPS.


    Auf dem Gateway selbst gibt es nichts zu konfigurieren bzw. ist nicht vorgesehen. Dem Server im Heimnetz sage ich nur, wie das Subnetz der anderen Seite aussieht. Für Routen auf der anderen Seite muss ich aber selbst sorgen. Das steht ja auch in der Anleitung. Das ist aber natürlich dort nicht näher für die Situation VLAN sowie Ubuntu erläutert.