Cloud Router mit FB7590

IPv64.net - Services
, , ,
1

Hallo zusammen,

meine Ausgangssituation ist, dass ich mit Endgeräten eine VPN-Verbindung zu meiner FB7590 von außen aufbauen möchte, und hinter einem Glasfaser-Anschluss sitze. IPv6 ist klar, einen DynDNS-Eintrag für v6 habe ich auch und er funktioniert auch. Jetzt bin ich aber des Öfteren in WLAN´s unterwegs (Hotel etc.) die kein IPv6 aktiviert haben. Und schon klemmts mit dem DynDNS.

Ich habe versucht, dies mit dem VPNGateway bzw. Cloud-Router-as-a-service zu lösen. Ein Peer ist meine FB, der andere Peer mein Laptop. Von beiden Seiten kann ich die wg-Verbindung aufbauen und sehe die aktiven Verbindungen. Den Peer FB habe ich als Site-to-Site-Verbindung gekennzeichnet. Ein Ping oder ein RemoteDesktop klappt vom Laptop aber leider nicht.

Nach meinem Verständnis sind die automatisch erstellten Routen 0.0.0.0/0 und ::/0 ausreichend, da fehlt nichts. Daher denke ich, dass ich bei der Config etwas falsch gemacht habe.

Meine Heimnetz hinter der FB ist 192.168.38.0/24. Die Peer-Config für die FB ist

[Interface]
Address = 10.7.0.2/24,fd64::2/64
PrivateKey = privPKFB
DNS = 86.54.11.100

[Peer]
PublicKey = pubPK
PresharedKey = PSK
AllowedIPs = 10.7.0.0/24,fd64::/16,0.0.0.0/0,::/0
Endpoint = srv03.vpn64.de:51175
PersistentKeepalive = 30

Die Peer-Config für mein Endgerät:

[Interface]
Address = 10.7.0.3/32,fd64::3/128
PrivateKey = privPKLaptop
DNS = 192.168.159.1

[Peer]
PublicKey = pubKeyLaptop
PresharedKey = PSK
AllowedIPs = 192.168.38.0/24,2a02:6568:d9f8:9f12::/56
Endpoint = srv03.vpn64.de:51175
PersistentKeepalive = 30

Damit dachte ich, alle Aufrufe in das Heimnetz 192.168.38.0/24 vom Laptop über den VPN-Tunnel an meine FB zu lenken und damit einen RDP z.B. auf 192.168.38.20 öffnen zu können. Habe ich dabei einen Denkfehler?

Viele Grüße
Christopher

2

Hab´s gerade verstanden: Source-NAT https://www.youtube.com/watch?v=R1XFj8PJRLY

3

Du handelst offenbar nach dem Prinzip:
Warum einfach, wenn es auch kompliziert geht

Das wäre viel unkomplizierter auch ohne VPNGateway bzw. Cloud-Router-as-a-service zu lösen gewesen.

Nämlich per CDN und Portmapper. Dann wäre in den Configs der Clients lediglich der bisher verwendete Wireguard-VPN Port (z.B. UDP 51820) auf den vom CDN zugewiesenen Port (z.B. UDP 54321) zu än dern gewesen und schon hättest du auch aus IPv4-Only Netzen Zugang zum VPN deiner Fritte. bekommen.

4

Für die FritzBox soll noch ein Beitrag kommen, weil man bei der etwas anders Einrichten muss als normal

5

hmmmh, das lag eher an fehlendem Wissen über CDN etc. Für mich hat sich die Lösung mit dem Cloud-Router direkt verständlich angehört und daher ich diese gewählt.
Ich habe mir aber mittlerweile auch ein Videos inklusive DeepDive zu CDN, Portmapping etc angehört und mich daran versucht.
Ich habe ein CDN, den DNS-Record für v6 und das Portmapping auf den Wireguard-Port meiner FB angelegt. Da sollte mir kein Fehler unterlaufen sein, denn das sind ja wirklich nur wenige Klicks :clap:

Danach habe ich eine bestehende Config über die MyFritz-Adresse für meinen Laptop hergnommen und den Endpoint auf das CDN abgeändert. Schlüssel und PSK habe ich gleich gelassen und gehöfft, das die FB die Verbindung für den abgeänderten Client annimmt. Pustekuchen, der Client zeigt mir eine akive Verbindung an, die FB zeigt aber keinen aktiven Client an, und natürlich klappt auch kein Ping.

Muss ich die Verbindung auf der FB neu anlegen und wie kann ich den Endpoint anders als die bestehende MyFritz-Adresse ändern?

6

Für alle die, die sich an der Fritzbox versuchen. In Text- & Videoform.

7

