DS-Lite Glasfaseranschluss - Wireguard VPN via IPv6 möglich ?
Hallo zusammen,
mich konfrontiert gerade zum ersten Mal das Thema "DS-Lite Anschluss", und dem damit verbundenen Problem mit den nicht vorhandenen (öffentlichen) IPv4 Adressen. Aber der Reihe nach ... ich habe die Aufgabe vor der Brust einen VPN Zugang für einen Kollegen bereitzustellen.
Gesagt getan schnurrt ein frisch aufgesetzter Wireguard Server auf einem Raspi. DynDNS ist auch eingerichtet.
Dann habe ich mir natürlich die Nase angerannt und musste feststellen das ich die 4er Adresse nicht erreichen kann, Stichwort Carrier Grade NAT usw.
Was ich nicht verstehe; ich bin dann davon ausgegangen das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).
Also habe ich in der Fritz!Box mal testweise eine IPv6-Portfreigabe eingerichtet auf den SSH Port vom Raspi. Keine Chance.
Seltsam ist meines Erachtens das die IPv6 Adresse (welche mir die Fritz!Box anzeigt bzw. DynDNS "auflöst") eine andere ist wie mir zum Beispiel die Seite
https://ipv6-test.com/ anzeigt (die IPv4 Adresse ist auch eine andere, aber das ist mir logisch durch das CGNAT). Hab ich einen Denkfehler oder wird in meinem Fall eben auch die 6er Adresse via CGNAT versteckt ? Der Provider selbst (Stiegeler) möchte das für mich klären bzw. hatte darauf jetzt auch keine konkrete Antwort.
Ich will es einfach am Ende verstehen und ob ich mich gleich einer Lösung zuwenden muss in welcher ein VPS zwischen drinsteht.
thx!
mich konfrontiert gerade zum ersten Mal das Thema "DS-Lite Anschluss", und dem damit verbundenen Problem mit den nicht vorhandenen (öffentlichen) IPv4 Adressen. Aber der Reihe nach ... ich habe die Aufgabe vor der Brust einen VPN Zugang für einen Kollegen bereitzustellen.
Gesagt getan schnurrt ein frisch aufgesetzter Wireguard Server auf einem Raspi. DynDNS ist auch eingerichtet.
Dann habe ich mir natürlich die Nase angerannt und musste feststellen das ich die 4er Adresse nicht erreichen kann, Stichwort Carrier Grade NAT usw.
Was ich nicht verstehe; ich bin dann davon ausgegangen das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).
Also habe ich in der Fritz!Box mal testweise eine IPv6-Portfreigabe eingerichtet auf den SSH Port vom Raspi. Keine Chance.
Seltsam ist meines Erachtens das die IPv6 Adresse (welche mir die Fritz!Box anzeigt bzw. DynDNS "auflöst") eine andere ist wie mir zum Beispiel die Seite
https://ipv6-test.com/ anzeigt (die IPv4 Adresse ist auch eine andere, aber das ist mir logisch durch das CGNAT). Hab ich einen Denkfehler oder wird in meinem Fall eben auch die 6er Adresse via CGNAT versteckt ? Der Provider selbst (Stiegeler) möchte das für mich klären bzw. hatte darauf jetzt auch keine konkrete Antwort.
Ich will es einfach am Ende verstehen und ob ich mich gleich einer Lösung zuwenden muss in welcher ein VPS zwischen drinsteht.
thx!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3327519249
Url: https://administrator.de/contentid/3327519249
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
39 Kommentare
Neuester Kommentar
Hallo!
Bei IPv6 (nicht generell, aber bei deinem Setup gehe ich davon aus) besitzen alle Endgeräte eine eigene, öffentliche IPv6-Adresse. Das heißt, dass du mit jedem Endgerät eine eigene IPv6-Adresse im Internet hast und auch auf deiner Testseite jeweils eine andere angezeigt bekommst.
Du musst die IPv6-Adresse des Raspberry Pis benutzen, um den Pi zu erreichen, nicht die IPv6-Adresse deiner FRITZ!Box. Normalerweise ändern sich nur die Prefixe der IPv6, das könnte dir noch weitere Probleme bereiten wenn dein DynDNS-Anbieter kein IPv6 unterstützt.
LG, runthegaunz
Bei IPv6 (nicht generell, aber bei deinem Setup gehe ich davon aus) besitzen alle Endgeräte eine eigene, öffentliche IPv6-Adresse. Das heißt, dass du mit jedem Endgerät eine eigene IPv6-Adresse im Internet hast und auch auf deiner Testseite jeweils eine andere angezeigt bekommst.
Du musst die IPv6-Adresse des Raspberry Pis benutzen, um den Pi zu erreichen, nicht die IPv6-Adresse deiner FRITZ!Box. Normalerweise ändern sich nur die Prefixe der IPv6, das könnte dir noch weitere Probleme bereiten wenn dein DynDNS-Anbieter kein IPv6 unterstützt.
LG, runthegaunz
das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).
Das ist sie auch immer! Es gibt ja bekanntlich gar kein NAT bei IPv6.Hier ein Raspberry Pi Interface in einem lokalen LAN
/home/pi# ip a
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:b6:4f:92:05 brd ff:ff:ff:ff:ff:ff
inet 192.168.28.7/26 brd 192.168.28.63 scope global noprefixroute eth1
valid_lft forever preferred_lft forever
inet6 2003:cb:73a:6383:759e:78b5:c2f4:ae18/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 40750sec preferred_lft 36430sec
inet6 fe80::3e61:d1af:32e5:a205/64 scope link
valid_lft forever preferred_lft forever
:/home/pi# ping -6 www.heise.de
PING www.heise.de(www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85)) 56 data bytes
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1 ttl=55 time=17.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2 ttl=55 time=15.0 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=3 ttl=55 time=15.1 ms
64 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85: icmp_seq=5 ttl=55 time=14.9 ms
Seltsam ist meines Erachtens das die IPv6 Adresse
Seltsam ist das nicht. Ein v6 Device kann mehrere v6 Adressen haben. Oft hat es die EUI-64 Adresse und eine mit Privacy Extensions und immer die Link Local Adresse, also 3.Du meinst ich kann den Pi im lokalen direkt "von außen" über die IPv6 Adresse ansprechen
Ja natürlich. Allerdings erfordert das 2 Voraussetzungen:- Dein remoter Client muss natürlich auch in einem öffentlichen v6 Netz sein.
- Deine lokale Firewall muss z.B. TCP Port 22 auf die lokale v6 IP des RasPis freigebene haben. (Macht man in der FritzBox unter Freigaben) Normal blockt die Router Firewall alle eingehenden IPv6 Sesssions von außen wie es sich gehört. Du willst ja nicht das dein lokales LAN von jedermann weltweit erreichbar ist, oder ?!
weil in der Adresse die ersten 64Bit das Netzwerk kennzeichnen, korrekt ?
Bei einem /64er Prefix ja. Es gibt aber auch noch andere Subnetzmasken. Portfreigaben sind nach wie vor erforderlich !?! Also zum Beispiel den Wireguard Port explizit freigeben
Das ist richtig! Wohlgemerkt freigeben.Weiterleiten gibt es nicht, da es kein NAT gibt bei IPv6.
sind aber nur die ersten 32Bit die selben.
Das ist die Provider Prefix Delegation, also das Subnetz was du vom Provider bekommst für deinenj lokalen LANs (meist ein /56er). Die FB ergänzt das dann und macht daraus im lokalen LAN /64er Netze.Noch viel lernen du noch musst...
Vielleicht hilft es wenn du dein IPv6 Wissen mit etwas kostenloser Literatur auf die Sprünge hilfst:
https://danrl.com/ipv6/
Wie man das lokale v4 IP Netz dann via VPN mit einem Jumphost, vServer usw. erreichbar macht erklären dir diverse Tutorials hier im Forum:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Feste IPs zuhause in pfsense via WireGuard Tunnel
Feste IPs zuhause in pfsense via GRE Tunnel
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Servus @aqui
Das man NAT bei IPv6 natürlich meist nie haben will außer in Ausnahmefällen steht natürlich außer Frage .
Grüße Uwe
Zitat von @aqui:
NaNaNa, geben tut es das schon, iptables, nftables, Mikrotik usw. können es out of the box, und das wird sogar auch bei einigen LTE-Carriern bei IPv6 genutzt (vornehmlich USA und auch einige hier). Man stelle sich nur mal vor das jemand ein DDOS auf eine IPv6 eines Mobilfunkteilnehmers fährt und der wundert sich das sein Datenvolumen nach der hälfte des Monats aufgebraucht ist obwohl er selbst keine Hand angelegt hat.das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).
Das ist sie auch immer! Es gibt ja bekanntlich gar kein NAT bei IPv6.Das man NAT bei IPv6 natürlich meist nie haben will außer in Ausnahmefällen steht natürlich außer Frage .
Grüße Uwe
Hallo,
Ok kurz um nimm doch bitte einfach den My!Fritz Account und dann mach es darüber. Ist nicht so cool und neu
aber es funktioniert und kann auch mit den AVM APPs benutzt werde.
> Ich will es einfach am Ende verstehen und ob ich mich gleich einer Lösung zuwenden muss in welcher ein
WireGuard Server mit an Board sein (in der AVM FB) somit fällt dann auch die RaspBerry PI Sache fast unter den Tisch.
Dobby
Also habe ich in der Fritz!Box mal testweise eine IPv6-Portfreigabe eingerichtet auf den SSH Port vom Raspi.
Keine Chance.
Und dürfen wir erfahren welche AVM FB das denn nun genau ist? Eine 5530 oder 5590?Keine Chance.
Ok kurz um nimm doch bitte einfach den My!Fritz Account und dann mach es darüber. Ist nicht so cool und neu
aber es funktioniert und kann auch mit den AVM APPs benutzt werde.
> Ich will es einfach am Ende verstehen und ob ich mich gleich einer Lösung zuwenden muss in welcher ein
VPS zwischen drinsteht.
Nimm My!Fritz von AVM und alles wird gut. In einer der nächsten FritzOS Versionen sollte dann auch einWireGuard Server mit an Board sein (in der AVM FB) somit fällt dann auch die RaspBerry PI Sache fast unter den Tisch.
Dobby
Hallo,
Dobby
UniFi Security Gateway als Router, Draytek Vigor als Modem
Und dort ist dann auf der anderen Seite (VPN Gegenseite) WireGuard drauf?es handelt sich um eine Fritz!Box 7390
Müssen da nur Ports geöffnet (weitergeleitet) werden oder auch Protokolle angegeben werden?Dobby
Miete dir einfach einen kleinen vServer für 1-2 Euro /Monat, und benutze diesen als Jumphost (kleine Linux Instanz mit Wireguard/Strongswan/etc.). Du baust dann mit dem Raspi eine VPN-Verbindung auf den Jumphost auf und mit deinen Clients verbindest du dich mit dem Jumphost und kommst so von jedem Standort auf dein Netz egal ob IPv6 oder nur IPv4 verfügbar ist. Der Jumphost kann dann bei Bedarf auch noch andere Aufgaben erledigen.
Grüße Uwe
Grüße Uwe
Alternativ, wenn Du Dir die 1-2 EUR/Monat (und die Bastelei) sparen möchtest, könntest auf dem lokalen Zielgerät auch Zerotier installieren. Das ist bis 50 Clients kostenlos. ist allerdings vermutlcih nicht das richtige, wenn Du von extern ins komplette Netz möchtest. Zumindest habe ich das Routing noch nicht hinbekommen.
Zitat von @Kollisionskurs:
ok, verstanden ... danke.
Aber nur um es auch richtig einzuordnen - diese Lösungen mit einem Jumphost usw. sind doch quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder ? Und so wie ich es sehe (vielleicht hab ich da den Denkfehler) bekomme ich das Ganze doch zum fliegen, wenn:
So lange du unterwegs über keine öffentliche IPv6 Anbindung verfügst bringt dir die IPv6-Anbindung daheim nichts.ok, verstanden ... danke.
Aber nur um es auch richtig einzuordnen - diese Lösungen mit einem Jumphost usw. sind doch quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder ? Und so wie ich es sehe (vielleicht hab ich da den Denkfehler) bekomme ich das Ganze doch zum fliegen, wenn:
- mein öffentliches Netz auch eine IPv6 Anbindung hat (wie erwähnt liegt es da eher an meiner Konfiguration bzw. der Provider "liefert" mir ja eigentlich IPv6)
Dein Provider ja, aber wenn du dich unterwegs bspw. in einem Hotspot befindest der dir nur IPv4 bietet hast du wieder das selbe Problem du kommst nicht auf "direktem" Wege auf deine IPv6 Adresse...Du brauchst also zwingend eine Zwischenstation die per IPv4 erreichbar ist sei es ein Jumphost oder Zerotier etc. damit du wirklich von überall in dein Netz kommst.
Hallo nochmal,
da nicht, die ermöglichen Dir quasi alle nur das man von außen auf eine andere Gegenstelle per VPN
verbinden kann.
- Eine dynamische und keine statische (feste) IP Adresse
- IPvx Mix und ein GCNAT dazwischen.
Dobby
Aber nur um es auch richtig einzuordnen - diese Lösungen mit einem Jumphost usw. sind doch
quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder?
Darum geht es ja bei DSlight und CGNAT!quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder?
Und so wie ich es sehe (vielleicht hab ich da den Denkfehler) bekomme ich das Ganze doch zum fliegen, wenn:
DynDNS, My!Fritz und der Jumphost erfüllen mehr oder weniger alle den gleichen Zweck. Verirr Dichda nicht, die ermöglichen Dir quasi alle nur das man von außen auf eine andere Gegenstelle per VPN
verbinden kann.
- mein öffentliches Netz auch eine IPv6 Anbindung hat (wie erwähnt liegt es da eher an meiner
Konfiguration bzw. der Provider "liefert" mir ja eigentlich IPv6)
Es geht hier in der Regel immer um zwei Sachen;Konfiguration bzw. der Provider "liefert" mir ja eigentlich IPv6)
- Eine dynamische und keine statische (feste) IP Adresse
- IPvx Mix und ein GCNAT dazwischen.
Und dann eben noch das Wireguard entsprechend IPv6 konform konfiguriert ist. DynDNS
entsprechend eingerichtet usw.
Ob Du nun DynDNS, My!Fritz oder den Jumphost benutzt ist eigentlich nur Nebensache.entsprechend eingerichtet usw.
Dobby
Wenn's das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
- IPv4 Forwarding mit Entkommentieren der Zeile net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf mit einem anschliessenden Reboot oder systemctl restart networking hast du gemacht? Andernfalls kann der Server nicht routen.
- Wo kommt das 10.0.0.0/24 Netz her? Existiert laut deiner Beschreibung nirgendwo!
- Zusätzlich sind deine Subnetzmasken im Client Setup falsch was das interne Netz anbetrifft, damit scheitert das Crypto Routing!
Merkzettel: VPN Installation mit Wireguard
und auch hier:
Wireguard Site2Site mit Roadwarrior
entsprechend korrigiert -
Dennoch hast du aber falsche Masken sowohl der VPN Adapter wie auch der AllowedIPs gepostet! Beim Server hast du es ja komischerweise richtig gemacht?! (Siehe das Beispiel oben)Richtig wäre für...
Client A:
[Interface]
PrivateKey = xyz
Address = 10.66.66.2/24
DNS = 10.10.10.2
[Peer]
PublicKey = xyz
PresharedKey = xyz
AllowedIPs = 10.66.66.1/32, 10.0.0.0/24, 192.168.178.0/24
Endpoint = myGateway:45703
Client B:
[Interface]
PrivateKey = xyz
Address = 10.66.66.3/24
DNS = 192.168.178.1
[Peer]
PublicKey = xyz
PresharedKey = xyz
AllowedIPs = 10.66.66.1/32, 10.0.0.0/24, 10.10.10.0/24
Endpoint = myGateway:45703
Sehr wahrscheinlich sind auch die PostUP und Down Kommandos überflüssig und auch kontraproduktiv wenn dort gar keine iptables Firewall aktiv ist!
- Des weiteren, je nachdem wie Wireguard auf dem Server eingerichtet wurde fehlen evt. noch die Routen in die Client-Netze am Server
ip route add 192.168.178.0/24 via 10.66.66.2
ip route add 10.10.10.0/24 via 10.66.66.3
- Des weiteren wenn das ein S2S werden soll, müssen die Windows-Clients ebenfalls als Router agieren, auf diesen muss das IP-Forwarding dort ebenfalls aktiviert werden wenn man nicht nur den Wireguard-Client selbst erreichen können will.
- Des weiteren muss auf dem Default-Gateway in den Client-Netzen ebenfalls eine statische Route in das fremde Netz mit dem Wireguard-Client als GW hinterlegt werden (Gilt auch nur wenn man dort andere Clients erreichen können will und nicht nur den Wireguard-Client).
- Des weiteren sollte man ein KeepAlive in der Wireguard-Client-Config setzen (z.B. 25 Sekunden) wenn das ein Site2Site werden soll, denn sonst schließt dein NAT Router den UDP-Session-State nach einem Leerlauf wenn da von einer Seite kein Traffic mehr kommt.
Übrigens, "Bääh" warum machst du mit Winblows-Wireguard-Clients ein Site2Site?? Sowas lässt man sinnvollerweise einen Router/Firewall/Linux-Device im Netz erledigen.
Cheers
certguy
fehlen evt. noch die Routen in die Client-Netze am Server
Nein, das macht Wireguard mit seinem Crypto Routing ganz automatisch und ist nicht erforderlich.Da wo statische Routen erforderlich sind, sind das die jeweils lokalen Router in den Client Netzen. Dort müssen die Zielnetze und das internen WG Netz eingetragen sein mit Next Hop auf die WG Client IP im lokalen Netz. (Siehe Wireguard Tutorial)
Zitat von @aqui:
Stimmt leider nicht ganz. Setze mal mit systemd-networkd den Wireguard Tunnel auf Server-Seite auf und du wirst sehen das das auf der Server-Seite nicht der Fall ist 😉. Ist übrigens bei einer pFSense und dem Wireguard Package genauso, dort muss man zu Zeit die zusätzlichen Routen auch noch von Hand eintragen! Bei systemd-networkd kann man das halt auch leicht mal vergessen.fehlen evt. noch die Routen in die Client-Netze am Server
Nein, das macht Wireguard mit seinem Crypto Routing ganz automatisch und ist nicht erforderlich.Es gibt unterschiedliche Methoden Wireguard aufzusetzen, und nicht bei allen werden die Routen in andere Netze als dem von WG selbst von Geisterhand angelegt, deswegen einfach der Hinweis an den TO das zu prüfen.
Bei wg-quick & co. ja, die nehmen einem das natürlich ab, Prüfen sollte man es aber im Fehlerfall natürlich.
Nur zur Info Windows Blockt ICMP aus anderen Subnetzen per Default in der Firewall, das musst du erst freischalten!
Lies dir unsere Hinweise oben nochmal ganz in Ruhe durch und setze sie korrekt um dann kommt das sofort zum Fliegen! Du hast nur noch nicht alle umgesetzt.
Lies dir unsere Hinweise oben nochmal ganz in Ruhe durch und setze sie korrekt um dann kommt das sofort zum Fliegen! Du hast nur noch nicht alle umgesetzt.
Siehe auch: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Das muss man customizen.
Was sagt denn die Routing Tabelle bei Server und Clients bei aktivem WG Tunnel?
Windows: route print
Linux: ip r
Das muss man customizen.
Was sagt denn die Routing Tabelle bei Server und Clients bei aktivem WG Tunnel?
Windows: route print
Linux: ip r
Tja, da fehlt ja auch wieder die Hälfte und die Subnetzmasken und Subnets sind erneut falsch eingetragen 🙈. Lies dir meinen und aquis Post oben nochmal in Ruhe durch dann siehst du was du vergessen und falsch gemacht hast!!!! Erste Devise richtig und gründlich LESEN, dann VERSTEHEN und erst dann NACHMACHEN!!!
Dir fehlen offensichtlich die einfachsten Routing-Grundlagen, also Dengel dir die erst mal rein dann verstehst du auch warum da keine Antwort kommen kann.
Dir fehlen offensichtlich die einfachsten Routing-Grundlagen, also Dengel dir die erst mal rein dann verstehst du auch warum da keine Antwort kommen kann.
Statische Route im Zielnetz auf dem Default GW angelegt? Forwarding auf dem Windows-Client im Zielnetz aktiviert? Firewall im Ziel customized?
Routingtabelle auf dem Wireguard Server überprüft.
Das alles fehlt hier nämlich in deinen uns präsentierten Daten für dein Setup. Sie sind aber Essentiell für das Funktionieren!
Leider gingst du darauf in keinster Weise ein und das sagt uns entweder hast du es nicht verstanden oder einfach ignoriert. Nur Wireguard einzurichten reicht dazu nämlich nicht.
Deswegen nochmal mein Post dazu oben LESEN.
Routingtabelle auf dem Wireguard Server überprüft.
Das alles fehlt hier nämlich in deinen uns präsentierten Daten für dein Setup. Sie sind aber Essentiell für das Funktionieren!
Leider gingst du darauf in keinster Weise ein und das sagt uns entweder hast du es nicht verstanden oder einfach ignoriert. Nur Wireguard einzurichten reicht dazu nämlich nicht.
Deswegen nochmal mein Post dazu oben LESEN.
was fehlt mir noch bzw. warum kommt nur die Antwort via ping zurück ?
Lass den Zugriff auf die Services auf den Clients aus den fremden Subnetzen in deren Firewall zu. Firewalls wie die von Windows blockieren Zugriffe aus fremden Subnetzen per Default, haben wir oben aber schon x mla geschrieben, das zum Thema unsere Beiträge "gründlich" Lesen.Zitat von @Kollisionskurs:
Ich hab es so langsam verstanden das ich alles GRÜNDLICH durchlesen soll. Die Firewall auf meiner Windows Büchse ist entsprechend konfiguriert bzw. das Zielnetz auch als vertrauenswürdig eingestuft.
Offensichtlich hast du das noch nicht ... denn nicht die Firewall von deinem Rechner, sondern die vom Zielrechner natürlich!!! Au möhr never ending story mit dir hier ...Ich hab es so langsam verstanden das ich alles GRÜNDLICH durchlesen soll. Die Firewall auf meiner Windows Büchse ist entsprechend konfiguriert bzw. das Zielnetz auch als vertrauenswürdig eingestuft.
Beim Kollegen steht jetzt ein frisch aufgesetzter Raspberry mit frisch installiertem Wireguard.
Wie Kollege @3803037559 schon gesagt hat wieder kompletten Schrott konfiguriert. Du musst auch mal lesen und wirklich umsetzen was man dir hier postet! Letzter Versuch...Server:
[Interface]
PrivateKey = ...
Address = 10.66.66.1/24
ListenPort = 45703
[Peer]
PublicKey = ...
AllowedIPs = 10.66.66.2/32, 10.10.10.0/24
PresharedKey = ...
[Peer]
PublicKey = ...
AllowedIPs = 10.66.66.3/32, 192.168.178.0/24
PresharedKey = ...
- Peer 1 (Client A) Allowed IPs sorgt dafür das interner Client A Traffic und Traffic mit Destination IPs fürs lokale Client A Netz in den Tunnel A geroutet wird.
- Peer 2 (Client B) Allowed IPs sorgt dafür das interner Client B Traffic und Traffic mit Destination IPs fürs lokale Client B Netz in den Tunnel B geroutet wird.
Client A:
[Interface]
PrivateKey = ...
Address = 10.66.66.2/24
[Peer]
PublicKey = ...
Endpoint = myGateway:45703
AllowedIPs = 10.66.66.1/32, 192.168.178.0/24, 10.0.0.0/24
PresharedKey = ...
- Peer Allowed IPs sorgt dafür das Traffic mit den dort aufgeführten Destination Netz IPs in den Tunnel A via Server geroutet wird, sprich also Traffic für den Server und die lokalen LANs an Server und Client B.
Client B:
[Interface]
PrivateKey = ...
Address = 10.66.66.3/24
[Peer]
PublicKey = ...
Endpoint = myGateway:45703
AllowedIPs = 10.66.66.1/32, 10.10.10.0/24, 10.0.0.0/24
PresharedKey = ...
- Peer Allowed IPs sorgt dafür das Traffic mit den dort aufgeführten Destination Netz IPs in den Tunnel B via Server geroutet wird, sprich also Traffic für den Server und die lokalen LANs an Server und Client A.
Hoffentliche erkennst du jetzt selber mal welchen Blödsinn du dort in der Server Konfig und der Client B Konfig verzapft hast! 🧐
Client A stimmt ausnahmsweise mal.
Au möhr never ending story mit dir hier ...
Wahre Worte... Tutorial lesen und verstehen hilft wirklich!!