Wireguard Client und Server simultan auf VPS. Netzwerke verbinden
Hallo zusammen,
da ich neu bin kurz zu mir. Ich bin Bj. 64 und nicht mehr ganz neu, was die Netzwerktechnik betrifft. Mein Metier ist eigentlich die SPS-Programmierung und die Antriebstechnik. Da kann ich in den einschlägigen Foren helfen. Mit Netzwerktechnik habe ich dadurch auch nur begrenzt zu tun und für alles Mögliche in dem Thema hat die Industrie wunderbare Tools, die das Leben erleichtern.
Ich bin also nur rudimentär mit Linux und dem damit verbundenen Networking unterwegs. Ich hätte mein Problem auch von unserem Dienstleister lösen lassen können. Da es sich aber um eine private Sache handelt packt mich hier allerdings der Ehrgeiz und ich möchte, trotz meines Alters, noch was lernen. Außerdem ist das Problem immer noch brandaktuell und das Netz ist voll von mehr oder weniger sinnvollen Lösungsansätzen. Bitte verzeiht mir, wenn ich diverse Fachbegriffe u.U. durcheinander bringe.
Folgendes Problem versuche ich zu lösen. Ich habe seit etwa 3 Monaten einen Glasfaseranschluss hinter einem CGNAT (DG). Bisher hatte ich auf meinem kleinen Linux-Fileserver (DietPi auf einem Odroid XU4 mit redundanten Platten) OpenVPN laufen. Das ist seit CGNAT leider so nicht mehr möglich. Die neue Fritze 7590AX von DG unterstützt Wireguard, was auch super funktioniert. Jedenfalls solange man eine IPv6 Verbindung aufbauen kann. Das ist mit dem Handy als Hotspot auch kein Problem und geht wie schnuff. Blöd wird es, wenn nur eine IPv4 Verbindung zur Verfügung steht. Das ist der Fall, wenn ich von meiner Hobbywerkstatt aus auf meine CNC-Daten zugreifen will. Mein Remotezugriff besteht im Moment also nur unidirektional durch einen USB-Stick. Das ist leider beliebig blöd. Ich habe mir dann bei IONOS einen VPS angelacht, der IPv4 und IPv6 unterstützt.
Auf dem VPS läuft also ein Wireguard Server für die IPv4 Werkstatt- und Externverbindung und ein Wireguard Client für die IPv6 Fritzbox-Anbindung. Der WG-Server läuft auf dem Interface 10.0.0.0/24 der Fritz- Client auf dem Interface 192.168.20.0/24.
Auf beides kann ich zugreifen und über SSH eine Terminalsitzung auf dem VPS initiieren. Ping geht logischerweise auch.
Hier mal der "wg show" vom VPS:
Die "WGFritzClient.conf" sieht fogendermaßen aus:
Hier noch die "WGServerVPS.conf"
Um die Sache noch zu vervollständigen hier die Routingtabelle vom VPS.
Also ich sehe hier keinen Routingeintrag zwischen den Netzen. Allerdings und das ist auch logisch, findet zwischen den Netzen ohne Routing kein Datenaustausch statt. Soweit ich das aus dem Nebel meines Gedächtnisses hervor hole braucht es doch ein Gateway und Routingeinträge???? Hier stehe ich vor einem großen schwarzen Loch und hoffe auf Eure Hilfe.
Gruß Thomas
da ich neu bin kurz zu mir. Ich bin Bj. 64 und nicht mehr ganz neu, was die Netzwerktechnik betrifft. Mein Metier ist eigentlich die SPS-Programmierung und die Antriebstechnik. Da kann ich in den einschlägigen Foren helfen. Mit Netzwerktechnik habe ich dadurch auch nur begrenzt zu tun und für alles Mögliche in dem Thema hat die Industrie wunderbare Tools, die das Leben erleichtern.
Ich bin also nur rudimentär mit Linux und dem damit verbundenen Networking unterwegs. Ich hätte mein Problem auch von unserem Dienstleister lösen lassen können. Da es sich aber um eine private Sache handelt packt mich hier allerdings der Ehrgeiz und ich möchte, trotz meines Alters, noch was lernen. Außerdem ist das Problem immer noch brandaktuell und das Netz ist voll von mehr oder weniger sinnvollen Lösungsansätzen. Bitte verzeiht mir, wenn ich diverse Fachbegriffe u.U. durcheinander bringe.
Folgendes Problem versuche ich zu lösen. Ich habe seit etwa 3 Monaten einen Glasfaseranschluss hinter einem CGNAT (DG). Bisher hatte ich auf meinem kleinen Linux-Fileserver (DietPi auf einem Odroid XU4 mit redundanten Platten) OpenVPN laufen. Das ist seit CGNAT leider so nicht mehr möglich. Die neue Fritze 7590AX von DG unterstützt Wireguard, was auch super funktioniert. Jedenfalls solange man eine IPv6 Verbindung aufbauen kann. Das ist mit dem Handy als Hotspot auch kein Problem und geht wie schnuff. Blöd wird es, wenn nur eine IPv4 Verbindung zur Verfügung steht. Das ist der Fall, wenn ich von meiner Hobbywerkstatt aus auf meine CNC-Daten zugreifen will. Mein Remotezugriff besteht im Moment also nur unidirektional durch einen USB-Stick. Das ist leider beliebig blöd. Ich habe mir dann bei IONOS einen VPS angelacht, der IPv4 und IPv6 unterstützt.
Auf dem VPS läuft also ein Wireguard Server für die IPv4 Werkstatt- und Externverbindung und ein Wireguard Client für die IPv6 Fritzbox-Anbindung. Der WG-Server läuft auf dem Interface 10.0.0.0/24 der Fritz- Client auf dem Interface 192.168.20.0/24.
Auf beides kann ich zugreifen und über SSH eine Terminalsitzung auf dem VPS initiieren. Ping geht logischerweise auch.
Hier mal der "wg show" vom VPS:
root@ubuntu:~# wg show
interface: WGFritzClient
public key: LVI=
private key: (hidden)
listening port: 49262
peer: KxY=
preshared key: (hidden)
endpoint: [IPv6]:51569
allowed ips: 192.168.20.0/24
latest handshake: 1 minute, 31 seconds ago
transfer: 8.26 KiB received, 22.65 KiB sent
persistent keepalive: every 25 seconds
interface: WGServerVPS
public key: Thk=
private key: (hidden)
listening port: 51820
peer: CkU=
preshared key: (hidden)
allowed ips: 10.0.0.2/32
persistent keepalive: every 25 seconds
peer: Dmk=
preshared key: (hidden)
allowed ips: 10.0.0.3/32
persistent keepalive: every 25 seconds
peer: UUw=
preshared key: (hidden)
allowed ips: 10.0.0.4/32
persistent keepalive: every 25 seconds
peer: GWc=
preshared key: (hidden)
allowed ips: 10.0.0.5/32
persistent keepalive: every 25 seconds
peer: d3Y=
preshared key: (hidden)
allowed ips: 10.0.0.6/32
persistent keepalive: every 25 seconds
peer: lUg=
preshared key: (hidden)
allowed ips: 10.0.0.7/32
persistent keepalive: every 25 seconds
Die "WGFritzClient.conf" sieht fogendermaßen aus:
[Interface]
PrivateKey = c10=
Address = 192.168.20.205/24
DNS = 192.168.20.1
DNS = fritz.box
[Peer]
PublicKey = QxY=
PresharedKey = 1c4=
AllowedIPs = 192.168.20.0/24
Endpoint = haruetzelgruempf.myfritz.net:51569
PersistentKeepalive = 25
Hier noch die "WGServerVPS.conf"
[Interface]
Address = 10.0.0.1/24
PrivateKey = +HA=
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
[Peer]
#Peer = Werkstatt
PublicKey = Dmk=
PresharedKey = NXY=
AllowedIPs = 10.0.0.3/32
PersistentKeepalive = 25
[Peer]
#Peer Firma
PublicKey = GWc=
PresharedKey = NXY=
AllowedIPs = 10.0.0.5/32
PersistentKeepalive = 25
[Peer]
#Peer Laptop
PublicKey = d3Y=
PresharedKey = NXY=
AllowedIPs = 10.0.0.6/32
PersistentKeepalive = 25
Um die Sache noch zu vervollständigen hier die Routingtabelle vom VPS.
root@ubuntu:/etc/wireguard# ip r
default via 5.6.7.8 dev ens6 proto dhcp src 1.2.3.4 metric 100
10.0.0.0/24 dev WGServerVPS proto kernel scope link src 10.0.0.1
5.6.7.8 dev ens6 proto dhcp scope link src 1.2.3.4 metric 100
prohibit 169.254.169.254
192.168.20.0/24 dev WGFritzClient proto kernel scope link src 192.168.20.205
212.227.123.16 via 5.6.7.8 dev ens6 proto dhcp src 1.2.3.4 metric 100
212.227.123.17 via 5.6.7.8 dev ens6 proto dhcp src 1.2.3.4 metric 100
Also ich sehe hier keinen Routingeintrag zwischen den Netzen. Allerdings und das ist auch logisch, findet zwischen den Netzen ohne Routing kein Datenaustausch statt. Soweit ich das aus dem Nebel meines Gedächtnisses hervor hole braucht es doch ein Gateway und Routingeinträge???? Hier stehe ich vor einem großen schwarzen Loch und hoffe auf Eure Hilfe.
Gruß Thomas
Please also mark the comments that contributed to the solution of the article
Content-ID: 669055
Url: https://administrator.de/contentid/669055
Printed on: November 13, 2024 at 12:11 o'clock
36 Comments
Latest comment
Moin.
Du musst dir jeweilig gegenüber liegenden Netze auch in die AllowedIPs eintragen.
D.h. die Fritze muss in ihrer Clientconfig in den AllowedIPs stehen haben
Und die Clients die im 10.0.0.0/24 angekoppelt sind müssen in Ihrem Client-Configs ihrerseits auch das Netz der Fritzbox stehen haben.
Denn die AllowedIPs bestimmen was überhaupt über die jeweiligen Tunnelendpunkte akzeptiert wird, wenn darin nämlich Netze nicht aufgeführt sind von denen man Traffic erwartet wird der ohne Meldung einfach gedroppt. Eine Route auf dem Server ist auch nicht nötig denn der kennt ja bereits alle Netze und kennt die Wege dorthin.
Des weiteren sind die KeepAlive Einträge auf der Serverseite für die DialIn Clients ebenfalls Unsinn, die gehören ausschließlich in die Config der Client-Seite.
Btw. Ich hätte ja die Fritze sich am vServer als Client einwählen lassen und nicht umgekehrt, ...
Mehr Infos dazu auch hier
Merkzettel: VPN Installation mit Wireguard
Gruß catrell
Du musst dir jeweilig gegenüber liegenden Netze auch in die AllowedIPs eintragen.
D.h. die Fritze muss in ihrer Clientconfig in den AllowedIPs stehen haben
AllowedIPs = 10.0.0.0/24
Und die Clients die im 10.0.0.0/24 angekoppelt sind müssen in Ihrem Client-Configs ihrerseits auch das Netz der Fritzbox stehen haben.
AllowedIPs = 192.168.20.0/24,10.0.0.1/32
Denn die AllowedIPs bestimmen was überhaupt über die jeweiligen Tunnelendpunkte akzeptiert wird, wenn darin nämlich Netze nicht aufgeführt sind von denen man Traffic erwartet wird der ohne Meldung einfach gedroppt. Eine Route auf dem Server ist auch nicht nötig denn der kennt ja bereits alle Netze und kennt die Wege dorthin.
Des weiteren sind die KeepAlive Einträge auf der Serverseite für die DialIn Clients ebenfalls Unsinn, die gehören ausschließlich in die Config der Client-Seite.
Btw. Ich hätte ja die Fritze sich am vServer als Client einwählen lassen und nicht umgekehrt, ...
Mehr Infos dazu auch hier
Merkzettel: VPN Installation mit Wireguard
Gruß catrell
ip -4 route add 10.0.0.0/24 dev WGFritzClient
Du hast das offensichtlich missverstanden. Das 10.0.0.0/24 käme nicht auf den Server sondern muss auf die Fritze für den Peer. Klar das dann nicht klappt wenn du das am Server einträgst, denn dann gäbe es das Netz ja doppelt 😉, und das lehnt er natürlich ab.Also wie ich schon gesagt habe, setze es gleich besser so um das die Fritze als Client den vServer anspricht, das gibt weniger Ärger mit der Fritze.
Vorausgesetzt es ist überhaupt möglich mit meiner Konfiguration so ein VPN aufzusetzen. Außerdem ist die AVM-Lösung wohl leider und bekanntermaßen, nicht ganz kompatibel mit WG-Standard.
Ja natürlich geht das, läuft bei einem Kollegen absolut problemlos und ist im o.g Link auch geschildert wenn du ihn noch mal eingehend liest. Einfach die Fritze als Peer im bestehenden WG Server auf dem vServer hinzufügen, und den jetzigen Client am Server komplett weglöschen und auf der Fritze einen Client zum vServer einrichten schon klappt das auch wunderbar.Hier nochmal zum nachlesen
vServer Config mit zus. Fritzbox Peer
[Interface]
Address = 10.0.0.1/24
PrivateKey = +HA=
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
[Peer]
#Peer = Werkstatt
PublicKey = Dmk=
PresharedKey = NXY=
AllowedIPs = 10.0.0.3/32
[Peer]
#Peer Firma
PublicKey = GWc=
PresharedKey = NXY=
AllowedIPs = 10.0.0.5/32
[Peer]
#Peer Laptop
PublicKey = d3Y=
PresharedKey = NXY=
AllowedIPs = 10.0.0.6/32
[Peer]
# Peer Fritzbox
PublicKey = XXXXXXX
AllowedIPs = 192.168.20.0/24,10.0.0.7/32
Fritzbox zus. als Client mit folgender Config einrichten. (Aber bitte auf der Fritzbox selbst, nicht am Server!!)
[Interface]
PrivateKey = <PRIVKEY-Fritzbox>
Address = 192.168.20.1/24
[Peer]
PublicKey = <PUBKEY-vServer>
Endpoint = vserver.domain.tld:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
Die angestrebte Lösung hat aber den Charme, dass ich bei Verlust des VPS immer noch an mein Netz komme.
Das kommst du auch noch, wenn die Fritze den Client spielt, die macht auch beides parallel!Also sich als Client in den vServer einwählen als auch separate Clients für die Einwahl einbinden, das ist ja gerade einer der Vorteile von Wireguard, da sind das alles nur "peers"
Das hiesige Wireguard Tutorial erklärt alles haarklein inkl. bunten Bildern was du im Setup genau konfigurieren und beachten musst:
Merkzettel: VPN Installation mit Wireguard
Lesen und verstehen...! 😉
Bei Kombinationen mit der nicht Standard konformen Fritzbox Wireguard Implementation ist besonders das Kapitel zur Anbindung einer FB genau zu lesen.
Die o.a. "WGServerVPS.conf" hat wieder einmal den üblichen (Anfänger) Fehler von unsinnigem NAT (Masquerading bzw. Adress Translation) im eigenen Tunnel. Damit schafft man eine routingtechnische Einbahnstrasse.
Das o.a. Tutorial weisst extra in rot auf diesen Unsinn hin! Das solltest du also zuallererst entfernen, zumal auch eine Fritzbox damit nicht umgehen kann!!
Die interne WG IP Adressierung mit einer Allerwelts 10er IP ist auch nicht gerade sehr intelligent und weitsichtig und wird dir früher oder später auf die Füße fallen. (Siehe dazu auch hier)
Tutorial lesen hilft.
Merkzettel: VPN Installation mit Wireguard
Lesen und verstehen...! 😉
Bei Kombinationen mit der nicht Standard konformen Fritzbox Wireguard Implementation ist besonders das Kapitel zur Anbindung einer FB genau zu lesen.
Die o.a. "WGServerVPS.conf" hat wieder einmal den üblichen (Anfänger) Fehler von unsinnigem NAT (Masquerading bzw. Adress Translation) im eigenen Tunnel. Damit schafft man eine routingtechnische Einbahnstrasse.
Das o.a. Tutorial weisst extra in rot auf diesen Unsinn hin! Das solltest du also zuallererst entfernen, zumal auch eine Fritzbox damit nicht umgehen kann!!
Die interne WG IP Adressierung mit einer Allerwelts 10er IP ist auch nicht gerade sehr intelligent und weitsichtig und wird dir früher oder später auf die Füße fallen. (Siehe dazu auch hier)
Tutorial lesen hilft.
Ich dachte nur, dass das Forwarding nicht zum NAT gehört.
Nicht denken sondern nachdenken! IP Forwarding sprich Routing und Network Adress Translation bzw. Masquerading sind 2 völlig verschiedene Paar Schuhe die nichts miteinander zu tun haben. Fisch und Fahrrad... Vielleicht helfen ein paar Routing Grundlagen etwas Licht ins Dunkel von 20 Jahren zu bringen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Eine Prise NAT dazu kann dann sicher auch nicht schaden.
https://de.wikipedia.org/wiki/Netzwerkadressübersetzung
Ich tue mich im Tutorial manchmal mit der Terminologie noch etwas schwer. Lesen hilft, aber den Transfer muss man auch hinbekommen.
Einfach hier fragen, denn 20 Jahre an einem Abend versuchen abzuhaken ist schon tough.und dumme Fragen stellen kann ich immer noch.
Wie wir alle wissen gibts die ja gar nicht. Nur dumme Antworten!! 😉Wenn ich das richtig verstanden habe ist ein Routingeintrag insgesamt in der VPS-Konfig unnötig.
Beim Hochfahren des Wireguard-Interfaces und Verwendung von wg-quick erstellt das System automatisch die Route in das jeweilige Netz anhand der AllowedIPs des Peers, somit kennt der VPS auch den Weg in das Netz.Ein
ip route show
Ein NAT mit masquerading und Furz und Feuerstein hat zwar nicht unbedingt Auswirkungen auf den Tunnel selbst, verursacht aber einen haufen Offset in der Übertragung, der erst einmal wieder raussortiert werden muss. Bringt also nichts außer Performanceproblemen.
SRC-NAT macht man nur wenn es nicht anders geht, wenn man Routen kann sollte dies immer Prämisse sein.Kleiner Nachtrag zum Thema NAT. Kann es sein, das das eingeschaltete NAT auf den VPS zu Problemen auf dem Firmenrouter geführt hat? Wenn ich mich in der alten Serverkonfig von der Firma aus dort angemeldet habe schmierten alle internen Verbindungen ab. D.h. ich konnte nur noch den VPS anpingen.
Ganz einfach, da hat jemand ein Gateway Redirect in die WG Config eingetragen denn ein 0.0.0.0/0 in den AllowedIPs führt dazu das sämtlicher Traffic über den Tunnel geschickt wird. Wenn also nur Traffic in das Subnetz des VPS soll, dann sollte in den AllowedIPs auch nur dieses Netz bzw andere Netze darin stehen die dort angebunden sind.Denn anhand der AllowedIPs erstellen die meisten Wireguard-Systeme automatisch die Einträge für die Routing-Tabelle (Ausnahmen bilden bspw. Mikrotik oder pfSense bei denen man die Routen von Hand anlegen muss).
Das oft eingesetzte wg-quick unter Linux erstellt die Routen automatisch anhand der AllowedIPs der Peers. Das manuelle Anlegen von Routen ist hier also nur nötig wenn man ein System nutzt das diese Routen nicht von selbst anlegt, z.B. wenn man alternativ systemd-networkd für die Konfiguration von Wireguard-Tunneln benutzt.
Zitat von @AlterMann:
So wie ich es sehe sind alle relevanten routen eingetragen. Ist das richtig?
So wie ich es sehe sind alle relevanten routen eingetragen. Ist das richtig?
root@ubuntu:~# ip r
default via 85.X.X.1 dev ens6 proto dhcp src 85.X.X.X metric 100
85.X.X.1 dev ens6 proto dhcp scope link src 85.X.X.X metric 100
100.64.114.0/24 dev WGServerVPS proto kernel scope link src 100.64.114.1
prohibit 169.254.169.254
192.168.20.0/24 dev WGServerVPS scope link
212.227.123.16 via 85.X.X.1 dev ens6 proto dhcp src 85.X.X.X metric 100
212.227.123.17 via 85.X.X.1 dev ens6 proto dhcp src 85.X.X.X metric 100
Korrekt.
Zitat von @AlterMann:
Ich würde mich freuen, wenn noch mal jemand was zu der Peerconfig der Fritze und der Firmenanbindung sagen könnte.
Ist doch in Ordnung so.Ich würde mich freuen, wenn noch mal jemand was zu der Peerconfig der Fritze und der Firmenanbindung sagen könnte.
Bei den Clients kannst du dir den sinnfreien und überflüssigen Preshared Key sparen! Das erspart dir sinnlosen Overhead und weitere überflüssige Fehlerquellen. Ein zusätzlicher Preshared Key ist sinnfrei wenn man schon mit Crypto Keys arbeitet. Siehe Tutorial!
Auch die Fritzbox sofern sie als VPN Initiator (Client) konfiguriert ist benötigt keinen überflüssigen Preshared Key!
Und einen bösen Kardinalsfehler hast du wieder und wieder gemacht obwohl du oben schon im Thread und auch im Tutorial mehrfach in ROT darauf hingewiesen wurdest! 😡
Die internen IP Adressen der Clients in der "AllowedIPs" Definition haben immer eine /32er Hostmaske!! Wenn nicht scheitert das korrekte Krypto Key Routing unter Wireguard!!
HIER nochmals der wichtige Hinweis zu der Thematik im Tutorial. Sollte man wirklich auch lesen wenn man schon drauf hingewiesen wird.
Das solltest du also dringenst auch korrigieren wenn du die überflüssigen PSKs löschst!
Auch die Fritzbox sofern sie als VPN Initiator (Client) konfiguriert ist benötigt keinen überflüssigen Preshared Key!
Und einen bösen Kardinalsfehler hast du wieder und wieder gemacht obwohl du oben schon im Thread und auch im Tutorial mehrfach in ROT darauf hingewiesen wurdest! 😡
Die internen IP Adressen der Clients in der "AllowedIPs" Definition haben immer eine /32er Hostmaske!! Wenn nicht scheitert das korrekte Krypto Key Routing unter Wireguard!!
HIER nochmals der wichtige Hinweis zu der Thematik im Tutorial. Sollte man wirklich auch lesen wenn man schon drauf hingewiesen wird.
Das solltest du also dringenst auch korrigieren wenn du die überflüssigen PSKs löschst!
Die internen IP Adressen der Clients in der "AllowedIPs" Definition haben immer eine /32er Hostmaske!! Wenn nicht scheitert das korrekte Krypto Key Routing unter Wireguard!!
Wenn er aber auch die einzelnen Wireguard Clients von der Fritte aus erreichen will dann braucht er die 24er Maske in der Client-Config der Fritze sonst erreicht er ja nur den VPS.In der Serverconfig stehen die Clients ja schon korrekt mit ihrer /32 Maske.
Die PSKs stören die Funktionalität nicht. Die machen die Verbdindung nur Post-Quantencrypto sicher falls jetzt jemand den Traffic für die Zukunft aufzeichnet, echter Overhead ist das für die Verbindung nicht da wird nur ein initialer Wert für die Verschlüsselung nur nicht auf 0 gesetzt.
dann braucht er die 24er Maske
Für die Fritte als Initiator stimmt das natürlich. Es ging um die Konfig des "Firmenrechners". Dort ist die interne AllowedIPs Maske falsch.so wie ich es oben verstanden habe kann die Fritzbox beides Client und Server?!?
Das ist richtig verstanden.Wenn die Fritte als VPN Responder (Server) arbeitet geht das nicht. Da du im Gegensatz zu "richtigem" Wireguard keinerlei Einfluss auf die automatische WG Konfig Generierung der Fritte als Server hast musst du zu mindestens beim Fritten Peer mit einem PSK leben. Aber auch nur da!
Jetzt müssen wir neben dem ganzen Standard Gemüse noch noch das wirkliche Problem finden!
Wie geht das mit dem VPS?
Auch dafür gibt es hier im Forum ein entsprechendes Tutorial was die ganze obige Prozedur noch einmal genau und mit bunten Bildern beschreibt:VPS Jumphost mit Fritzbox für VPN Zugang bei DS-Lite/CGNAT Anschlüssen
IPsec hat den großen Vorteil das nicht nur ältere Fritzboxen supportet werden sondern man sich damit auch die unnötige Frickelei mit einer externen und damit überflüssigen VPN Client Software erspart und die bei allen Endgeräten verfügbaren onboard VPN Clients nutzt die in der Regel performanter und besser ins jeweilige Betriebssystem integriert sind! 😉
Aus mehreren Fachartikeln weiß ich...
Wie immer im Leben ist das eine rein relative Aussage die immer vom Standpunkt abhängt. Für einen einfachen Admin sind das dort alles simple Allerweltsbegriffe und so ein einfaches VPN Setup in 20 Minuten erledigt. Ein Fachfremder braucht natürlich etwas länger...alles relativ eben! Per aspera ad astra würde der Römer sagen. Zum Schluß: Das mit dem Faden klingt wirklich gruselig. Wenn du in der Beziehung konsequent wärest wäre deine Limousine ein Zerknalltreibling und dein Browser ein Stöberer. Von Laien, Hobby und trivial äähh... Anfänger, Freizeitbeschäftigung (Steckenpferd kennt ja keiner mehr) und einfach jetzt mal nicht zu reden.
Zitat von @AlterMann:
Entweder das oder alternativ nur die einzelnen IPs die du im Zugriff brauchst.- Der WGTunnel arbeitet mit dem Netz 100.64.114.0/24 und die Fritzbox mit 192.168.20.0/24.
- Damit ich auf jeden Rechner bzw. Peer, welcher den Tunnel nutzt zugreifen kann ist in der Client-Konfig bei "AllowedIPs" das gesamte Tunnelnetz anzugeben. Also 100.64.114.0.
* Um jetzt auf das Heimnetz, sagen wir von der Werkstatt aus zuzugreifen, benötige ich in der Clientconfig der Werkstatt unter "AllowedIPs" dessen Netzwerkadresse. Also 192.168.20.0/24.
Jepp.* Damit der WGServer jetzt weiß wohin er das Paket schicken soll, muss in der Server-Konfig unter dem Peer für die Fritzbox ebenfalls dieses Netz eingetragen sein. Sieht so aus.
Jepp, anhand der Einträge erstellt der WG Server die statische Route in der Routing-Tabelle auf den Peer.Aber ebenfalls wichtig zu erwähnen ist folgendes: Die AllowedIPs sind auch dafür da, für das CryptoKey-Routing den erlaubten Traffic zu definieren. Wenn Traffic von einer IP von diesem Peer eintrifft welche nicht in den AllowedIPs vermerkt ist wird dieser verworfen und nicht geforwarded! Das ist wichtig zu wissen wenn man mehrere Site2Site Tunnel implementiert auf die man gegenseitig Zugriff haben will.
* Solange auf dem VPS, also dem WGServer, das ipforwarding aktiviert ist kümmert sich wg-quick um die richtigen Routingeinträge.
Ja, wg-quick erstellt die Routing-Einträge der peers für dich automatisch.Zitat von @AlterMann:
Da sind wir schon beim Thema und bei meinen Überlegungen. Wenn ich also eine weitere Fritze bzw. ein weiteres Netzwerk an den Tunnel anbinden will müsste ich dann folgendes machen? (Site2Site) Mal angenommen dieses Netz hätte die Adresse 192.168.30.0/24.
Da sind wir schon beim Thema und bei meinen Überlegungen. Wenn ich also eine weitere Fritze bzw. ein weiteres Netzwerk an den Tunnel anbinden will müsste ich dann folgendes machen? (Site2Site) Mal angenommen dieses Netz hätte die Adresse 192.168.30.0/24.
- Dann müsste die Server Konfig für den neuen Peer wohl so aussehen, bzw um den Eintrag ergänzt werden?
[Peer]
#Peer Weit weg Box
PublicKey = IUg=
PresharedKey = KxY=
AllowedIPs = 100.64.114.7/32,192.168.20.0/24,192.168.30.0/24
Nein, bei der Policy-Betrachtung ist dies nur eingehend zu betrachten denn von diesem Peer kommt ja nur Traffic von den Absender-IPs
100.64.114.7/32 und 192.168.30.0/24
Die Ziel-IP spielt dabei keine Rolle. Die spielt erst eine Rolle für das Routing des Servers an den anderen Peer.
Auch bei den Clients gilt dann wenn eine Absender-IP der ankommenden Pakete nicht in den AllowedIPs steht wird das Paket verworfen. Ergo müssen auf die Clients sämtliche Subnetze die der Client erreichen will und von denen er Traffic erwartet.
* Die Konfig für die Fritzbox im "Weit weg Netz müsste wohl so aussehen?
[Interface]
PrivateKey = LGA=
Address = 192.168.30.1/24
[Peer]
PublicKey = Thk=
PresharedKey = NXY=
AllowedIPs = 100.64.114.0/24
Endpoint = <VPS.ip>:51820
PersistentKeepalive = 25
Nein dort müsste das hier stehen wenn du auch das Netz der Fritzbox daheim erreichen willst:
AllowedIPs = 100.64.114.0/24,192.168.20.0/24
* Der bestehende Eintrag in der Server Konfig für das Heimnetz müsste dann entsprechend um das "Weit weg Netz? erweitert werden?
Nein, der bleibt wie er ist, auch hier gilt die Absender-IP der Clients hinter dem Peer. Nur an der Fritzbox daheim müsste noch das 192.168.30.0/24 Netz in den AllowedIPs der ClientConfig ergänzt werden denn die braucht einerseits die Route ins fremde Netz und muss Pakete mit diesen Absender-IPs akzeptieren.[Peer]
#Peer FritzBox
PublicKey = lUg=
PresharedKey = NXY=
AllowedIPs = 100.64.114.6/32,192.168.20.0/24,192.168.30.0/24
Bleibt eine Frage? Was ist mit den DNS Einträgen, die in den Client Dateien im Moment auf die Fritze im Heimnetz verweisen. Das klappt auch richtig gut. Ein Eintrag wie "DNS = 192.168.20.1, 192.168.30.1, fritz.box" dürfte wohl völliger Oppdeldock sein? Dazu fällt mir leider nichts ein.
Bleibt die Frage nach dem DNS.
Sofern die Clients keine lokalen DNS Adressen auflösen müssen brauchst du keinerlei DNS Einträge. Ohne ein DNS Setting nehmen die Clients immer die DNS Server die sie lokal dynamisch lernen (DHCP etc.). In der Regel also lokale Router die als DNS Server agieren.Einzig nur wenn du lokale Hostnamen auflösen musst, dann musst du logischerweise einen lokalen DNS Server angeben um das zu erreichen für lokale Domains wie fritz.box, .internal oder home.arpa. Öffentliche Requests reicht dieser dann weiter. Oder man löst das eben statisch über die lmhosts Datei. Aber auch dann braucht man natürlich keinen lokalen DNS Server weil der Client das dann lokal macht.
Hast du also keine lokalen Hostnamen kannst du auf DNS Komandos komplett verzichten. Ist in dem Falle auch besser weil der DNS Request sich nicht unnütz durch den Tunnel quälen muss.
Gibt es eine Erklärung dafür?
Ohne die konkrete beidseitige Infrastruktur mit Auslastung usw. und auch der beiden Providerseiten und insbesondere deren Internet Peering zu kennen ist das reine Kristallkugelei. Dazu sind die möglichen Szenarien zu vielfältig.Z.B. bei einem Kabel TV Anschluss wo mehrere 1000 User die letzte Meile sharen machen morgens ggf. ein paar irgendwelche Backups. QoS Policies der Provider die bestimmten VPN Traffic ratelimiten zu bestimmten Zeiten usw. usw. Zuviele Optionen mit viel zuvielen Unbekannten die eine belastbare Aussage ergeben könnten. Besonders an einfachen Consumer Anschlüssen. Vergessen und freuen das es klappt was in Zeiten von Billo Providern mit DS-Lite ja nicht immer gegeben ist!