5
Wireguard. Tunnel besteht, aber Daten gehen nicht übers VPN
SERVER: Debian System
Client: Debian System
+SERVER-Config:
Verbindung besteht also
+Client-Config
Besteht also auch Clientseitig.
Ping in alle Richtungen gehen auch. Frage ich nun aber die IP-Adresse ab kommt meine dynamische IPv6 Adresse.
Es müsste aber die 109.+++.+++.38 sein.
Wo kann ich anfangen zu suchen ?
Habt Dank
uname -a
Linux WireGuard 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/LinuxClient: Debian System
Linux debian-1 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux+SERVER-Config:
nano /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
SaveConfig = false
PostUp = ufw route allow in on wg0 out on ens32
PostUp = iptables -t nat -I POSTROUTING -o ens32 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o ens32 -j MASQUERADE
PostUp = iptables -t nat -A PREROUTING -i ens32 -d 109.+++.+++.38 -p tcp --dport 1234 -j DNAT --to-destination 10.8.0.2:1234
PostUp = iptables -A FORWARD -i ens32 -p tcp --dport 8444 -d 10.8.0.2 -j ACCEPT
PreDown = ufw route delete allow in on wg0 out on ens32
PreDown = iptables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
ListenPort = 51820
PrivateKey = 0M+++++Uw=
[Peer]
PublicKey = FP+++++U8=
AllowedIPs = 10.8.0.0/24
wg
interface: wg0
public key: Q/++++BE=
private key: (hidden)
listening port: 51820
peer: FP+++++U8=
endpoint: 84.+++.+++.192:36209
allowed ips: 10.8.0.0/24
latest handshake: 1 minute, 28 seconds ago
transfer: 1.42 KiB received, 656 B sentVerbindung besteht also
+Client-Config
nano /etc/wireguard/wg-client1.conf
[Interface]
# Define the IP address for the client - must be matched with wg0 on Wireguard Server
Address = 10.8.0.2/24
# specific DNS Server
DNS = 1.1.1.1
# Private key for the client - client1.key
PrivateKey = gN+++++Gc=
[Peer]
# Public key of the Wireguard server - server.pub
PublicKey = Q/+++++BE=
# Allow all traffic to be routed via Wireguard VPN
AllowedIPs = 0.0.0.0/0
# Public IP address of the Wireguard Server
Endpoint = 109.+++.+++.38:51820
# Sending Keepalive every 25 sec
PersistentKeepalive = 25
wg
interface: wg-client1
public key: FP+++++U8=
private key: (hidden)
listening port: 36209
fwmark: 0xca6c
peer: Q/Hu+++++BE=
endpoint: 109.+++.+++.38:51820
allowed ips: 0.0.0.0/0
latest handshake: 54 seconds ago
transfer: 308 B received, 1.07 KiB sent
persistent keepalive: every 25 secondsBesteht also auch Clientseitig.
Ping in alle Richtungen gehen auch. Frage ich nun aber die IP-Adresse ab kommt meine dynamische IPv6 Adresse.
Es müsste aber die 109.+++.+++.38 sein.
curl ifconfig.me
2003:d7:xxx:2d00:20c:xxx:fe86:3556route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 ens33
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg-client1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ens33
192.168.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens33Wo kann ich anfangen zu suchen ?
Habt Dank
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 22561362840
Url: https://administrator.de/contentid/22561362840
Printed on: April 27, 2024 at 06:04 o'clock
5 Comments
Latest comment
Nachtrag. Am Server kann es nicht liegen.
Ich habe parallel mal ein neues Debian aufgesetzt (als Spielwiese). Da läuft der VPN sauber. Ich bekomme auch die passende IP zurück.
Nun würde ich aber den VPN gern auf mein Produktiv System nutzen wollen, da hier meine Apps und Daten liegen.
Nur da schlägt es fehl. Ich bin mir weitesgehend sicher, dass es am "alten" Client liegen müsste.
Aber nicht an der Wireguard-Config. Die ist mit der Spielwiese 1:1 identisch.
P.s. Die Spielwiese ist natürlich runtergefahren und hat somit kein WG-contakt.
Es sollte somit am Basissystem liegen und nicht an WG.
Vielleicht hilft ja diese Info (?)
Ich habe parallel mal ein neues Debian aufgesetzt (als Spielwiese). Da läuft der VPN sauber. Ich bekomme auch die passende IP zurück.
Nun würde ich aber den VPN gern auf mein Produktiv System nutzen wollen, da hier meine Apps und Daten liegen.
Nur da schlägt es fehl. Ich bin mir weitesgehend sicher, dass es am "alten" Client liegen müsste.
Aber nicht an der Wireguard-Config. Die ist mit der Spielwiese 1:1 identisch.
P.s. Die Spielwiese ist natürlich runtergefahren und hat somit kein WG-contakt.
Es sollte somit am Basissystem liegen und nicht an WG.
Vielleicht hilft ja diese Info (?)
Normal, weil du in Wireguard keine IPv6 Konfiguration und auch kein IPv6 GW-Redirect für den Client gesetzt hast. IPv6 wird aber eben vom Client bevorzugt genutzt sofern es vom Ziel angeboten wird, deswegen geht es nicht über den Tunnel sondern direkt über deine globale IPv6 raus ... Just simple Routing Basics 
Gib dem Server und Client jeweils eine IPv6 im WG Netz und mach ein IPv6 GW Redirect ::/0 im WG Client. Wenn du kein öffentliches IPv6 Sbunet am vServer hast kannst du am vServer auch ein UniqueLocal Netz im WG Tunnel über die öffentliche IPv6 des vServer NATen.
Gruß Katrin
Gib dem Server und Client jeweils eine IPv6 im WG Netz und mach ein IPv6 GW Redirect ::/0 im WG Client. Wenn du kein öffentliches IPv6 Sbunet am vServer hast kannst du am vServer auch ein UniqueLocal Netz im WG Tunnel über die öffentliche IPv6 des vServer NATen.
Gruß Katrin
ach f**k... ich hab die spielwiese extra genutzt um die befehle mitzuschreiben.
Da hatte ich auch IPv6 deaktiviert weil ich das nicht benötige
somit sollte dein Hinweis die Lösung sein.... mal schauen ^^
Da hatte ich auch IPv6 deaktiviert weil ich das nicht benötige
somit sollte dein Hinweis die Lösung sein.... mal schauen ^^
Zitat von @lord-icon:
ach f**k... ich hab die spielwiese extra genutzt um die befehle mitzuschreiben.
Da hatte ich auch IPv6 deaktiviert weil ich das nicht benötige
somit sollte dein Hinweis die Lösung sein.... mal schauen ^^
ach f**k... ich hab die spielwiese extra genutzt um die befehle mitzuschreiben.
Da hatte ich auch IPv6 deaktiviert weil ich das nicht benötige
somit sollte dein Hinweis die Lösung sein.... mal schauen ^^
Das fehlt aber noch mehr nämlich die gesamte IPv6 Adressierung an Server und Client IPv6 Forward Rule und AllowedIPs ....
Server:
[Interface]
Address = 10.8.0.1/24,fd55:aaaa:bbbb:cccc::1/64
SaveConfig = false
PostUp = ufw route allow in on wg0 out on ens32
PostUp = iptables -t nat -I POSTROUTING -o ens32 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o ens32 -j MASQUERADE
PostUp = ip6tables -A FORWARD -i wg0 -o ens32 -j ACCEPT
PostUp = iptables -t nat -A PREROUTING -i ens32 -d 109.+++.+++.38 -p tcp --dport 1234 -j DNAT --to-destination 10.8.0.2:1234
PostUp = iptables -A FORWARD -i ens32 -p tcp --dport 8444 -d 10.8.0.2 -j ACCEPT
PreDown = ufw route delete allow in on wg0 out on ens32
PreDown = iptables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
ListenPort = 51820
PrivateKey = 0M+++++Uw=
[Peer]
PublicKey = FP+++++U8=
AllowedIPs = 10.8.0.2/32,fd55:aaaa:bbbb:cccc::2/128Client
[Interface]
Address = 10.8.0.2/24,fd55:aaaa:bbbb:cccc::2/64
DNS = 1.1.1.1
PrivateKey = gN+++++Gc=
[Peer]
PublicKey = Q/+++++BE=
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = 109.+++.+++.38:51820
PersistentKeepalive = 25So geht der Client auch mit der IPv6 des vServer ins Netz sofern die Gegenstelle es auch anbietet.
Besser wäre es noch wenn du das öffentliche IPv6 Subnetz per Subnetz-Maske auf WAN und WG Interface aufteilst (kleiner machst, z.B. per 72er Maske) und den Clients dann direkt eine öffentliche IPv6 im WG Netz verpasst, dann würde auch das hässliche IPv6 NAT entfallen
.
Danke Katrin.... wird sicherlich später für einen anderen Hilfesuchenden als Lösung dienen.
Da ich aber IPv6 im internen Netz völlig überflüssig finde möchte ich dieses 2te "Standbein" garnicht.
Auf meiner Spielwiese hatte ich mittels:
erfolgreich deaktiviert
Scheint auch zu greifen. Der Client hat keine IPv6 mehr.
Dann hatte ich wieder curl ifconfig.me getetstet und wieder die IPv6 bekommen.
ABER: Jetzt (für diesen Posting) nochmal diese Abfrage gemacht um passende Outputs posten zu können:
Und jetzt isses die gewünschte IP :wirr
Kann die erste Abfrage vlt. noch das Caching gewesen sein... ??
hmm.... komisch komisch. Ich werde das wohl mal beobachten müssen.
Läuft aber JETZT erstmal. Hab mal wieder Dank Katrin
Da ich aber IPv6 im internen Netz völlig überflüssig finde möchte ich dieses 2te "Standbein" garnicht.
Auf meiner Spielwiese hatte ich mittels:
nano /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1
+ rebooterfolgreich deaktiviert
Scheint auch zu greifen. Der Client hat keine IPv6 mehr.
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:++:++:++:56 brd ff:ff:ff:ff:ff:ff
altname enp2s1
inet 192.168.2.167/24 brd 192.168.2.255 scope global ens33
valid_lft forever preferred_lft forever
3: wg-client1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.8.0.2/24 scope global wg-client1
valid_lft forever preferred_lft foreverDann hatte ich wieder curl ifconfig.me getetstet und wieder die IPv6 bekommen.
ABER: Jetzt (für diesen Posting) nochmal diese Abfrage gemacht um passende Outputs posten zu können:
Und jetzt isses die gewünschte IP :wirr
Kann die erste Abfrage vlt. noch das Caching gewesen sein... ??
hmm.... komisch komisch. Ich werde das wohl mal beobachten müssen.
Läuft aber JETZT erstmal. Hab mal wieder Dank Katrin