36
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 secondsDie "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 = 25Hier 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 = 25Um 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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669055
Url: https://administrator.de/contentid/669055
Ausgedruckt am: 21.11.2024 um 09:11 Uhr
36 Kommentare
Neuester Kommentar
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/24Und 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/32Denn 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
Gude catrell,
danke für die schnelle Antwort. Ich habe die Configs beider Interfaces mal nach Deinem Vorschlag angepasst. Die Fritze hat das ohne Meckern gemacht und eine Route angelegt. WG-Quick meldet folgendes:
Soweit so gut. Beim Server sieht das anders aus:
Hier gibt es Mecker beim Anlegen der Route. Da beißt sich die Katze auch in den Schwanz.
Je nachdem welches WG Interface als erstes gestartet wird entsteht der Fehler beim Start des zweiten Interfaces. Starte ich also den WGServerVPS als erstes entsteht der Fehler dann beim Starten des WGFritzClient.
Ja, da gebe ich Dir Recht. Vielleicht bleibt am Ende nichts anderes übrig. Die angestrebte Lösung hat aber den Charme, dass ich bei Verlust des VPS immer noch an mein Netz komme. 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.
Gruß Thomas
danke für die schnelle Antwort. Ich habe die Configs beider Interfaces mal nach Deinem Vorschlag angepasst. Die Fritze hat das ohne Meckern gemacht und eine Route angelegt. WG-Quick meldet folgendes:
root@ubuntu:/etc/wireguard# wg-quick up WGFritzClient
ip link add WGFritzClient type wireguard
wg setconf WGFritzClient /dev/fd/63
ip -4 address add 192.168.20.205/24 dev WGFritzClient
ip link set mtu 1420 up dev WGFritzClient
resolvconf -a WGFritzClient -m 0 -x
ip -4 route add 10.0.0.0/24 dev WGFritzClientSoweit so gut. Beim Server sieht das anders aus:
root@ubuntu:/etc/wireguard# wg-quick up WGServerVPS
ip link add WGServerVPS type wireguard
wg setconf WGServerVPS /dev/fd/63
ip -4 address add 10.0.0.1/24 dev WGServerVPS
ip link set mtu 1420 up dev WGServerVPS
ip -4 route add 192.168.20.0/24 dev WGServerVPS
RTNETLINK answers: File exists
ip link delete dev WGServerVPSHier gibt es Mecker beim Anlegen der Route. Da beißt sich die Katze auch in den Schwanz.
Je nachdem welches WG Interface als erstes gestartet wird entsteht der Fehler beim Start des zweiten Interfaces. Starte ich also den WGServerVPS als erstes entsteht der Fehler dann beim Starten des WGFritzClient.
Btw. Ich hätte ja die Fritze sich am vServer als Client einwählen lassen und nicht umgekehrt, ...
Ja, da gebe ich Dir Recht. Vielleicht bleibt am Ende nichts anderes übrig. Die angestrebte Lösung hat aber den Charme, dass ich bei Verlust des VPS immer noch an mein Netz komme. 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.
Gruß Thomas
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/32Fritzbox 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 = 25Die 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 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"
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"
Danke Dir für den Hinweis. Ich sehe, genau da habe ich eine gewaltige Verständnislücke und das ändert natürlich einiges. Ich komme erst im Laufe der Woche dazu das auszuprobieren.
Die Konfig habe ich verstanden und der Link, um das ganze auf die Reihe zu bekommen, ist auch äußerst hilfreich. Ich folge erst einmal Deinem Rat und studiere den Thread noch mal ausführlich. Ein Berichte folgt sobald ich neue Erkenntnisse habe. Insgesamt denke ich wohl zu kompliziert. "Keep it simple stupid" scheint zielführend zu sein.😊
Anfänglich hatte ich mit der Lösung schon experimentiert, aber immer eine Fehlermeldung von der Fritze beim Erstellen
des Tunnels erhalten. Wahrscheinlich Mist gebaut bei der Konfig. Wenn ich mir die IP's in Deinem Beispiel anschaue glaube ich auch zu wissen warum.
Gruß Thomas
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.
Hallo aqui,
vielen Dank für die klaren Worte. Ich bin dankbar für jeden kompetenten Hinweis. Ich bin jetzt seit zwei Monaten mit dem Thema unterwegs und versuche 20Jahre Netzwerktechnik nachzuholen. Erst das im Link genannte Tutorial brachte mich erst einmal ansatzweise in die Nähe des Verständnisses. (Der Tab ist seit etwa vier Wochen offen und fast jeden Abend besucht.)
Die "iptables" entferne ich Samt und Sonders aus der Konfig. Ich dachte nur, dass das Forwarding nicht zum NAT gehört. Ich gestehe, der Mechanismus dahinter liegt für mich noch im Nebel.
Auch vielen Dank für den Link auf die richtige Wahl der IP Netze. Es ist schwer etwas im Netz zu finden, wenn man die Frage nicht kennt. Der Input war sehr gut und ich werde das auch gleich umsetzen. Die Argumente sind unschlagbar.
Ich tue mich im Tutorial manchmal mit der Terminologie noch etwas schwer. Lesen hilft, aber den Transfer muss man auch hinbekommen. Aber das wird schon und dumme Fragen stellen kann ich immer noch.
Gruß Thomas
vielen Dank für die klaren Worte. Ich bin dankbar für jeden kompetenten Hinweis. Ich bin jetzt seit zwei Monaten mit dem Thema unterwegs und versuche 20Jahre Netzwerktechnik nachzuholen. Erst das im Link genannte Tutorial brachte mich erst einmal ansatzweise in die Nähe des Verständnisses. (Der Tab ist seit etwa vier Wochen offen und fast jeden Abend besucht.)
Die "iptables" entferne ich Samt und Sonders aus der Konfig. Ich dachte nur, dass das Forwarding nicht zum NAT gehört. Ich gestehe, der Mechanismus dahinter liegt für mich noch im Nebel.
Auch vielen Dank für den Link auf die richtige Wahl der IP Netze. Es ist schwer etwas im Netz zu finden, wenn man die Frage nicht kennt. Der Input war sehr gut und ich werde das auch gleich umsetzen. Die Argumente sind unschlagbar.
Ich tue mich im Tutorial manchmal mit der Terminologie noch etwas schwer. Lesen hilft, aber den Transfer muss man auch hinbekommen. Aber das wird schon und dumme Fragen stellen kann ich immer noch.
Gruß Thomas
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!! 😉
1
Guten Morgen zusammen,
ich hatte gestern noch Zeit mich mit dem von aqui empfohlenen "Lesestoff" auseinander zu setzen. Aufgrund der gesammelten Erkenntnisse aus allen vorangegangenen Beiträgen habe ich die "WGServerVPS.conf" und auch den Client "WGFritzCLient.conf", der in die Fritze importiert werden soll, angepasst. Die neue Serverkonfig ist bereits Online und ich kann mich mit meinem Bürorechner darauf verbinden und auch eine Terminalsitzung starten.
Hier erst einmal die Serverconfig "WGServerVPS.conf".
Und natürlich das Pendant für die Fritzbox "WGFritzClient.conf". Das ist noch nicht implementiert, da mögen die "Meister" erst einmal, hoffentlich wohlwollend, drauf schauen. 😊
und der Vollständigkeit halber auch noch die Konfig vom Firmenrechner, der erwiesenermaßen läuft.
Jetzt habe ich noch ein paar kleine Fragen zum Thema NAT und Routing.
Wenn ich das richtig verstanden habe ist ein Routingeintrag insgesamt in der VPS-Konfig unnötig. Der VPS verfügt ja über zwei Netzwerkkarten. Die eine ist die von IONOS bereitgestellte NIC in dem Fall heißt das Ding "ens6" und natürlich meine WGServerVPS NIC. Damit verfüge ich über zwei "Netzwerkkarten", wenn auch nur virtuell und es genügt in der sysctl.conf das IP-Forwarding für IPv4 und gerne auch IPv6 zu aktivieren. Ansonsten sind die beiden Schnittstellen, weil auf einem einzigen Rechner, diesem auch bekannt. Wozu also mehr eintragen als das Forwarding (Das Beispiel mit dem reisenden Paket ist richtig gut)
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.
Ich hoffe, dass ich nicht zu sehr falsch liege.
Gruß Thomas
ich hatte gestern noch Zeit mich mit dem von aqui empfohlenen "Lesestoff" auseinander zu setzen. Aufgrund der gesammelten Erkenntnisse aus allen vorangegangenen Beiträgen habe ich die "WGServerVPS.conf" und auch den Client "WGFritzCLient.conf", der in die Fritze importiert werden soll, angepasst. Die neue Serverkonfig ist bereits Online und ich kann mich mit meinem Bürorechner darauf verbinden und auch eine Terminalsitzung starten.
Hier erst einmal die Serverconfig "WGServerVPS.conf".
[Interface]
Address = 100.64.114.1/24
PrivateKey = +HA=
ListenPort = 51820
[Peer]
#Peer = Werkstatt
PublicKey = Dmk=
PresharedKey = NXY=
AllowedIPs = 100.64.114.2/32
[Peer]
#Peer = MyHandy
PublicKey = UUw=
PresharedKey = NXY=
AllowedIPs = 100.64.114.3/32
[Peer]
#Peer Firma
PublicKey = GWc=
PresharedKey = NXY=
AllowedIPs = 100.64.114.4/32
[Peer]
#Peer MyLaptop
PublicKey = d3Y=
PresharedKey = NXY=
AllowedIPs = 100.64.114.5/32
[Peer]
#Peer FritzBox
PublicKey = lUg=
PresharedKey = NXY=
AllowedIPs = 100.64.114.6/32,192.168.20.0/24Und natürlich das Pendant für die Fritzbox "WGFritzClient.conf". Das ist noch nicht implementiert, da mögen die "Meister" erst einmal, hoffentlich wohlwollend, drauf schauen. 😊
[Interface]
PrivateKey = c10=
Address = 192.168.20.1/24
[Peer]
PublicKey = Thk=
PresharedKey = NXY=
AllowedIPs = 100.64.114.0/24
Endpoint = VPS.Server.IP:51820
PersistentKeepalive = 25und der Vollständigkeit halber auch noch die Konfig vom Firmenrechner, der erwiesenermaßen läuft.
[Interface]
PrivateKey = QHU=
Address = 100.64.114.4/24
[Peer]
PublicKey = Thk=
PresharedKey = NXY=
AllowedIPs = 100.64.114.0/24, 192.168.20.0/24
Endpoint = vps.server.ip:51820
PersistentKeepalive = 25Jetzt habe ich noch ein paar kleine Fragen zum Thema NAT und Routing.
Wenn ich das richtig verstanden habe ist ein Routingeintrag insgesamt in der VPS-Konfig unnötig. Der VPS verfügt ja über zwei Netzwerkkarten. Die eine ist die von IONOS bereitgestellte NIC in dem Fall heißt das Ding "ens6" und natürlich meine WGServerVPS NIC. Damit verfüge ich über zwei "Netzwerkkarten", wenn auch nur virtuell und es genügt in der sysctl.conf das IP-Forwarding für IPv4 und gerne auch IPv6 zu aktivieren. Ansonsten sind die beiden Schnittstellen, weil auf einem einzigen Rechner, diesem auch bekannt. Wozu also mehr eintragen als das Forwarding (Das Beispiel mit dem reisenden Paket ist richtig gut)
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.
Ich hoffe, dass ich nicht zu sehr falsch liege.
Gruß Thomas
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. Mit der neuen Konfig kann ich alles wieder anpingen, Firmenintern und VPS. Sogar das interne Routing auf das Maschinennetz läuft problemlos.
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 showEin 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.
So wie ich es sehe sind alle relevanten routen eingetragen. Ist das richtig?
Hoppla, stimmt. Das war ich. Ist aber jetzt rausgeflogen. Danke
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 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.
Hoppla, stimmt. Das war ich. Ist aber jetzt rausgeflogen. Danke
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.
1
Sonst noch Fragen? Wenn nicht dann bitte den Beitrag auch schließen.
Ich würde mich freuen, wenn noch mal jemand was zu der Peerconfig der Fritze und der Firmenanbindung sagen könnte. (Beiträge oben) Vermeidet bei der Fritze u.U. Schiffbruch. Die Firma geht. Zumindest bis auf den VPS. Rest werde ich sehen.
Mein Plan war den Faden zu schließen, wenn ich die Konfig in die Fritze geladen habe und das Gesamtsystem läuft und keine Fragen mehr zum Thema auftauchen.
Alles Andere in einem neuen Faden
Gruß Thomas
Mein Plan war den Faden zu schließen, wenn ich die Konfig in die Fritze geladen habe und das Gesamtsystem läuft und keine Fragen mehr zum Thema auftauchen.
Alles Andere in einem neuen Faden
Gruß Thomas
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.
Wenn er aber auch die einzelnen Wireguard Clients von der Fritte aus erreichen will dann braucht er die 24er Maske sonst erreicht er ja nur den VPS.
Und genau das wäre für die Werkstatt wichtig. Dann kann ich nämlich die Fräsdaten auf der Maschine ablegen ohne sie vor Ort abholen zu müssen. Ursprünglich hatte ich da übrigens 32 Masken. Das habe ich übrigens gelesen und auch verstanden.
Auch die Fritzbox sofern sie als VPN Initiator (Client) konfiguriert ist benötigt keinen überflüssigen Preshared Key!
Nun, so wie ich es oben verstanden habe kann die Fritzbox beides Client und Server?!? Ursprünglich war das ja Thema des Fadens. Insofern habe ich jetzt reine IPv6 Responder auf der Fritze und will noch einen Initiator zum VPS installieren. (Die Frage warum will ich auch gleich beantworten. Sollte der VPS mal Tot sein, kann ich immer noch auf mein Netz.) Wie kriege ich unter den Umständen jetzt den PSK aus der Fritze? Insgesamt tritt jetzt etwas Verwirrung auf.
Wo ist denn jetzt überhaupt noch das Problem??? Ich seh keins mehr. Absolutes Standard-Gemüse.
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!
Es ging um die Konfig des "Firmenrechners". Dort ist die interne AllowedIPs Maske falsch.
Wieso? Da steht doch bereits ne /32 Maske in seiner aktuellen Server-Config für den Firmenrechner ...
[Peer]
#Peer Firma
PublicKey = GWc=
PresharedKey = NXY=
AllowedIPs = 100.64.114.4/32
Sorry, hatte es im Eifer des Gefechts mit der Firmenrechner Konfig verwechselt die ja auf die Fritte als Responder geht... 🙈
Hallo zusammen,
hoffentlich bekommt ihr Euch wegen mir nicht in die Haare. Ich habe jetzt die Konfig versucht in die Fritze zu laden. Wohlgemerkt, die Fritze sollte als Responder und Initiator arbeiten können. Das ist das Ergebnis des erstenVersuchs.
Jetzt kann ich wahrscheinlich die erste brauchbare Information zu dem Thread hinzufügen.
Damit die Fritze gleichzeitig als Initiator(Client) und Responder(Server) arbeiten kann muss zuerst der Client eingerichtet werden! Erst nachdem ich alle Einträge unter Wireguard gelöscht hatte konnte ich das Clientsetup laden und dann hat die Fritze auch die Verbindung sofort aufgebaut. Erst danach die Einzelverbindungen zu den Endgeräten neu anlegen. Auch das funktioniert dann einwandfrei über die AVM-Standards.
Um es Vorweg zu nehmen die Geschichte klappt in beide Richtungen und ich komme an alle Geräte in meinem Netz von außen dran. Auch an meine Werkstatt CNC. Was übrigens mit einer 32 Maske in der Clientconfig nicht funktioniert! (Ich wollte es wissen und habe es getestet) Bin ich wohl doch nicht zu blöd Tutorials zu lesen. Sorry, aqui.😜
Was ich noch nicht getestet habe sind die Verbindungen auf meine freigegebenen Laufwerke. Also die Netbios Zugriffe.
auf den Server.
Das probiere ich noch aus. (Heute schaffe ich das nicht mehr).
Trotzdem an dieser Stelle vorab ganz herzlichen Dank an alle Beteiligten. Einmal für die Hilfe und auch für die Geduld mit dem Opa. Richtig was gelernt und der nächste Faden kommt gewiss.
Nach den letzten Tests mache noch mal eine Zusammenfasssung in meinen Worten. So dass es ein Laie, wie ich mich bezeichnen würde, auch versteht und schließe den Faden dann.
Gruß Thomas
hoffentlich bekommt ihr Euch wegen mir nicht in die Haare. Ich habe jetzt die Konfig versucht in die Fritze zu laden. Wohlgemerkt, die Fritze sollte als Responder und Initiator arbeiten können. Das ist das Ergebnis des erstenVersuchs.
Jetzt kann ich wahrscheinlich die erste brauchbare Information zu dem Thread hinzufügen.
Damit die Fritze gleichzeitig als Initiator(Client) und Responder(Server) arbeiten kann muss zuerst der Client eingerichtet werden! Erst nachdem ich alle Einträge unter Wireguard gelöscht hatte konnte ich das Clientsetup laden und dann hat die Fritze auch die Verbindung sofort aufgebaut. Erst danach die Einzelverbindungen zu den Endgeräten neu anlegen. Auch das funktioniert dann einwandfrei über die AVM-Standards.
Um es Vorweg zu nehmen die Geschichte klappt in beide Richtungen und ich komme an alle Geräte in meinem Netz von außen dran. Auch an meine Werkstatt CNC. Was übrigens mit einer 32 Maske in der Clientconfig nicht funktioniert! (Ich wollte es wissen und habe es getestet) Bin ich wohl doch nicht zu blöd Tutorials zu lesen. Sorry, aqui.😜
Was ich noch nicht getestet habe sind die Verbindungen auf meine freigegebenen Laufwerke. Also die Netbios Zugriffe.
auf den Server.
Das probiere ich noch aus. (Heute schaffe ich das nicht mehr).
Trotzdem an dieser Stelle vorab ganz herzlichen Dank an alle Beteiligten. Einmal für die Hilfe und auch für die Geduld mit dem Opa. Richtig was gelernt und der nächste Faden kommt gewiss.
Nach den letzten Tests mache noch mal eine Zusammenfasssung in meinen Worten. So dass es ein Laie, wie ich mich bezeichnen würde, auch versteht und schließe den Faden dann.
Gruß Thomas
Die letzten Tests sind gemacht und ich kann meine Netzlaufwerke von extern über den Tunnel erreichen. Ein DNS Eintrag in der Client-Datei war dazu noch nötig, aber dazu unten mehr.
Für Leute wie mich, die nur rudimentäre Kenntnisse in Netzwerktechnik haben, empfehle ich, zu allererst die Tutorials unter den oben aufgeführten Links zu studieren. Man findet Sie unter den Beiträgen von catrell und aqui. Mir sind dabei auch Begriffe begegnet, mit denen ich erst einmal nichts anfangen konnte. Das passiert leicht, wenn man als Fachmann dem Laien etwas erklären will und ist normal. Aber eine Recherche danach lohnt sich, will man das geschriebene in Gänze verstehen. Oder sagen wir mal zumindest die Basic’s.
Alles in Allem habe ich dabei auch für mein berufliches Umfeld einige Erkenntnisse gewonnen, die mit Sicherheit ihre Umsetzung finden.
Hier möchte ich noch einmal alle Schritte zusammenfassen. Die Details finden sich oben im Faden.
• Infrastruktur planen.
Zuerst einmal Gedanken machen, wie denn das Netzwerk insgesamt aufgebaut sein soll. Wie viele Clients sollen zugreifen können? VPS-Server oder nicht? Usw. Ein Blatt Papier und eine handgezeichnete Grafik erleichtern das Leben gewaltig. Zumal man die Zeichnung im Laufe des Aufbaues und der Vorbereitungen um IP-Adressen, Namen etc. ergänzen kann.
• Wie soll der Zugang auf mein Heimnetz erfolgen?
Habe ich eine öffentliche IPv4 von meinem Provider oder sitze ich hinter einem CGNAT, weil ich einen neuen Glasfaseranschluss bekommen habe. Das ist bei mir der Fall und somit habe ich keine öffentliche IPv4 mehr. Dafür aber eine öffentliche IPv6. Liefert mir mein Handyprovider eine IPv6, dann brauche ich nur noch den HOTSPOT auf dem Handy zu konfigurieren und kann über z.B. eine Fritze und WireGuard auf mein Netz zugreifen. Das ist supereinfach zu konfigurieren und „Malen nach Zahlen“. Wem das reicht, der kann sich den ganzen Aufwand sparen und hier aufhören zu lesen. Ich brauche allerdings auch Zugang zu meinem Netz, wenn ausschließlich IPv4 Netze zur Verfügung stehen.
• Wie komme ich an eine öffentliche IPv4 Adresse?
Hier gibt es natürlich viele Möglichkeiten. Mein Provider, die DG, bietet über einen externen Dienstleister eine feste IPv4 an. Das geht richtig gut, kostet aber satte 12 Euronen im Monat. Wen das nicht schreckt, der ist dann auch schon fast fertig. Eine andere und damit meine genutzte Möglichkeit ist, sich einen sogenannten VPS-Server (Virtual Private Server) anzumieten. Es gibt jede Menge Provider, die diesen Dienst anbieten. Ich habe mich für IONOS VPS entschieden. Das Ding kostet genau 1 Eurone im Monat und bietet eine statische öffentliche IPv4 und eine statische öffentliche IPv6. Warum ist eine statische öffentliche IP wichtig. Nun, diese IP bleibt für immer so festgelegt und man spart sich einen Mechanismus wie dyndns, der zudem ebenfalls Kosten verursacht. Für weitere 2 Euronen gibt es sogar eine eigene Domain dazu. Letzteres verwende ich im Moment nicht. Sollte ich mal mein eigener Bildhoster werden wollen, dann kann man das immer noch machen.
• Wie geht das mit dem VPS?
Einfach einen Provider suchen, der öffentliche IPv4 und IPv6 zur Verfügung stellt und den kleinsten Server für’s kleinste Geld bestellen. Den Server nach Anleitung des Providers aufsetzen. Auf jeden Fall ein Linux vorzugsweise UBUNTU nehmen. Das System ist schlank und schnell und für unsere Zwecke absolut ausreichend. Nicht vergessen die Firewalleinstellungen für den Server anzupassen. Ich habe den gewünschten Wireguard Port auf UDP dort eintragen müssen, damit der Server überhaupt WG Anfragen angenommen hat. Alle anderen, nicht verwendeten Ports, sollte man schließen.
• IP Forward freigeben
Damit der VPS unsere Daten weitersenden kann muss auf dem VPS das IP„forwarding“ aktiviert werden. Steht im Netz wie es geht. (/etc/sysctl.conf)
• IP Adressbereiche für WG-Netz und Heimnetz aussuchen
Wenn man den Tutorials folgt, dann wird schnell klar, dass man sich nie um dieses Thema Gedanken gemacht hat. Einfach die Werkseinstellungen der Fritze genommen, den PC eigestöpselt und schon ist man im Internet. Soweit so gut aber für uns nicht brauchbar. Es ist erforderlich die Adressbereiche nach den einschlägigen RFC’s (Was das ist, steht in den Tutorials und Links) abzuändern. Ich verwende in dem Faden für das Heimnetz den Bereich 192.68.20.0/24 und für das WireGuard Netz den IP Bereich 100.64.114.0/24 (Das ist auf dem Echtsystem natürlich nicht mehr so, falls das hier jemand blind abtippt. 😉)
• Warum zwei Netze? Die Fritze verwendet doch auch immer das selbe Netz für die WG-Clients
Nun, die Fritze verwendet ein nicht 100% WG-kompatibles Setup. Da wir aber einen VPS einsetzen, auf dem die Standard WG Implementierung läuft, müssen wir uns auch an die Standard WG Vorgaben halten. Das setzt zwei getrennte Netze, eines für WG und eines fürs Heimnetz, was durch den WG-Tunnel den Teilnehmern Zugriff gewährt, voraus.
• Wie geht das jetzt mit dem WG und Heimnetz?
Am einfachsten kann man sich das vielleicht folgendermaßen vorstellen. Der VPS stellt mit dem WG-Netz auf dem VPS ein Tunnelsystem zur Verfügung. Die Tunnel sind miteinander verbunden und die Teilnehmer an unserem Heimnetz können sich in dem Tunnel frei bewegen. Und das so, dass von außen niemand unsere Kommunikation verstehen kann.
• WG-Server aufsetzen
Alles was hier steht kann man in den Tutorials nachlesen! Als nächstes ist WireGuard auf dem Server zu installieren. Nach der Installation empfiehlt es sich die Schlüsselpaare zu erzeugen. Sprechende Namen verwenden. Z.B. ServerPubKey, ServerPrivKey. Das macht man für alle zu erstellenden Clients immer mit dem gleichen Befehl. Außerdem brauchen wir noch für die Fritze einen sogenannten preshared Key. Da dieser immer der Gleiche ist genügt es den „preshared“ zu nennen.
Die Key‘s bitte vom Server entfernen und irgendwo sichern. Das wäre sonst so, wie wenn man den Schlüsselbund in der Eisdiele liegen lässt. Eine gute Praxis ist es, sich die Key’s mit Namen in eine Textdatei zu kopieren, die man bei der Erstellung der Konfigdateien zur Hand hat. Dann kann man die Schlüssel prima kopieren und kommt mit den Namen nicht durcheinander.
• WGServer.conf erstellen
Als nächstes erstellt man die Server Konfigurationsdatei wie oben gezeigt. Natürlich angepasst an die eigenen Bedürfnisse mit den eigenen Key’s und IP-Adressen
• WGClient.conf erstellen
Analog dazu kann man auch für alle Clients die Konfiguration erstellen. Bitte sprechende Namen verwenden, da jeder Client seine eigene Konfig bekommt. Man beachte unbedingt die außergewöhnliche Konfiguration der Fritzenanbindung. Ansonsten erleidet man Schiffbruch. (Oben im Faden) Die restlichen Clientkonfigurationen kann man kopieren und passt da lediglich die Schlüssel und die IP-Adressen an. Die Konfigs dann auch vom VPS sichern und ggf. löschen. Die werden da nicht mehr gebraucht
• WGServer mit „wg-quick up WGServer“ starten und testen
Ist der Server gestartet kann man mit dem Befehl „wg show“ den Status sehen. Erfolgt keine Ausgabe ist was schiefgelaufen. In dem Fall muss man auf die Ausgabe beim Starten des Servers achten. Meistens hat sich ein Fehler beim Tippen eingeschlichen. Mir passiert.
Bekommt man den Status angezeigt, dann läuft der WG-Server schon einmal.
• WGClientXXX auf dem Client PC einrichten und starten
Zuerst für das Betriebssystem des Client Rechners das passende WG Frontend herunterladen und installieren. Danach die passende ClientXXX.conf importieren und fertig. Danach kann man einfach auf Verbinden drücken. Hat alles geklappt, dann erscheinen im Status bei Sent und Receive aufsteigende Bytewerte. Auf der Kommandozeile sollte man dann noch die IP des VPS anpingen. Kriegt man eine Antwort geht die gesamte Mimik.
• Fritzbox Client installieren und starten
Bevor man die Clientkonfig in die Fritze einspielen kann, müssen alle existierenden und bereits konfigurierten Tunnel gelöscht werden. Das Problem ist, dass im Interfaceteil Konfigdatei der PublicKey unseres VPS steht. In einer bestehenden Konfiguration steht im Interfaceteil der PublicKey der Fritze. Das mag sie gar nicht und das Ergebnis kann man oben nachsehen. Ist die Tabelle leer kann man den Import ohne Probleme durchführen.
Bitte unbedingt die Sonderkonfiguration der Konfigdatei für die Fritze beachten. Ich widerhole mich. Tutorial, Links, lesen! Wenn alles OK ist baut die Fritze unmittelbar eine Verbindung zum VPS auf und die grüne LED im Listeneintrag der Fritze geht an. Jetzt kann man vom Heimnetz aus einen Ping auf den VPS absetzen. Bekommt man Antwort, dann läuft alles. Steht die Verbindung zum VPS kann man auch wieder Direktzugänge für einzelne Geräte konfigurieren. Damit arbeitet die Fritze gleichzeitig als Initiator(Client) und Responder(Server). Damit ist auch der Bezug zum Fadentitel hergestellt. 😊
• Besonderheiten beim Konfigurieren der Clients
Die Fritzbox bastelt ohne unser Zutun einen weiteren Eintrag in die Konfiguration, der da lautet: DNS = <IP der Fritze>, fritz.box.
Der Eintrag wird erzeugt, wenn man beim Laden der Konfigurationsdatei das Kontrollkästchen für „NETBIOS verwenden“ anklickt. Das ist sehr hilfreich, wenn man seine Netzlaufwerke unter dem Klarnamen erreichen will. Den gleichen Eintrag habe ich auch in meinen Clientdateien händisch hinzugefügt. Lässt man das weg, dann kann man seine Windows oder Samba Laufwerke nur noch durch die Angabe der IP als Servernamen erreichen bzw. verbinden. Aber das ist Geschmackssache. Noch etwas. Die Fritze hat die Angewohnheit bei den Allowed IP's neben dem Home- und WG-Netz auch noch einen "Gateway redirect" hinzuzufügen 0.0.0.0/0. Ich weiß nicht warum, weil damit die anderen Adressen außer Kraft gesetzt werden. Damit wird der gesamte Datenverkehr des Clients in den Tunnel geschaufelt. Man muss sich dann nicht wundern, wenn plötzlich alle Firmeninternen Netze perdü sind. Sinnvoll ist das nur, wenn man den gesamten Datenverkehr, insbesondere Internetverkehr, unsichtbar machen will. Im "Hackers Inn" sicher sinnvoll und der Chef muss auch nicht alles wissen. Ich habe mir zwei Konfigs gemacht, die ich entsprechend auswählen kann.
War doch mehr als gedacht, aber vielleicht hilft es dem Einen oder Anderen oder dem geplagten DG-Kunden. Insgesamt ist das WG-VPN sehr performant und wesentlich schneller als mein OpenVPN. Besonders an älteren Kabelanschlüssen (Meine Werkstatt). Hat man die Zusammenhänge erst einmal verinnerlicht auch wesentlich einfacher zu Administrieren.
Viele Grüße
Thomas
Für Leute wie mich, die nur rudimentäre Kenntnisse in Netzwerktechnik haben, empfehle ich, zu allererst die Tutorials unter den oben aufgeführten Links zu studieren. Man findet Sie unter den Beiträgen von catrell und aqui. Mir sind dabei auch Begriffe begegnet, mit denen ich erst einmal nichts anfangen konnte. Das passiert leicht, wenn man als Fachmann dem Laien etwas erklären will und ist normal. Aber eine Recherche danach lohnt sich, will man das geschriebene in Gänze verstehen. Oder sagen wir mal zumindest die Basic’s.
Alles in Allem habe ich dabei auch für mein berufliches Umfeld einige Erkenntnisse gewonnen, die mit Sicherheit ihre Umsetzung finden.
Hier möchte ich noch einmal alle Schritte zusammenfassen. Die Details finden sich oben im Faden.
• Infrastruktur planen.
Zuerst einmal Gedanken machen, wie denn das Netzwerk insgesamt aufgebaut sein soll. Wie viele Clients sollen zugreifen können? VPS-Server oder nicht? Usw. Ein Blatt Papier und eine handgezeichnete Grafik erleichtern das Leben gewaltig. Zumal man die Zeichnung im Laufe des Aufbaues und der Vorbereitungen um IP-Adressen, Namen etc. ergänzen kann.
• Wie soll der Zugang auf mein Heimnetz erfolgen?
Habe ich eine öffentliche IPv4 von meinem Provider oder sitze ich hinter einem CGNAT, weil ich einen neuen Glasfaseranschluss bekommen habe. Das ist bei mir der Fall und somit habe ich keine öffentliche IPv4 mehr. Dafür aber eine öffentliche IPv6. Liefert mir mein Handyprovider eine IPv6, dann brauche ich nur noch den HOTSPOT auf dem Handy zu konfigurieren und kann über z.B. eine Fritze und WireGuard auf mein Netz zugreifen. Das ist supereinfach zu konfigurieren und „Malen nach Zahlen“. Wem das reicht, der kann sich den ganzen Aufwand sparen und hier aufhören zu lesen. Ich brauche allerdings auch Zugang zu meinem Netz, wenn ausschließlich IPv4 Netze zur Verfügung stehen.
• Wie komme ich an eine öffentliche IPv4 Adresse?
Hier gibt es natürlich viele Möglichkeiten. Mein Provider, die DG, bietet über einen externen Dienstleister eine feste IPv4 an. Das geht richtig gut, kostet aber satte 12 Euronen im Monat. Wen das nicht schreckt, der ist dann auch schon fast fertig. Eine andere und damit meine genutzte Möglichkeit ist, sich einen sogenannten VPS-Server (Virtual Private Server) anzumieten. Es gibt jede Menge Provider, die diesen Dienst anbieten. Ich habe mich für IONOS VPS entschieden. Das Ding kostet genau 1 Eurone im Monat und bietet eine statische öffentliche IPv4 und eine statische öffentliche IPv6. Warum ist eine statische öffentliche IP wichtig. Nun, diese IP bleibt für immer so festgelegt und man spart sich einen Mechanismus wie dyndns, der zudem ebenfalls Kosten verursacht. Für weitere 2 Euronen gibt es sogar eine eigene Domain dazu. Letzteres verwende ich im Moment nicht. Sollte ich mal mein eigener Bildhoster werden wollen, dann kann man das immer noch machen.
• Wie geht das mit dem VPS?
Einfach einen Provider suchen, der öffentliche IPv4 und IPv6 zur Verfügung stellt und den kleinsten Server für’s kleinste Geld bestellen. Den Server nach Anleitung des Providers aufsetzen. Auf jeden Fall ein Linux vorzugsweise UBUNTU nehmen. Das System ist schlank und schnell und für unsere Zwecke absolut ausreichend. Nicht vergessen die Firewalleinstellungen für den Server anzupassen. Ich habe den gewünschten Wireguard Port auf UDP dort eintragen müssen, damit der Server überhaupt WG Anfragen angenommen hat. Alle anderen, nicht verwendeten Ports, sollte man schließen.
• IP Forward freigeben
Damit der VPS unsere Daten weitersenden kann muss auf dem VPS das IP„forwarding“ aktiviert werden. Steht im Netz wie es geht. (/etc/sysctl.conf)
• IP Adressbereiche für WG-Netz und Heimnetz aussuchen
Wenn man den Tutorials folgt, dann wird schnell klar, dass man sich nie um dieses Thema Gedanken gemacht hat. Einfach die Werkseinstellungen der Fritze genommen, den PC eigestöpselt und schon ist man im Internet. Soweit so gut aber für uns nicht brauchbar. Es ist erforderlich die Adressbereiche nach den einschlägigen RFC’s (Was das ist, steht in den Tutorials und Links) abzuändern. Ich verwende in dem Faden für das Heimnetz den Bereich 192.68.20.0/24 und für das WireGuard Netz den IP Bereich 100.64.114.0/24 (Das ist auf dem Echtsystem natürlich nicht mehr so, falls das hier jemand blind abtippt. 😉)
• Warum zwei Netze? Die Fritze verwendet doch auch immer das selbe Netz für die WG-Clients
Nun, die Fritze verwendet ein nicht 100% WG-kompatibles Setup. Da wir aber einen VPS einsetzen, auf dem die Standard WG Implementierung läuft, müssen wir uns auch an die Standard WG Vorgaben halten. Das setzt zwei getrennte Netze, eines für WG und eines fürs Heimnetz, was durch den WG-Tunnel den Teilnehmern Zugriff gewährt, voraus.
• Wie geht das jetzt mit dem WG und Heimnetz?
Am einfachsten kann man sich das vielleicht folgendermaßen vorstellen. Der VPS stellt mit dem WG-Netz auf dem VPS ein Tunnelsystem zur Verfügung. Die Tunnel sind miteinander verbunden und die Teilnehmer an unserem Heimnetz können sich in dem Tunnel frei bewegen. Und das so, dass von außen niemand unsere Kommunikation verstehen kann.
• WG-Server aufsetzen
Alles was hier steht kann man in den Tutorials nachlesen! Als nächstes ist WireGuard auf dem Server zu installieren. Nach der Installation empfiehlt es sich die Schlüsselpaare zu erzeugen. Sprechende Namen verwenden. Z.B. ServerPubKey, ServerPrivKey. Das macht man für alle zu erstellenden Clients immer mit dem gleichen Befehl. Außerdem brauchen wir noch für die Fritze einen sogenannten preshared Key. Da dieser immer der Gleiche ist genügt es den „preshared“ zu nennen.
Die Key‘s bitte vom Server entfernen und irgendwo sichern. Das wäre sonst so, wie wenn man den Schlüsselbund in der Eisdiele liegen lässt. Eine gute Praxis ist es, sich die Key’s mit Namen in eine Textdatei zu kopieren, die man bei der Erstellung der Konfigdateien zur Hand hat. Dann kann man die Schlüssel prima kopieren und kommt mit den Namen nicht durcheinander.
• WGServer.conf erstellen
Als nächstes erstellt man die Server Konfigurationsdatei wie oben gezeigt. Natürlich angepasst an die eigenen Bedürfnisse mit den eigenen Key’s und IP-Adressen
• WGClient.conf erstellen
Analog dazu kann man auch für alle Clients die Konfiguration erstellen. Bitte sprechende Namen verwenden, da jeder Client seine eigene Konfig bekommt. Man beachte unbedingt die außergewöhnliche Konfiguration der Fritzenanbindung. Ansonsten erleidet man Schiffbruch. (Oben im Faden) Die restlichen Clientkonfigurationen kann man kopieren und passt da lediglich die Schlüssel und die IP-Adressen an. Die Konfigs dann auch vom VPS sichern und ggf. löschen. Die werden da nicht mehr gebraucht
• WGServer mit „wg-quick up WGServer“ starten und testen
Ist der Server gestartet kann man mit dem Befehl „wg show“ den Status sehen. Erfolgt keine Ausgabe ist was schiefgelaufen. In dem Fall muss man auf die Ausgabe beim Starten des Servers achten. Meistens hat sich ein Fehler beim Tippen eingeschlichen. Mir passiert.
Bekommt man den Status angezeigt, dann läuft der WG-Server schon einmal.
• WGClientXXX auf dem Client PC einrichten und starten
Zuerst für das Betriebssystem des Client Rechners das passende WG Frontend herunterladen und installieren. Danach die passende ClientXXX.conf importieren und fertig. Danach kann man einfach auf Verbinden drücken. Hat alles geklappt, dann erscheinen im Status bei Sent und Receive aufsteigende Bytewerte. Auf der Kommandozeile sollte man dann noch die IP des VPS anpingen. Kriegt man eine Antwort geht die gesamte Mimik.
• Fritzbox Client installieren und starten
Bevor man die Clientkonfig in die Fritze einspielen kann, müssen alle existierenden und bereits konfigurierten Tunnel gelöscht werden. Das Problem ist, dass im Interfaceteil Konfigdatei der PublicKey unseres VPS steht. In einer bestehenden Konfiguration steht im Interfaceteil der PublicKey der Fritze. Das mag sie gar nicht und das Ergebnis kann man oben nachsehen. Ist die Tabelle leer kann man den Import ohne Probleme durchführen.
Bitte unbedingt die Sonderkonfiguration der Konfigdatei für die Fritze beachten. Ich widerhole mich. Tutorial, Links, lesen! Wenn alles OK ist baut die Fritze unmittelbar eine Verbindung zum VPS auf und die grüne LED im Listeneintrag der Fritze geht an. Jetzt kann man vom Heimnetz aus einen Ping auf den VPS absetzen. Bekommt man Antwort, dann läuft alles. Steht die Verbindung zum VPS kann man auch wieder Direktzugänge für einzelne Geräte konfigurieren. Damit arbeitet die Fritze gleichzeitig als Initiator(Client) und Responder(Server). Damit ist auch der Bezug zum Fadentitel hergestellt. 😊
• Besonderheiten beim Konfigurieren der Clients
Die Fritzbox bastelt ohne unser Zutun einen weiteren Eintrag in die Konfiguration, der da lautet: DNS = <IP der Fritze>, fritz.box.
Der Eintrag wird erzeugt, wenn man beim Laden der Konfigurationsdatei das Kontrollkästchen für „NETBIOS verwenden“ anklickt. Das ist sehr hilfreich, wenn man seine Netzlaufwerke unter dem Klarnamen erreichen will. Den gleichen Eintrag habe ich auch in meinen Clientdateien händisch hinzugefügt. Lässt man das weg, dann kann man seine Windows oder Samba Laufwerke nur noch durch die Angabe der IP als Servernamen erreichen bzw. verbinden. Aber das ist Geschmackssache. Noch etwas. Die Fritze hat die Angewohnheit bei den Allowed IP's neben dem Home- und WG-Netz auch noch einen "Gateway redirect" hinzuzufügen 0.0.0.0/0. Ich weiß nicht warum, weil damit die anderen Adressen außer Kraft gesetzt werden. Damit wird der gesamte Datenverkehr des Clients in den Tunnel geschaufelt. Man muss sich dann nicht wundern, wenn plötzlich alle Firmeninternen Netze perdü sind. Sinnvoll ist das nur, wenn man den gesamten Datenverkehr, insbesondere Internetverkehr, unsichtbar machen will. Im "Hackers Inn" sicher sinnvoll und der Chef muss auch nicht alles wissen. Ich habe mir zwei Konfigs gemacht, die ich entsprechend auswählen kann.
War doch mehr als gedacht, aber vielleicht hilft es dem Einen oder Anderen oder dem geplagten DG-Kunden. Insgesamt ist das WG-VPN sehr performant und wesentlich schneller als mein OpenVPN. Besonders an älteren Kabelanschlüssen (Meine Werkstatt). Hat man die Zusammenhänge erst einmal verinnerlicht auch wesentlich einfacher zu Administrieren.
Viele Grüße
Thomas
1Wie 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! 😉
Hallo aqui,
Danke für den wirlich interessanten Link. Sicherlich findet sich hier im Forum ein Klientel was mit den verwendeten Fachbegriffen in dem Tutorial umgeht wie unsereins mit dem Brotmesser. Aus mehreren Fachartikeln weiß ich, dass die Impementation von IPSec nicht trivial ist. (Und wenn ich das Tutorial lese stimme ich dem zu) Ich denke, dass die Implementierung von WG, so wie hier im Forum und oben beschrieben mindestens 95% der Anforderung von Klein- und Privatanwendern erfüllt. Außerdem ist das für interessierte Laien auf dem Gebiet, zu denen ich mich auch zähle, nachvollziehbar und somit selbst umsetzbar. Darauf wird viel zu selten Wert gelegt und ich kenne das zu Genüge aus meiner beruflichen Praxis.
Das ganze läuft auf IPv6 und im Mischbetrieb mit IPv4 ohne Probleme. Peformance spielt da eine untergeordnete Rolle. Ein Formel 1 Wagen ist auch performanter als meine Limousine. Damit käme ich im Tagesgeschäft aber auch nicht viel schneller von A nach B. Erfordert aber viel Sachverstand und Aufwand und macht daher keinen Sinn. Abgesehen davon ist meine WG-Lösung schneller und performanter als jede bisher verwendete OVPN-Lösung, die bei den meisten Firmen, mit denen wir zu tun haben, auf einer z.B. pfSense implementiert sind. Das mag in anderen Regionen vielleicht anders sein.
"omnes viae Romam ducunt" Ich finde man sollte immer den Nutzen ins Verhältnis zum Aufwand stellen und den Wissensstand der Protagonisten berücksichtigen. Worum geht es eigentlich? Hätte ich nicht den Sonderfall mit meiner, Achtung! Hobbywerkstatt gehabt, dann gäbe es diesen Thread nicht. Dann hätte ich mir die Lösung auf der Fritze in 5 Minuten zusammengeklickt. Du und catrell habt mir in kurzer Zeit, mit eurer Expertise, sehr viel beigebracht und die Arbeit war von Erfolg gekrönt. Vielleicht ist sogar noch jemand dankbar für die oben (laienhaft) dokumentierte Lösung, weil er im Moment genauso hilflos da steht wie ich am Anfang. Was wollen wir also mehr?
Gruß Thomas
Danke für den wirlich interessanten Link. Sicherlich findet sich hier im Forum ein Klientel was mit den verwendeten Fachbegriffen in dem Tutorial umgeht wie unsereins mit dem Brotmesser. Aus mehreren Fachartikeln weiß ich, dass die Impementation von IPSec nicht trivial ist. (Und wenn ich das Tutorial lese stimme ich dem zu) Ich denke, dass die Implementierung von WG, so wie hier im Forum und oben beschrieben mindestens 95% der Anforderung von Klein- und Privatanwendern erfüllt. Außerdem ist das für interessierte Laien auf dem Gebiet, zu denen ich mich auch zähle, nachvollziehbar und somit selbst umsetzbar. Darauf wird viel zu selten Wert gelegt und ich kenne das zu Genüge aus meiner beruflichen Praxis.
Das ganze läuft auf IPv6 und im Mischbetrieb mit IPv4 ohne Probleme. Peformance spielt da eine untergeordnete Rolle. Ein Formel 1 Wagen ist auch performanter als meine Limousine. Damit käme ich im Tagesgeschäft aber auch nicht viel schneller von A nach B. Erfordert aber viel Sachverstand und Aufwand und macht daher keinen Sinn. Abgesehen davon ist meine WG-Lösung schneller und performanter als jede bisher verwendete OVPN-Lösung, die bei den meisten Firmen, mit denen wir zu tun haben, auf einer z.B. pfSense implementiert sind. Das mag in anderen Regionen vielleicht anders sein.
"omnes viae Romam ducunt" Ich finde man sollte immer den Nutzen ins Verhältnis zum Aufwand stellen und den Wissensstand der Protagonisten berücksichtigen. Worum geht es eigentlich? Hätte ich nicht den Sonderfall mit meiner, Achtung! Hobbywerkstatt gehabt, dann gäbe es diesen Thread nicht. Dann hätte ich mir die Lösung auf der Fritze in 5 Minuten zusammengeklickt. Du und catrell habt mir in kurzer Zeit, mit eurer Expertise, sehr viel beigebracht und die Arbeit war von Erfolg gekrönt. Vielleicht ist sogar noch jemand dankbar für die oben (laienhaft) dokumentierte Lösung, weil er im Moment genauso hilflos da steht wie ich am Anfang. Was wollen wir also mehr?
Gruß Thomas
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.
Nachdem ich mich weiter mit dem Thema WG beschäftigt habe sind noch ein paar Verständnisfragen aufgetaucht. Ich denke ich habe die Antworten, würde das aber gerne Verifizieren. Ich bin mal so frei.
Liege ich da mit meinem laienhaften Verständnis richtig oder habe ich etwas Wichtiges vergessen?
Gruß Thomas
- 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.
[Peer]
PublicKey = Thk=
PresharedKey = kXY=
AllowedIPs = 100.64.114.0/24, 192.168.20.0/24
Endpoint = <VPS.ip>:51820
PersistentKeepalive = 25- 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.
[Peer]
#Peer FritzBox
PublicKey = IUg=
PresharedKey = KxY=
AllowedIPs = 100.64.114.6/32,192.168.20.0/24- Solange auf dem VPS, also dem WGServer, das ipforwarding aktiviert ist kümmert sich wg-quick um die richtigen Routingeinträge.
Liege ich da mit meinem laienhaften Verständnis richtig oder habe ich etwas Wichtiges vergessen?
Gruß Thomas
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.2
Hallo catrell,
Zuerst einmal vielen Dank für die Info. Eine Wissenslücke nachhaltig gefüllt. 😊
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.
Damit jetzt von einem beliebigen Teilnehmer im gesamten Netz auf einen beliebigen Teilnehmer im Netz zugegriffen werden kann muss die Client Konfig eines jeden Host's diese Netze unter AlowedIPs enthalten? Jedenfalls, wenn Datenpakete in und von diesen Netzen ausgetauscht werden sollen?
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.
Gruß Thomas
Zuerst einmal vielen Dank für die Info. Eine Wissenslücke nachhaltig gefüllt. 😊
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.
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- 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- Der bestehende Eintrag in der Server Konfig für das Heimnetz müsste dann entsprechend um das "Weit weg Netz? erweitert werden?
[Peer]
#Peer FritzBox
PublicKey = lUg=
PresharedKey = NXY=
AllowedIPs = 100.64.114.6/32,192.168.20.0/24,192.168.30.0/24Damit jetzt von einem beliebigen Teilnehmer im gesamten Netz auf einen beliebigen Teilnehmer im Netz zugegriffen werden kann muss die Client Konfig eines jeden Host's diese Netze unter AlowedIPs enthalten? Jedenfalls, wenn Datenpakete in und von diesen Netzen ausgetauscht werden sollen?
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.
Gruß Thomas
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/24Nein, 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 = 25Nein 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/24Bleibt 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.
1
Hallo catrell,
habe den Denkfehler ekannt. Der Server legt das Routing an und somit braucht er nur zu wissen an welchen Peer er den Traffic für das 20er bzw. 30er Netz schicken muss. (Jeder Eintrag nur einmal!)
Beim Client sieht das natürlich anders aus. Der muss Routen in beide Netze incl. WG-Netz haben damit er weiß in welches Netz er den Traffic schicken soll. Der Client schickt also den Traffic für das 20er und 30er Netz über das WG-Netz an den Server. Dieser schaut in seinen Routen nach wohin das gehen soll (20er, 30er oder anderer WG-Client) und dann ab dahin.
Wenn ich Deine Worte richtig wiedergegeben habe, dann habe ich das verstanden. Ist eigentlich sehr einfach und logisch.
Bleibt die Frage nach dem DNS.
Gäbe es eine Möglichkeit auf dem VPS einen DNS-Dienst einzurichten, der nur auf dem WG- und angebundenen Netzen reagiert? Was macht man dann mit den DNS-Servern auf der Fritze?
Hmm. Auch wenn ich mich lächerlich mache. Da fällt mir spontan die LMHOSTS bei Windows ein. Wenn es das überhaupt noch gibt. Das setzt aber statische IP's voraus. Auch nicht das Gelbe vom Ei. Scheint beliebig kompliziert zu sein. Aber eigentlich müsste ein DNS auf dem Server sich doch "nur" die DNS-Einträge der beiden Fritzen holen und in seiner Tabelle ablegen? (Mal so ins Blaue gedacht)
Gruß Thomas
habe den Denkfehler ekannt. Der Server legt das Routing an und somit braucht er nur zu wissen an welchen Peer er den Traffic für das 20er bzw. 30er Netz schicken muss. (Jeder Eintrag nur einmal!)
Beim Client sieht das natürlich anders aus. Der muss Routen in beide Netze incl. WG-Netz haben damit er weiß in welches Netz er den Traffic schicken soll. Der Client schickt also den Traffic für das 20er und 30er Netz über das WG-Netz an den Server. Dieser schaut in seinen Routen nach wohin das gehen soll (20er, 30er oder anderer WG-Client) und dann ab dahin.
Wenn ich Deine Worte richtig wiedergegeben habe, dann habe ich das verstanden. Ist eigentlich sehr einfach und logisch.
Bleibt die Frage nach dem DNS.
Gäbe es eine Möglichkeit auf dem VPS einen DNS-Dienst einzurichten, der nur auf dem WG- und angebundenen Netzen reagiert? Was macht man dann mit den DNS-Servern auf der Fritze?
da gehört i.d.R. nur DNS-Server rein welche alle deine Hosts kennt bzw. dort hinterlegt sind, und dieser macht i.d.R. nur an den mobilen Clients Sinn.
Hmm. Auch wenn ich mich lächerlich mache. Da fällt mir spontan die LMHOSTS bei Windows ein. Wenn es das überhaupt noch gibt. Das setzt aber statische IP's voraus. Auch nicht das Gelbe vom Ei. Scheint beliebig kompliziert zu sein. Aber eigentlich müsste ein DNS auf dem Server sich doch "nur" die DNS-Einträge der beiden Fritzen holen und in seiner Tabelle ablegen? (Mal so ins Blaue gedacht)
Gruß Thomas
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.
Hallo zusammen,
das mit dem DNS lasse ich lieber. Macht keinen Sinn bei den paar Hosts. Und diejenigen die relevant sind kann man leicht in der LMHOST pflegen. Man sollte auch die Kirche im Dorf lassen.
Was aber gut geht ist Profinet über den Tunnel routen. Ich habe seit gestern eine kleine S7-1200CPU als Telemetriehost laufen und der tauscht seine Messswerte ohne Murren und Knurren mit der 1500er hier im Büro aus. Die Latenzzeiten liegen bei unter 40ms. Geroutet wird folgendermaßen: SPS -> MiniPC mit WG -> FB(kann kein Wireguard. Update nicht gemacht, ist nicht meine Box) an einem Breitbandanschluss -> VPS -> Heimnetz.
Interessante Beobachtung: Die Latenzzeiten gingen kontinuierlich runter. Angefangen habe ich heute Morgen mit 125-150ms. Innerhalb des Vormittags pendelte sich das dann bei ca. 40ms ein. Dabei gab es auf dem Anschluss ab 8 Uhr ansteigenden Internet Traffic. Ich hätte es andersherum erwartet. Gibt es eine Erklärung dafür?
Gruß Thomas
das mit dem DNS lasse ich lieber. Macht keinen Sinn bei den paar Hosts. Und diejenigen die relevant sind kann man leicht in der LMHOST pflegen. Man sollte auch die Kirche im Dorf lassen.
Was aber gut geht ist Profinet über den Tunnel routen. Ich habe seit gestern eine kleine S7-1200CPU als Telemetriehost laufen und der tauscht seine Messswerte ohne Murren und Knurren mit der 1500er hier im Büro aus. Die Latenzzeiten liegen bei unter 40ms. Geroutet wird folgendermaßen: SPS -> MiniPC mit WG -> FB(kann kein Wireguard. Update nicht gemacht, ist nicht meine Box) an einem Breitbandanschluss -> VPS -> Heimnetz.
Interessante Beobachtung: Die Latenzzeiten gingen kontinuierlich runter. Angefangen habe ich heute Morgen mit 125-150ms. Innerhalb des Vormittags pendelte sich das dann bei ca. 40ms ein. Dabei gab es auf dem Anschluss ab 8 Uhr ansteigenden Internet Traffic. Ich hätte es andersherum erwartet. Gibt es eine Erklärung dafür?
Gruß Thomas
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!
Vergessen und freuen das es klappt was in Zeiten von Billo Providern mit DS-Lite ja nicht immer gegeben ist!
Wahrscheinlich hast Du Recht. Ich lasse den Versuchsaufbau noch ein paar Tage laufen und baue dann mal um. (Gleicher Aufbau, jedoch eine LTE-Fritze am anderen Ende ). Ich meine, wenn man mal kapiert hat wie sowas geht, dann kommen auch Ideen was man noch damit anstellen könnte.
Hintergrund ist ein Fernwartungsthema. Fernwartungslösungen über VPN gibt es wie Sand am Meer. Allerdings läßt sich die Industrie sowas richtig teuer bezahlen. Hier wäre der Einsatz eines LTE bzw. G5 Routers recht einfach. Sowas versendet man an den Kunden, der stöpselt das in die Maschine und der Techniker ist "drin". Der WG-Server ist im eigenen Haus, was die Datensicherheit mit Sicherheit erhöht. Kommt natürlich darauf an, wie einfach es ist die Zugangsbeschränkung einer Fritze zu knacken.
Gruß Thomas
