21
Wireguard Server (vServer) mit Windows Client
Hallo zusammen,
ich habe einen Wireguard Server nach dieser Anleitung aufgesetzt:
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard ...
Allerdings beschreibt dies einen Wireguard Server UND einen Client auf Ubuntu.
Daher bin ich nicht sicher ob ich das mit den Keys richtig gemacht habe.
Nachdem man auf dem Server einen private und einen public key erstellt hat, soll man irgendwann später auch noch mal auf der Gegenseite (Client) einen private und public Key erstellen.
Da ich keinen Ubuntu Client habe sondern später per Wireguard Installation auf einem Windows Client zugreifen will, habe ich die zweiten Schlüsselpaare auch einfach auf dem Server erstellt.
Wenn der Windows Client den Tunnel aufgebaut hat (Aktiv ist) steht im log aber Handshake not complete und wenn ich meine Öffentliche IP auf dem Laptop checke, ist dies immer noch die meines Heimnetzwerks und nicht die des vServers...
Hier mal meine config:
Wg0.conf:
client.conf für den Wireguard Client:
root@ubuntu:~# wg
root@ubuntu:~# systemctl status wg-quick@wg0.service
root@ubuntu:~# ufw status
root@ubuntu:~# ip route list default
Wobei ich hier nicht verstehe weshalb die erste öffentliche IP in der Ausgabe nur eine 1 hinten hat und die zweite die 171 (wie es auch eigentlich richtig ist)
root@ubuntu:~# sysctl -p
Wireguard Client Log:
Was mache ich falsch oder was habe ich vergessen ??
VG
ich habe einen Wireguard Server nach dieser Anleitung aufgesetzt:
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard ...
Allerdings beschreibt dies einen Wireguard Server UND einen Client auf Ubuntu.
Daher bin ich nicht sicher ob ich das mit den Keys richtig gemacht habe.
Nachdem man auf dem Server einen private und einen public key erstellt hat, soll man irgendwann später auch noch mal auf der Gegenseite (Client) einen private und public Key erstellen.
Da ich keinen Ubuntu Client habe sondern später per Wireguard Installation auf einem Windows Client zugreifen will, habe ich die zweiten Schlüsselpaare auch einfach auf dem Server erstellt.
Wenn der Windows Client den Tunnel aufgebaut hat (Aktiv ist) steht im log aber Handshake not complete und wenn ich meine Öffentliche IP auf dem Laptop checke, ist dies immer noch die meines Heimnetzwerks und nicht die des vServers...
Hier mal meine config:
Wg0.conf:
[Interface]
Address = 10.8.0.1/24
Address = fdfa:653f:ecde::/64
SaveConfig = true
PostUp = ufw route allow in on wg0 out on ens6
PostUp = iptables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on ens6
PreDown = iptables -t nat -D POSTROUTING -o ens6 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o ens6 -j MASQUERADE
ListenPort = 51820
PrivateKey = UPg+weaJdmKvW8b-------------/R7nXZFvbXVGQ=
[Peer]
PublicKey = Y0OSmWs0n4YE-------Tuw2XUBK2zyg=client.conf für den Wireguard Client:
[Interface]
PrivateKey = UPg+weaJdmKvW8b------------/R7nXZFvbXVGQ=
Address = 10.8.0.2/24
Address = fdfa:653f:ecde::2/64
DNS = 212.227.xxx.xx 212.xxx.123.xx 2001:xxx:fe:xx:72ec::1 2001:xxx:fe:xx:72ec::2
[Peer]
PublicKey = Y0OSmWs0n4YE0E------------Tuw2XUBK2zyg=
AllowedIPs = 10.8.0.0/24, fdfa:653f:ecde::/64
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 15root@ubuntu:~# wg
interface: wg0
public key: jiDTd5pAECB5------------2Tymf6uQU=
private key: (hidden)
listening port: 51820
peer: Y0OSmWs0n4Y--------------Tuw2XUBK2zyg=
allowed ips: (none)root@ubuntu:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: active (exited) since Sat 2023-11-11 01:55:06 UTC; 9h ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Main PID: 1455 (code=exited, status=0/SUCCESS)
CPU: 88ms
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] wg setconf wg0 /dev/fd/63
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip -6 address add fdfa:653f:ecde::/64 dev wg0
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip link set mtu 1420 up dev wg0
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ufw route allow in on wg0 out on ens6
Nov 11 01:55:06 ubuntu wg-quick[1489]: Rule added
Nov 11 01:55:06 ubuntu wg-quick[1489]: Rule added (v6)
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] iptables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip6tables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
Nov 11 01:55:06 ubuntu systemd[1]: Finished WireGuard via wg-quick(8) for wg0.root@ubuntu:~# ufw status
Status: active
To Action From
-- ------ ----
51820/udp ALLOW Anywhere
OpenSSH ALLOW Anywhere
51820/udp (v6) ALLOW Anywhere (v6)
OpenSSH (v6) ALLOW Anywhere (v6)
Anywhere on ens6 ALLOW FWD Anywhere on wg0
Anywhere (v6) on ens6 ALLOW FWD Anywhere (v6) on wg0root@ubuntu:~# ip route list default
default via 157.x.x.1 dev ens6 proto dhcp src 157.x.x.171 metric 100root@ubuntu:~# sysctl -p
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1Wireguard Client Log:
2023-11-11 12:25:41.577932: [MGR] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 12:25:41.586190: [MGR] Starting UI process for user ‘USER’ for session 7
2023-11-11 12:45:15.410757: [TUN] [client] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 12:45:15.411635: [TUN] [client] Watching network interfaces
2023-11-11 12:45:15.415485: [TUN] [client] Resolving DNS names
2023-11-11 12:45:15.415485: [TUN] [client] Creating network adapter
2023-11-11 12:45:15.600172: [TUN] [client] Installing driver 0.10
2023-11-11 12:45:15.604030: [TUN] [client] Extracting driver
2023-11-11 12:45:15.607118: [TUN] [client] Installing driver
2023-11-11 12:45:16.172932: [TUN] [client] Creating adapter
2023-11-11 12:45:16.759359: [TUN] [client] Using WireGuardNT/0.10
2023-11-11 12:45:16.759900: [TUN] [client] Enabling firewall rules
2023-11-11 12:45:16.655150: [TUN] [client] Interface created
2023-11-11 12:45:16.768020: [TUN] [client] Dropping privileges
2023-11-11 12:45:16.769304: [TUN] [client] Setting interface configuration
2023-11-11 12:45:16.769814: [TUN] [client] Peer 1 created
2023-11-11 12:45:16.771916: [TUN] [client] Sending keepalive packet to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:16.773785: [TUN] [client] Monitoring MTU of default v6 routes
2023-11-11 12:45:16.771916: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:16.771916: [TUN] [client] Interface up
2023-11-11 12:45:16.786549: [TUN] [client] Setting device v6 addresses
2023-11-11 12:45:16.871987: [TUN] [client] Monitoring MTU of default v4 routes
2023-11-11 12:45:16.873294: [TUN] [client] Setting device v4 addresses
2023-11-11 12:45:16.898521: [TUN] [client] Startup complete
2023-11-11 12:45:21.824826: [TUN] [client] Handshake for peer 1 (157.x.x.171:51820) did not complete after 5 seconds, retrying (try 2)
2023-11-11 12:45:21.824826: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:26.899884: [TUN] [client] Handshake for peer 1 (157.x.x.171:51820) did not complete after 5 seconds, retrying (try 3)
2023-11-11 12:45:26.900137: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:31.978708: [TUN] [client] Handshake for peer 1 (157.x.x.171:51820) did not complete after 5 seconds, retrying (try 4)
2023-11-11 12:45:31.978708: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)Was mache ich falsch oder was habe ich vergessen ??
VG
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: 61941997910
Url: https://administrator.de/contentid/61941997910
Ausgedruckt am: 19.12.2024 um 14:12 Uhr
21 Kommentare
Neuester Kommentar
Allerdings beschreibt dies einen Wireguard Server
Wie immer die üblichen Kardinalsfehler: 
- Überflüssiges und kontraproduktives NAT (Address Translation im Tunnel)
- Falsche Subnetzmasken beim Cryptokey Routing (Allowed IPs) insbesondere die Redirect Maske 0.0.0.0
Nebenbei:
Wenn du bequemer und stressfreier mit bordeigenen VPN Clients arbeiten möchtest ohne die umständliche Frickelei mit externen extra VPN Clients dann guckst du hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Hallo aqui,
guck ich mir gleich mal an.
Was anderes als wireguard kommt da gerade nicht in frage.
Benutze das hinterher auf dem FireTV Stick und dafür brauche ich wireguard
VG
guck ich mir gleich mal an.
Was anderes als wireguard kommt da gerade nicht in frage.
Benutze das hinterher auf dem FireTV Stick und dafür brauche ich wireguard
VG
ok also mit Deiner Anleitung sieht es schon mal besser aus aber auf wieistmeineip bekomme ich immer noch die "falsche Adresse"
Meine neue config:
wg0.conf:
client.conf:
root@ubuntu:~# systemctl status wg-quick@wg0.service
root@ubuntu:~# wg show
root@ubuntu:~# sysctl -p
wireguard log
Was hab ich falsch gemacht?
VG
Meine neue config:
wg0.conf:
[Interface]
Address = 100.64.64.1/24
PrivateKey = WPobDkq7+IEqM--------------u4Xbm2Pg534=
ListenPort = 51820
[Peer]
PublicKey = lAiS+vClXAD--------------N31LD6mRJyiM6ly8=
AllowedIPs = 100.64.64.100/32, 0.0.0.0/24 client.conf:
[Interface]
PrivateKey = +OGBEeMVze---------------MAdTRtHgdpal0=
Address = 100.64.64.1/24
[Peer]
PublicKey = GtMk1AA3-----------------xcHr/qEzBY=
AllowedIPs = 100.64.64.100/32, 0.0.0.0/24
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 15root@ubuntu:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor pre>
Active: active (exited) since Sat 2023-11-11 14:02:44 UTC; 12min ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 558 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCC>
Main PID: 558 (code=exited, status=0/SUCCESS)
CPU: 24ms
Nov 11 14:02:43 ubuntu systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip link add wg0 type wireguard
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] wg setconf wg0 /dev/fd/63
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip -4 address add 100.64.64.1/24 dev >
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip link set mtu 1420 up dev wg0
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip -4 route add 0.0.0.0/24 dev wg0
Nov 11 14:02:44 ubuntu systemd[1]: Finished WireGuard via wg-quick(8) for wg0.root@ubuntu:~# wg show
interface: wg0
public key: GtMk1AA3T-----------------xJWxcHr/qEzBY=
private key: (hidden)
listening port: 51820
peer: lAiS+vClXADSsOA--------------------LD6mRJyiM6ly8=
endpoint: 87.x.x.x:59681
allowed ips: 100.64.64.100/32, 0.0.0.0/24
latest handshake: 5 minutes, 18 seconds ago
transfer: 796 B received, 276 B sentroot@ubuntu:~# sysctl -p
net.ipv4.ip_forward = 1wireguard log
2023-11-11 15:11:17.040204: [MGR] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:17.048988: [MGR] Starting UI process for user ‘USER’ for session 1
2023-11-11 15:11:25.828014: [TUN] [client] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:25.828014: [TUN] [client] Watching network interfaces
2023-11-11 15:11:25.830700: [TUN] [client] Resolving DNS names
2023-11-11 15:11:25.831254: [TUN] [client] Creating network adapter
2023-11-11 15:11:25.927675: [TUN] [client] Using existing driver 0.10
2023-11-11 15:11:25.936986: [TUN] [client] Creating adapter
2023-11-11 15:11:26.235951: [TUN] [client] Using WireGuardNT/0.10
2023-11-11 15:11:26.235951: [TUN] [client] Enabling firewall rules
2023-11-11 15:11:26.182525: [TUN] [client] Interface created
2023-11-11 15:11:26.242425: [TUN] [client] Dropping privileges
2023-11-11 15:11:26.242934: [TUN] [client] Setting interface configuration
2023-11-11 15:11:26.243629: [TUN] [client] Peer 1 created
2023-11-11 15:11:26.245212: [TUN] [client] Monitoring MTU of default v4 routes
2023-11-11 15:11:26.244681: [TUN] [client] Sending keepalive packet to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Interface up
2023-11-11 15:11:26.271515: [TUN] [client] Receiving handshake response from peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.271515: [TUN] [client] Keypair 1 created for peer 1
2023-11-11 15:11:26.271515: [TUN] [client] Setting device v4 addresses
2023-11-11 15:11:26.301183: [TUN] [client] Monitoring MTU of default v6 routes
2023-11-11 15:11:26.302199: [TUN] [client] Setting device v6 addresses
2023-11-11 15:11:26.323717: [TUN] [client] Startup completeWas hab ich falsch gemacht?
VG
Hallo,
0.0.0.0/24 ist nicht das ganze Internet. Richtig wäre hier: 0.0.0.0/0
LG
0.0.0.0/24 ist nicht das ganze Internet. Richtig wäre hier: 0.0.0.0/0
LG
1Hab ich geändert, jetzt erreiche ich den Server nicht mehr....
Also gar nicht mehr, öffentliche IP lässt sich nicht mehr anpingen, putty logischerweise auch nicht mehr...
...was dann auf ein falsches Routing am Tunnelendpunkt schliessen lässt. Pathping oder Traceroute sind, wie immer, deine besten Freunde.
Posten des aktuellen Client und Server Setups würde auch helfen.
Pathping oder Traceroute sind, wie immer, deine besten Freunde.Posten des aktuellen Client und Server Setups würde auch helfen.
Hab ich doch:
Wireguard Server (vServer) mit Windows Client
Oder fehlt da noch was ?
Zitat von @aqui:
...was dann auf ein falsches Routing am Tunnelendpunkt schliessen lässt. Pathping oder Traceroute sind, wie immer, deine besten Freunde.
Naja da das ja ein vServer ist an den ich nur per putty komme werde ich den wohl neu installieren müssen, richtig ?...was dann auf ein falsches Routing am Tunnelendpunkt schliessen lässt.
Pathping oder Traceroute sind, wie immer, deine besten Freunde.VG
Nöö, kann man ja alles auch mit PuTTY und SSH machen. ip r zeigt dir die Routing Tabelle.
Wenn du von da ins Internet willst musst du den WG Tunneltraffic dann natürlich masqueraden, denn RFC 1918 IPs wie dein internes 10.8er Netz sind bekanntlich nicht routebar im Internet.
Da wäre dann die Firewall Konfig hilfreich bzw. deine /etc/nftables.conf.
Hier ist dann ein ip saddr 10.8.0.0/24 oif eth0 masquerade in der Chain "postrouting" zwingend. Guckst du auch hier.
Wenn du von da ins Internet willst musst du den WG Tunneltraffic dann natürlich masqueraden, denn RFC 1918 IPs wie dein internes 10.8er Netz sind bekanntlich nicht routebar im Internet.
Da wäre dann die Firewall Konfig hilfreich bzw. deine /etc/nftables.conf.
Hier ist dann ein ip saddr 10.8.0.0/24 oif eth0 masquerade in der Chain "postrouting" zwingend. Guckst du auch hier.
Zitat von @aqui:
Nöö, kann man ja alles auch mit PuTTY und SSH machen. ip r zeigt dir die Routing Tabelle.
Nöö, kann man ja alles auch mit PuTTY und SSH machen. ip r zeigt dir die Routing Tabelle.
Wie gesagt das ist das Problem, komme nicht mehr ran 😅
Hab das so geändert wie hier beschrieben:
Jetzt kann man die öffentliche IP nicht mehr pingen und ich komme auch mit putty nicht mehr dran 🤷♂️
Egal, setze den neu auf und schaue mal ob ich dann mit den nftables weiter komme…
…
0.0.0.0/0 = an Client in die allowedIPs eintragen
0.0.0.0/0 = an Client in die allowedIPs eintragen
das ist das Problem, komme nicht mehr ran
Oha, dann hast du aber erstmal ein ganz anderes Problem...! ☹️Da hilft dann in der Tat nur alles auf Anfang.
Oder beim Hoster schauen. Vor allem an virtuelle Server kommt man oft auch direkt über eine Konsole im Web. Du brauchst halt einen Nutzer, der sich mit PW anmelden darf, also ohne SSH Schlüssel.
1Zitat von @asp.net.core:
Oder beim Hoster schauen. Vor allem an virtuelle Server kommt man oft auch direkt über eine Konsole im Web. Du brauchst halt einen Nutzer, der sich mit PW anmelden darf, also ohne SSH Schlüssel.
Oder beim Hoster schauen. Vor allem an virtuelle Server kommt man oft auch direkt über eine Konsole im Web. Du brauchst halt einen Nutzer, der sich mit PW anmelden darf, also ohne SSH Schlüssel.
Stimmt, allerdings zu spät gesehen, da hatte ich schon neu installiert.
Ich bin jetzt quasi wieder an diesem Punkt hier bekomme aber jetzt bei aktiver Verbindung keine Internetverbindung mehr...
Meine neue config:
wg0.conf:
[Interface]
Address = 100.64.64.1/24
PrivateKey = QDpsUBDpk------------------SD19CgF2hkc=
ListenPort = 51820
[Peer]
PublicKey = x4LyrRAquJ---------------------lbRjh+DNfnqhU=
AllowedIPs = 100.64.64.100/32, 192.168.40.0/24, 192.168.178.0/24client.conf:
[Interface]
PrivateKey = QOIuIQTtfaz53-----------------tdbdr1+H/QGU=
Address = 100.64.64.1/24
[Peer]
PublicKey = pCqtnC0AXLvrl---------------DRCPFpnerDcO0A=
AllowedIPs = 100.64.64.100/32, 192.168.40.0/24, 192.168.178.0/24
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 15root@ubuntu:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor pre>
Active: active (exited) since Sat 2023-11-11 14:02:44 UTC; 12min ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 558 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCC>
Main PID: 558 (code=exited, status=0/SUCCESS)
CPU: 24ms
Nov 11 14:02:43 ubuntu systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip link add wg0 type wireguard
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] wg setconf wg0 /dev/fd/63
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip -4 address add 100.64.64.1/24 dev >
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip link set mtu 1420 up dev wg0
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip -4 route add 0.0.0.0/24 dev wg0
Nov 11 14:02:44 ubuntu systemd[1]: Finished WireGuard via wg-quick(8) for wg0.root@ubuntu:~# wg show
interface: wg0
public key: pCqtnC0A----------1oIKDRCPFpnerDcO0A=
private key: (hidden)
listening port: 51820
peer: x4LyrRAquJXjRB+---------j3lbRjh+DNfnqhU=
endpoint: 79.x.x.x:64093
allowed ips: 100.64.64.100/32, 192.168.40.0/24, 192.168.178.0/24
latest handshake: 7 minutes, 5 seconds ago
transfer: 360 B received, 408 B sentroot@ubuntu:~# sysctl -p
net.ipv4.ip_forward = 1wireguard log
2023-11-11 15:11:17.040204: [MGR] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:17.048988: [MGR] Starting UI process for user ‘USER’ for session 1
2023-11-11 15:11:25.828014: [TUN] [client] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:25.828014: [TUN] [client] Watching network interfaces
2023-11-11 15:11:25.830700: [TUN] [client] Resolving DNS names
2023-11-11 15:11:25.831254: [TUN] [client] Creating network adapter
2023-11-11 15:11:25.927675: [TUN] [client] Using existing driver 0.10
2023-11-11 15:11:25.936986: [TUN] [client] Creating adapter
2023-11-11 15:11:26.235951: [TUN] [client] Using WireGuardNT/0.10
2023-11-11 15:11:26.235951: [TUN] [client] Enabling firewall rules
2023-11-11 15:11:26.182525: [TUN] [client] Interface created
2023-11-11 15:11:26.242425: [TUN] [client] Dropping privileges
2023-11-11 15:11:26.242934: [TUN] [client] Setting interface configuration
2023-11-11 15:11:26.243629: [TUN] [client] Peer 1 created
2023-11-11 15:11:26.245212: [TUN] [client] Monitoring MTU of default v4 routes
2023-11-11 15:11:26.244681: [TUN] [client] Sending keepalive packet to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Interface up
2023-11-11 15:11:26.271515: [TUN] [client] Receiving handshake response from peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.271515: [TUN] [client] Keypair 1 created for peer 1
2023-11-11 15:11:26.271515: [TUN] [client] Setting device v4 addresses
2023-11-11 15:11:26.301183: [TUN] [client] Monitoring MTU of default v6 routes
2023-11-11 15:11:26.302199: [TUN] [client] Setting device v6 addresses
2023-11-11 15:11:26.323717: [TUN] [client] Startup completenftables
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
}
table ip nat {
define VPN_NETS = {
192.168.178.0/24
}
# fuer VPN Client Pakete ins Internet masquerade ausser VPN Netzwerke
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname ens6 ip daddr $VPN_NETS accept
ip saddr 100.64.64.0/24 oif ens6 masquerade
}
} root@ubuntu:~# ip r
default via 157.97.109.1 dev ens6 proto dhcp src 157.x.x.x metric 100
100.64.64.0/24 dev wg0 proto kernel scope link src 100.64.64.1
157.x.x.1 dev ens6 proto dhcp scope link src 157.x.x.x metric 100
192.168.40.0/24 dev wg0 scope link
192.168.178.0/24 dev wg0 scope link
212.227.123.16 via 157.x.x.1 dev ens6 proto dhcp src 157.x.x.x metric 100
212.227.123.17 via 157.x.x.1 dev ens6 proto dhcp src 157.x.x.x metric 100
Irgendwas fehlt mir auf jeden fall noch...
VG
Einen groben Kardianalsfehler hast du begangen, denn du hast dem Server und dem Client die gleiche lokale IP Adresse 100.64.64.1/24 gegeben!!
Mal ehrlich wenn es an solchen Banalitäten die jeder Azubi im ersten Lehrjahr scheitert muss man sich nicht wundern. Doppelte IP Adressen sind ein NoGo im TCP/IP!
Halte dich an das Tutorial das empfhielt dem Server die höchste IP zu geben (bei einem 24er Prefix die .254) und die Clients ab .1 oder auch .101 usw. durchzunummerieren. So vermeidet man solche groben Anfänger Fauxpas'.
Server also:
Erster Client dazu:
Den Keepalive sollte man nicht unnötigerweise hochsetzen weil die UDP Sessiontimeouts in NAT Routern oder Firewall selten unter 30 liegen!
Wenn du über den Tunnel ins Internet willst musst du aber eine Gateway Redirect Verbindung aufsetzen, die ALLES in den Tunnel routet.
Diese Thematik ist HIER genau beschrieben. Lesen und verstehen... 😉
Folglich sind deine Todos für einen Redirect:
Deine nftables Rules sind soweit korrekt. Ein nft list ruleset zeigt die Aktivität der Firewall
Vorsichtig solltest du mit der Nutzung der RFC 6598 Adressen (100.64.0.0 /10) sein fürs interne Netz.
Das geht nur wenn du keine DS-Lite Anschlüsse hast und Provider diesen Shared Adress Space NICHT nutzen mit deinem VPN Setup.
Wenn du da auf Nummer sicher gehen willst nutzt du dann besser RFC 1918 IP Netze mit einer sicheren VPN Adresse.
Mal ehrlich wenn es an solchen Banalitäten die jeder Azubi im ersten Lehrjahr scheitert muss man sich nicht wundern. Doppelte IP Adressen sind ein NoGo im TCP/IP!
Halte dich an das Tutorial das empfhielt dem Server die höchste IP zu geben (bei einem 24er Prefix die .254) und die Clients ab .1 oder auch .101 usw. durchzunummerieren. So vermeidet man solche groben Anfänger Fauxpas'.
Server also:
[Interface]
Address = 100.64.64.254/24
PrivateKey = QDpsUBDpk
ListenPort = 51820
[Peer]
PublicKey = x4LyrRAquJ
AllowedIPs = 100.64.64.101/32 [Interface]
PrivateKey = QOIuIQTtfaz53
Address = 100.64.64.101/24
[Peer]
PublicKey = pCqtnC0AXLvrl
AllowedIPs = 100.64.64.254/32
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 25 hier bekomme aber jetzt bei aktiver Verbindung keine Internetverbindung mehr...
Was ja auch verständlich ist, denn das Setup oben ist eine klassische "Split Tunneling" VPN Verbindung die einzig und allein nur das in den VPN Tunnel routet was in die 3 remoten Netze soll.Wenn du über den Tunnel ins Internet willst musst du aber eine Gateway Redirect Verbindung aufsetzen, die ALLES in den Tunnel routet.
Diese Thematik ist HIER genau beschrieben. Lesen und verstehen... 😉
Folglich sind deine Todos für einen Redirect:
- AllowedIP Parameter anpassen
- DNS Server muss einer sein der über den Tunnel erreichbar ist. Ggf. IP Connectivity Check nur mit nackter IP um DNS Probleme temorär auszuschliessen. Ein nslookup muss Adressen auflösen können!
- Traffic aus dem internen WG IP Netz den die Clients nutzen muss am WG Server masqueraded (NAT per nftables etc.) werden da RFC 1918 IPs NICHT geroutet werden.
Deine nftables Rules sind soweit korrekt. Ein nft list ruleset zeigt die Aktivität der Firewall
Vorsichtig solltest du mit der Nutzung der RFC 6598 Adressen (100.64.0.0 /10) sein fürs interne Netz.
Das geht nur wenn du keine DS-Lite Anschlüsse hast und Provider diesen Shared Adress Space NICHT nutzen mit deinem VPN Setup.
Wenn du da auf Nummer sicher gehen willst nutzt du dann besser RFC 1918 IP Netze mit einer sicheren VPN Adresse.
Also aktuell steh ich echt absolut auf dem Schlauch, Du könntest mir das genauso gut gerade auf chinesisch erklären....
Die Internetverbindung klappt zumindest schon mal wieder wenn ich verbunden bin...
Aber dennoch ist meine öffentliche Adresse am Client weiterhin die des Client-Netzes, nicht die des vServers
Ok das mit den doppelten IP-Adressen ist natürlich doof gelaufen ^^
Sieht jetzt aber so aus
Win-CLIENT
Server config:
Folglich sind deine Todos für einen Redirect:
Wie gesagt auf 0.0.0.0/0 klappt bei mir nicht...
Absolut am verzweifeln hier 😵💫😫😫
Die Internetverbindung klappt zumindest schon mal wieder wenn ich verbunden bin...
Aber dennoch ist meine öffentliche Adresse am Client weiterhin die des Client-Netzes, nicht die des vServers
Ok das mit den doppelten IP-Adressen ist natürlich doof gelaufen ^^
Sieht jetzt aber so aus
Win-CLIENT
[Interface]
PrivateKey = QOIuIQTtfaz53yf-------------1+H/QGU=
Address = 100.64.64.101/24
DNS = 192.168.188.1
[Peer]
PublicKey = pCqtnC0A-----------pnerDcO0A=
AllowedIPs = 100.64.64.254/32
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 25Server config:
[Interface]
Address = 100.64.64.254/24
PrivateKey = QDpsUBDpk8---------------19CgF2hkc=
ListenPort = 51820
[Peer]
PublicKey = x4LyrRAquJ------------------Rjh+DNfnqhU=
AllowedIPs = 100.64.64.101/32Wenn du über den Tunnel ins Internet willst musst du aber eine Gateway Redirect Verbindung aufsetzen, die ALLES in den Tunnel routet.
Diese Thematik ist HIER genau beschrieben. Lesen und verstehen... 😉
Wenn ich auf das 0.0.0.0/0 ändere schließe ich mich immer selbst aus und muss das über die Konsole wieder ändern...Diese Thematik ist HIER genau beschrieben. Lesen und verstehen... 😉
Folglich sind deine Todos für einen Redirect:
- AllowedIP Parameter anpassen
* DNS Server muss einer sein der über den Tunnel erreichbar ist. Ggf. IP Connectivity Check nur mit nackter IP um DNS Probleme temorär auszuschliessen. Ein nslookup muss Adressen auflösen können!
Geändert auf 192.168.188.1, ist die Fritte vom Client, keine Ahnung ob das richtig ist....* Traffic aus dem internen WG IP Netz den die Clients nutzen muss am WG Server masqueraded (NAT per nftables etc.) werden da RFC 1918 IPs NICHT geroutet werden.
Äh ja... Gar keine Ahnung was ich da jetzt wo machen muss :/Deine nftables Rules sind soweit korrekt. Ein nft list ruleset zeigt die Aktivität der Firewall
root@ubuntu:~# nft list rulesettable inet filter {
chain input {
type filter hook input priority filter; policy accept;
}
chain forward {
type filter hook forward priority filter; policy accept;
}
chain output {
type filter hook output priority filter; policy accept;
}
}
table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifname "ens6" ip daddr 192.168.188.0/24 accept
ip saddr 100.64.64.0/24 oif "ens6" masquerade
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname "ens6" counter packets 43 bytes 12348 masquerade
}
}
table ip filter {
chain FORWARD {
type filter hook forward priority filter; policy accept;
iifname "ens6" oifname "wg0" counter packets 0 bytes 0 accept
iifname "wg0" counter packets 37 bytes 17108 accept
}
}
table ip6 filter {
chain FORWARD {
type filter hook forward priority filter; policy accept;
iifname "wg0" counter packets 0 bytes 0 accept
}
}
table ip6 nat {
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname "ens6" counter packets 18 bytes 2416 masquerade
}
}Vorsichtig solltest du mit der Nutzung der RFC 6598 Adressen (100.64.0.0 /10) sein fürs interne Netz.
Das geht nur wenn du keine DS-Lite Anschlüsse hast und Provider diesen Shared Adress Space NICHT nutzen mit deinem VPN Setup.
Wenn du da auf Nummer sicher gehen willst nutzt du dann besser RFC 1918 IP Netze mit einer sicheren VPN Adresse.
Also die Testumgebung ist kein DSLite Anschluss aber generell werde ich das dann ändernDas geht nur wenn du keine DS-Lite Anschlüsse hast und Provider diesen Shared Adress Space NICHT nutzen mit deinem VPN Setup.
Wenn du da auf Nummer sicher gehen willst nutzt du dann besser RFC 1918 IP Netze mit einer sicheren VPN Adresse.
Absolut am verzweifeln hier 😵💫😫😫
Also aktuell steh ich echt absolut auf dem Schlauch
Wie ist das möglich, denn die doppelte IP Vergabe der Server und Client IP im internen VPN Netz ist ja eindeutig falsch. Um das zu erkennen muss man kein Chinesisch können....1Zitat von @aqui:
Also aktuell steh ich echt absolut auf dem Schlauch
Wie ist das möglich, denn die doppelte IP Vergabe der Server und Client IP im internen VPN Netz ist ja eindeutig falsch. Um das zu erkennen muss man kein Chinesisch können....Das meinte ich auch nicht sondern das ich immer noch nicht dahin komme wo ich hin will ^^
Mit den doppelten IP-Adressen ist klar und das habe ich natürlich behoben.
Aber wie gesagt, ins Internet komme ich jetzt mit verbundenem Tunnel aber wenn ich auf wieistmeineip.de gehe bekomme ich immer noch nicht die IP meines vServers zu sehen....
wenn ich auf wieistmeineip.de gehe bekomme ich immer noch nicht die IP meines vServers zu sehen....
Weil deine DNS Konfig in einem Redirect Setup Blödsinn ist! Das doppelte Adressproblem hast du aber zumindestens nun korrigiert. Das o.a. Beispiel war aber reduziert auf eine reine Client Server Kommunikation um die Adressierungsproblematik der doppelten IP aufzuzeigen.
Eine Redirect Konfig sähe dann für den Client so aus:
[Interface]
PrivateKey = QOIuIQTtfaz53yf
Address = 100.64.64.101/24
DNS = 192.168.188.1
[Peer]
PublicKey = pCqtnC0A
AllowedIPs = 0.0.0.0/0
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 25 ⚠️ Wichtig ist das der Server eine Default Route auf den Internet Router hat und der Internet Router eine statisch IP Route auf das 100.64.64.0er Netz mit Next Hop auf die lokale WG Server IP.
Das o.a. gilt natürlich nur wenn der Server im eigenen Heimnetz liegt.
Sofern der WG Server ein vServer mit öffentlicher IP ist entfällt das natürlich, denn ein gehosteter vServer hat ja schon ein Bein direkt im Internet und fungiert ja selber dann schon als Router.
Ist er ein vServer, dann darf aber der Client logischerweise niemals die DNS Adresse auf die o.a. gesetzt haben. Klar, denn bei einem Redirect landen DNS Anfragen dann bei 192.168.188.1 und werden durch die Redirect Konfig zwangsweise immer in den Tunnel geroutet, wo natürlich keine RFC1918 IP Netze sind.
Ein vServer kann deshalb unroutebare RFC1918 IPs niemals erreichen und somit landet dann jede DNS Anfrage im Nirwana.
Wenn, dann muss als DNS Server in der Client Konfig hier zwingend die DNS IP Adressen des vServer Hosters stehen!! Welche das sind erfährt man immer auf den Info Seiten seines vServer Hosters. Alternativ geht zur Not eine Allgemeine die aus Datenschutz Sicht unbedenktlich ist wie z.B. 9.9.9.9.
Nun solltest du eigentlich davon genug Ahnung haben um dir die Frage ob das obige DNS Setup richtig oder ob das völliger Unsinn ist, ganz sicher selbst beantworten zu können.
Bei aktivem VPN Client sollte ein nslookup www.administrator.de immer eine korrekte Antwort ergeben wenn es richtig konfiguriert wurde.
Ob das IP Routing ins Internet über den Redirect sauber funktioniert kann man immer mit Traceroute und einer nackten Internet Ziel IP checken. IP Adresse weil dies DNS Fehler erstmal außen vor lässt.
Bei Winblows ist das das tracert Kommando. Sprich ein tracert 8.8.8.8 sollte dann den kompletten Pfad zum Ziel über den VPN Tunnel zeigen.
Surft man bei aktivem VPN Tunnel z.B. zu http://myexternalip.com dann sollte als Internet IP die WAN Port IP des vServers angezeigt werden über die ja jeglicher VPN Traffic dann ins Internet geht via NAT/Masquerading.
Soviel zur simplen Theorie die de facto keinerlei Fremdsprachen erfordert...
Noch ein wichtiger Security Tip...
Du solltest die Input und Prerouting Chain der nftables Firewall noch etwas dichter machen, denn im Moment erlaubt deine einfache Konfig allen möglichen Angreifern den Zugriff.
Über failtoban solltest du bei einem öffentlichen vServer auch nachdenken.
Aber bitte erst nachdem alles andere sauber funktioniert!!
#!/usr/sbin/nft -f
flush ruleset
# Interface name
define pub_iface = "en123"
# Wireguard port
define wg_port = 51820
table inet drop-bad-ct-states {
chain prerouting {
type filter hook prerouting priority -150; policy accept;
# Drop packets in "invalid" connection-tracking state
ct state invalid drop
# Drop tcp packets for new connections that aren't syn packets
tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
# Drop XMAS packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
# Drop NULL packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
# Drop new connections over rate limit
ct state new limit rate over 1/second burst 20 packets drop
}
}
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Akzeptiert localhost traffic
iif lo accept
# Akzeptiert Wireguard tunnel traffic
iifname "wg0" accept
# Akzeptiert traffic vom eigenen Server
ct state established,related accept
# Akzeptiert ICMP types
ip protocol icmp icmp type { time-exceeded, parameter-problem, destination-unreachable } accept
# Akzeptiert lokale TCP Dienste
iif $pub_iface tcp dport { ssh, https } ct state new accept
# Akzeptiert UDP Traffic
iif $pub_iface udp dport { $wg_port } accept
# Akzeptiert Neighbour discovery otherwise IPv6 connectivity breaks.
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
# log and count dropped traffic
# log prefix "[nftables]Denied: " counter drop
# only count dropped traffic
counter drop
}
Ok jetzt klappt es 
Kann ich das so übernehmen wie Du das gepostet hast oder muss ich da noch was anpassen ?
Eine Kleinigkeit ist mir aber noch aufgefallen.
Wenn ich das richtig verstanden habe, geht ja jetzt der gesamte Verkehr des Clients durch den Tunnel was zur Folge hat, wenn der Tunnel aktiv ist, bricht meine putty Verbindung ab.
Im Grunde könnte ich damit leben weil ich eigentlich nicht beides gleichzeitig brauche, aber würde es eine schnelle Lösung dafür geben ?
VG
Achso, mit dem failtoban guck ich mir auf jeden Fall auch noch an!
Wie immer vielen Dank für Deine kompetente Hilfe und Deine Geduld :D
Noch ein wichtiger Security Tip...
Du solltest die Input und Prerouting Chain der nftables Firewall noch etwas dichter machen, denn im Moment erlaubt deine einfache Konfig allen möglichen Angreifern den Zugriff.
Du solltest die Input und Prerouting Chain der nftables Firewall noch etwas dichter machen, denn im Moment erlaubt deine einfache Konfig allen möglichen Angreifern den Zugriff.
Kann ich das so übernehmen wie Du das gepostet hast oder muss ich da noch was anpassen ?
Eine Kleinigkeit ist mir aber noch aufgefallen.
Wenn ich das richtig verstanden habe, geht ja jetzt der gesamte Verkehr des Clients durch den Tunnel was zur Folge hat, wenn der Tunnel aktiv ist, bricht meine putty Verbindung ab.
Im Grunde könnte ich damit leben weil ich eigentlich nicht beides gleichzeitig brauche, aber würde es eine schnelle Lösung dafür geben ?
VG
Achso, mit dem failtoban guck ich mir auf jeden Fall auch noch an!
Wie immer vielen Dank für Deine kompetente Hilfe und Deine Geduld :D
geht ja jetzt der gesamte Verkehr des Clients durch den Tunnel
Das hast du richtig verstanden. Mit "AllowedIPs 0.0.0.0/0" betreibst du ja eine Gateway Redirect Konfig, sprich dein Default Gateway am Client wird komplett auf den VPN Tunnel umgebogen so das sämtlicher, nicht lokaler Traffic in den VPN Tunnel geroutet wird.wenn der Tunnel aktiv ist, bricht meine putty Verbindung ab.
Nicht wenn du sie dann mit der internen WG IP Adresse des Servers aufbaust. Kann ich das so übernehmen
Ja kannst du. Beachte allerdings das es nur der Part mit der Input und Prerouting Chain ist. Den unterne Part mit NAT usw. musst du aus deiner bestehenden Konfig übernehmen.Die Variablen oben des pub_iface und wg_port musst du natürlich auf deine aktuell verwendeten Namen bzw. Ports anpassen.
Falls erforderlich kann ich dir aber nochmal die vollständige nftables.conf posten.
