Ich verwende einen GL.inet-Router mit OpenWRT OpenWrt 19.07.8 r11364-ef56c85848.
Ich habe einen Wireguard-Server auf einem Remote-Computer eingerichtet. Wenn das VPN nicht verbunden ist, kann ich diesen Server von meinem LAN aus über seine öffentliche IP erreichen. Wenn das VPN verbunden ist, kann ich ihn über die interne IP erreichen, aber nicht mehr über die externe IP von einem Computer in meinem LAN aus.
Traceroute zeigt die Pakete, die am Router fehlschlagen und keine Route zum Host haben:
~ % ping 35.190.161.xxx
PING 35.190.161.169 (35.190.161.xxx): 56 data bytes
92 bytes from router.local.wan (192.168.1.254): Destination Host Unreachable
Wenn ich mich jedoch per SSH mit dem Router in Verbindung setze, wird nicht nur das erwartete Routing angezeigt, sondern auch Pings und Traceroute sind erfolgreich:
~# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 100.64.0.1 0.0.0.0 UG 0 0 0 wan
10.66.66.0 * 255.255.255.0 U 0 0 0 wg0
34.120.255.244 * 255.255.255.255 UH 0 0 0 wan
35.190.161.xxx 100.64.0.1 255.255.255.255 UGH 0 0 0 wan
100.64.0.0 * 255.192.0.0 U 0 0 0 wan
192.168.0.0 * 255.255.252.0 U 0 0 0 br-lan
~# ping 35.190.161.xxx
PING 35.190.161.xxx (35.190.161.xxx): 56 data bytes
64 bytes from 35.190.161.xxx: seq=0 ttl=59 time=243.335 ms
Meine Wireguard-Konfiguration für diesen Client ist:
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxlMxuhwtB9vV2Gpks=
Address = 10.66.66.3/32,fd42:42:42::3/128
DNS = 8.8.8.8,8.8.4.4
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxkIIPFsO2/EuXDNbeR3g=
PresharedKey = xxxxxxxxxxxxxxxxxxxxxxxxYnnXy4CZUMUzGBAieqU=
Endpoint = 35.190.161.xxx:60242
AllowedIPs = 10.66.66.0/24,::/0
Während ichdürfenUm über die interne IP auf den Remote-Server zuzugreifen (z. B. über SSH), ist es umständlich, je nachdem, ob das VPN hergestellt ist oder nicht, die richtige Adresse auswählen zu müssen.
Fehlt etwas in meiner Wireguard-Konfiguration oder liegt ein anderes Problem vor?
Antwort1
Ich hatte vor kurzem auch dieses Problem. Ich habe herausgefunden, dass mein Router eine IP-Regel für die Server-IP-Adresse hinzufügt (Tabelle 31):
Screenshot der LUCI-Routentabelle
root@GL-MT300N-V2:~# ip rule
0: from all lookup local
31: from all fwmark 0x60000/0x60000 lookup 31
1001: from all iif eth0.2 lookup 1
2001: from all fwmark 0x100/0x3f00 lookup 1
2061: from all fwmark 0x3d00/0x3f00 blackhole
2062: from all fwmark 0x3e00/0x3f00 unreachable
32766: from all lookup main
32767: from all lookup default
Wenn ich den Wireguard-Client aktiviere und diese Regel dann manuell mit ip rule del from all fwmark 0x60000/0x60000 lookup 31einem Befehl entferne, kann ich vom LAN-Netzwerk direkt per Ping/SSH an die IP des Wireguard-Servers senden.
Ich habe einige Stellen gefunden, an denen diese Regel hinzugefügt wird:
/etc/init.d/wireguard
/etc/vpn.user
Ich habe Zeilen mit Befehlen zum Hinzufügen von IP-Regeln kommentiert und kann jetzt den Wireguard-Client aus- und einschalten und trotzdem auf die WAN-IP zugreifen:
#fix ddns conflict
#local DDNS=$(iptables -nL -t mangle | grep WG_DDNS)
#local lanip=$(uci get network.lan.ipaddr)
#local gateway=${lanip%.*}.0/24
#if [ -z "$DDNS" ];then
#iptables -t mangle -N WG_DDNS
#iptables -A WG_DDNS -t mangle -i br-lan -s $gateway -d $publicip -j MARK --set-mark 0x60000
#iptables -t mangle -I PREROUTING -j WG_DDNS
#ip rule add fwmark 0x60000/0x60000 lookup 31 pref 31
#ip route add $publicip dev wg0 table 31
#fi
Bitte beachten Sie, dass ich kein Routing-Experte bin und nicht weiß, ob dieser Hack irgendetwas kaputt macht (in den Kommentaren steht „DDNS-Konflikt beheben“ – ich bin mir nicht sicher, was das bedeutet), aber bei mir funktioniert es einwandfrei und macht nichts kaputt (ich verwende eine Wireguard-Verbindung nur für den Zugriff auf das Remote-Netzwerk). Außerdem bin ich kein OpenWRT-Experte, daher kann ich nicht garantieren, dass diese Änderungen bei Neustarts des Routers gespeichert werden.