Folgende Ursachen fallen mir spontan ein:

  • du testest mit dem Laptop aus dem LAN der Fritte heraus. Geht nicht wegen Rebind-Schutz der Fritte
  • du hast zwar den FQDN umgestellt von Myfritz auf ipv64, aber vergessen den Port auf den vom Portmapper zu ändern
  • du hast die falschen Ports gemappt, TCP statt UDP. Wireguard ist UDP
8

So funktioniert es. Danke das du die Anleitung so schnell rausgebracht hast. :+1:

9

:+1: bei mir auch. Ebenfalls vielen Dank für die Anleitung an Dich Dennis.

Trotzdem hat mich jetzt der Ehrgeiz gepackt, es mit dem CDN ebenfalls hinzubekommen. Ich prüfe die 3 Tips bei nächster Gelegenheit.

10

Das wäre auch der sichere Weg. Das folgende bitte nicht falsch verstehen. Ich finde das was Dennis hier mit ipv64 auf die Beine gestellt hat wirklich großartig. Aber einen guten und vor allem zwingenden Grund den Cloud Router zu benutzen kann ich einfach nicht erkennen.

Dafür kann ich aber ein gewisses Risiko in dessen Nutzen sehen.

Immerhin liegen die Key’s (und zwar sowohl der Public key wie auch der Private key und der Pre-shared Key) dabei auf einem Server auf dem ich keine root-Rechte (übersetzt für Win-User keine Adminrechte) habe.

Im Video dem ihr (@Torben_Scherzer & @chrclaus ) gefolgt seit, wurden diese Key’s auch irgendwo im Reich von Dennis erzeugt und dann auf eure Fritte übertragen. Wer dort root ist kennt auch diese Key’s. Damit will ich nun keinesfalls Dennis unterstellen damit nix gutes im Schilde zu führen. Es ist aber auch kein Geheimnis, dass die Infrastruktur von Dennis bereits Ziel von DDoS-Attacken war. Was wenn derartige Leute, die so etwas machen, mal mehr tun als nur DDoS-Attacken und in die Systeme eindringen und an die Key’s kommen. Dann haben die alles was sie brauchen um auch in die LAN’s zu gelangen, die per Cloud Router erreichbar sind.

Und eine Server-Infrastruktur, auf der es eine Vielzahl solcher Key’s zu holen gibt, ist natürlich ein wesentlich lohnenderes Ziel als eine einzelne Fritte.

11

Das ist schon richtig was du sagst. Aber hat man nicht bei allen größeren Anbietern das Problem das diese ein gutes Ziel bieten?
Ich denke das dass hier schon sinnig betrieben wird und für mich ein akzeptables Risiko.

1 „Gefällt mir“
12

würde ich dann gelten lassen, wenn es keine gute, wenn nicht bessere, Alternative gäbe, die ipv64 auch anbietet → den CDN Portmapper.

Damit bekommt man auch per IPv4 Zugang per Wireguard ins eigene LAN, wenn man CG-NAT oder DS-Lite hat, ganz ohne die Key’s aus der Hand zu geben.

13

Ich füge dieser Disskussion hinzu. Beim Peer kann man natürlich auch nur den Public Key eintragen. Ich brauche den Priv Key da nicht…

14

CDN und Portmapper laufen jetzt auch, vielen Dank für Eure Unterstützung :folded_hands:

Ich habe mir zunächst schwer getan, weil ich im CDN den Reverse-Proxy nicht aktiviert hatte und es nur mit dem Portmapper versucht hatte. Nachdem ich dann noch mal die Anleitungen detailliert befolgt hatte läuft es jetzt wie gewünscht auch aus fremden WLAN´s.

Hier muss ich noch mal den ReverseProxy nachschlagen. Mein Backend ist nicht wirklich gesetzt und mir ist nicht klar, was der ReverseProxy grundsätzlich für den Portmapper tut.

15

Garnichts. Reverse Proxy ist bei IPv64 zu verstehen als der WEB (HTTPS) Reverse Proxy.
Der Portmapper läuft auch ohne Reverse Proxy, nutzt aber denselben Software Stack.

Du kannst beides unabhängig voneinander betreiben.

16

Das stimmt natürlich! Ich füge dieser Diskussion daher hinzu, wie man das sicher auf einem Linux-Device macht:

  1. PrivateKey erzeugen:
$ umask 077
$ wg genkey > privatekey

wobei umask 077 dafür sorgt, dass nur der User der diese Key’s erzeugt, diese auch lesend/schreibend öffnen kann.
2. PublicKey aus dem erzeugten PrivateKey ableiten

$ wg pubkey < privatekey > publickey

Die so erzeugten Dateien privatekey und publickey enthalten nun die sicher neu erzeugten Key’s. Mit

$ less privatekey
$ less publickey

können diese angezeigt werden und man kann die auf dem Cloud-Router erzeugten Key’s löschen und den publickey dort ersetzen.

Ob und wie das mit den Betriebssystemen aus Redmond funktioniert ist mir nicht bekannt.