ubuntuusers.de

Danke dir! Die Änderungen geben ein neues Fehlerbild. Die externe IP der VM ist meine normale Telekom-IP. Das wg0 Interface hat laut ubuntu die IP des VPN Providers (10.2.0.2). Vom Gerät mit der IP .55 kann ich alle möglichen externen IPs anpingen (z.B. 8.8.8.8), jedoch nicht die des VPN Providers (also zB 10.2.0.1) und keine URLs auflösen. Laut tcpdump gehen die Anfragen des .55 Geräts aber durch die wg0 der VM.

curl ifconfig.me
91.*.*.*

4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.2.0.2/32 scope global wg0
       valid_lft forever preferred_lft forever

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=118 time=10.649 ms
64 bytes from 8.8.8.8: seq=1 ttl=118 time=10.716 ms
64 bytes from 8.8.8.8: seq=2 ttl=118 time=10.456 ms

PING 10.2.0.1 (10.2.0.1): 56 data bytes
^C
--- 10.2.0.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

ping web.de
^C

cpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:14:23.321325 00:1d:ec:0f:e2:64 > 52:54:00:cb:f3:b0, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 52126, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.178.55 > 8.8.8.8: ICMP echo request, id 54035, seq 0, length 64
13:14:23.321361 52:54:00:cb:f3:b0 > dc:39:6f:cf:ba:1e, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 52126, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.178.55 > 8.8.8.8: ICMP echo request, id 54035, seq 0, length 64

tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
13:14:23.321348 ip: (tos 0xc0, ttl 64, id 56465, offset 0, flags [none], proto ICMP (1), length 112)
    10.2.0.2 > 192.168.178.55: ICMP redirect 8.8.8.8 to host 192.168.178.1, length 92
        (tos 0x0, ttl 63, id 52126, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.178.55 > 8.8.8.8: ICMP echo request, id 54035, seq 0, length 64
13:14:24.321569 ip: (tos 0xc0, ttl 64, id 56668, offset 0, flags [none], proto ICMP (1), length 112)
    10.2.0.2 > 192.168.178.55: ICMP redirect 8.8.8.8 to host 192.168.178.1, length 92
        (tos 0x0, ttl 63, id 52179, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.178.55 > 8.8.8.8: ICMP echo request, id 54035, seq 1, length 64

Koko80 schrieb:

Die Änderungen geben ein neues Fehlerbild. Die externe IP der VM ist meine normale Telekom-IP.

Ja, durch die Änderung der "AllowedIPs" wird im 192.168.178.112, nicht mehr das wg0 das device der default route sein, sondern das Lan-Interface (an der FB). Poste jetzt vom 192.168.178.112, die Ausgaben von:

route -n
ip -4 r

Evtl. kannst Du dort jetzt manuell eine default route via wg0 (10.2.0.1) mit einer besseren metric, konfigurieren, damit diese benutzt wird.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 enp1s0
10.2.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 enp1s0
192.168.178.55  0.0.0.0         255.255.255.255 UH    0      0        0 wg0
192.168.178.112 0.0.0.0         255.255.255.255 UH    0      0        0 wg0

default via 192.168.178.1 dev enp1s0 proto static 
10.2.0.1 dev wg0 scope link 
192.168.178.0/24 dev enp1s0 proto kernel scope link src 192.168.178.112 
192.168.178.55 dev wg0 scope link 
192.168.178.112 dev wg0 scope link 

Koko80 schrieb:

default via 192.168.178.1 dev enp1s0 proto static 
10.2.0.1 dev wg0 scope link 
192.168.178.0/24 dev enp1s0 proto kernel scope link src 192.168.178.112 
192.168.178.55 dev wg0 scope link 
192.168.178.112 dev wg0 scope link 

OK, dann konfiguriere zusätzlich und manuell (auf dem WG-Client/VPN-Gateway mit der IP .112):

sudo ip route add 194.126.177.8/32 via 192.168.178.1 dev enp1s0
sudo ip route add default via 10.2.0.2 dev wg0
sudo ip route del default via 192.168.178.1 dev enp1s0

und danach testen:

ip -4 r
ip -4 r g 1.1.1.1
ping -c 3 9.9.9.9

Hast Du in deiner FritzBox die statische Route konfiguriert (siehe oben)?

Ja, in der FritzBox ist die statische ipv4 route angelegt.

Mit den neuen Routen ist keine Verbindung mehr möglich, entsprechend schlagen die ip-Befehle fehl. Die Wireguard-Verbindung scheint aber noch zu stehen

10.2.0.1 dev wg0 scope link 
192.168.178.0/24 dev enp1s0 proto kernel scope link src 192.168.178.112 
192.168.178.55 dev wg0 scope link 
192.168.178.112 dev wg0 scope link 
194.126.177.8 via 192.168.178.1 dev enp1s0 

ip -4 r g 1.1.1.1
RTNETLINK answers: Network is unreachable

ping -c 3 9.9.9.9
ping: connect: Network is unreachable

interface: wg0
  public key: KEY
  private key: (hidden)
  listening port: 46958

peer: KEY
  endpoint: 194.126.177.8:51820
  allowed ips: 10.2.0.1/32, 192.168.178.55/32, 192.168.178.112/32
  latest handshake: 8 seconds ago
  transfer: 230.76 KiB received, 631.69 KiB sent

Koko80 schrieb:

10.2.0.1 dev wg0 scope link 
192.168.178.0/24 dev enp1s0 proto kernel scope link src 192.168.178.112 
192.168.178.55 dev wg0 scope link 
192.168.178.112 dev wg0 scope link 
194.126.177.8 via 192.168.178.1 dev enp1s0 

Es gibt keine default route. Hast Du:

sudo ip route add default via 10.2.0.2 dev wg0

eingegeben?

ahja, richtig. Ja, hatte ich gemacht - hat er wohl verschluckt.

ip -4 r g 1.1.1.1
1.1.1.1 dev wg0 src 10.2.0.2 uid 1000 
    cache 

PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
From 10.2.0.2 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Required key not available
From 10.2.0.2 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Required key not available
From 10.2.0.2 icmp_seq=3 Destination Host Unreachable
ping: sendmsg: Required key not available
^C
--- 9.9.9.9 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2030m

Koko80 schrieb:

ip -4 r g 1.1.1.1
1.1.1.1 dev wg0 src 10.2.0.2 uid 1000 
    cache 

Teste mal den Ping auf die IP 10.2.0.1. Wenn das funktioniert, dann ergänze im WG-Client bei AllowedIPs, die IP-Adresse 9.9.9.9/32 und wenn diese Ergänzung wirksam ist, dann mach den Ping via WG-Tunnel auf die IP 9.9.9.9.

sieht besser aus

ip -4 r g 1.1.1.1
RTNETLINK answers: Network is unreachable

PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=57 time=11.2 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=57 time=8.95 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=57 time=8.85 ms

--- 9.9.9.9 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 8.852/9.654/11.158/1.064 ms

Koko80 schrieb:

sieht besser aus

OK, d. h. Du brauchst u. a. auch folgende Routen auf deinem Gerät (VPN-Gateway) mit der IP .112:

-die definierte Route via FritzBox zu deinem VPN-Provider (dessen öffentliche IPv4-Adresse), damit der VPN-Tunnel erstmal hergestellt werden kann.

-eine default route via IP 10.2.0.2 (d. h. mit dem wg0-Interface), damit der Internet-Traffic über deinen VPN-Provider statt findet.

Die default route via FritzBox darf nicht zustande kommen oder sollte gelöscht werden. Die default route via 10.2.0.2 (wg0) sollte durch den Eintrag von 0.0.0.0/0 bei den AllowedIPs in der config des wg0 zustande kommen. source-NAT sollte auf allen geräten und für alle Interfaces (außer lo) konfiguriert sein.

Es ist alles hinterlegt, default-Route eingerichtet, in fritz.box die Standardroute konfiguriert und jetzt geht wieder gar nichts bei der VM.

Mir ist das echt zu hoch und verliere den Überblick wie was gemacht werden muss. Ich steige jetzt echt aus.

@lubux Tausend Dank für deine super Hilfe und Geduld! Ich bin dann eher der User, der am liebsten einen Button drücken würde und es läuft. Arbeite mich echt gerne in sowas ein, aber da fehlt mir dann doch die Geduld. Glaube mittlerweile habe ich da die VM wieder irgendwo verbastelt, dass es die Nadel im Heuhaufen wird, da den Fehler zu suchen.

Ich arbeite jetzt mit meiner 16.04 VM weiter und wenn die irgendwann komplett den Geist aufgeben wird, gibt es hoffentlich entweder wieder eine Schritt-für-Schritt-Anleitung für Dummies mit einer Neuinstallation oder ich schaue, dass ich auf all meinen Devices einen eigenen Client mit proprietären Software laufen lasse.

Dennoch, tausend Dank für deine Hilfe!