
Estoy usando un enrutador GL.inet con OpenWRT OpenWrt 19.07.8 r11364-ef56c85848.
He configurado un servidor Wireguard en una máquina remota. Con la VPN no conectada puedo llegar a ese servidor desde mi LAN usando su IP pública. Con la VPN conectada, puedo acceder a ella con la IP interna, pero ya no puedo acceder a ella a través de la IP externa desde una computadora en mi LAN.
Traceroute muestra los paquetes que fallan en el enrutador sin ruta al host:
~ % 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
Sin embargo, si entro al enrutador por ssh, no solo muestra el enrutamiento esperado, sino que los pings y el traceroute se realizan correctamente:
~# 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
Mi configuración de Wireguard para este cliente es:
[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
Mientras yopoderllegar al servidor remoto (por ejemplo, a través de ssh) utilizando la IP interna, es inconveniente tener que elegir la dirección correcta dependiendo de si la VPN está establecida o no.
¿Falta algo en mi configuración de Wireguard o hay algún otro problema?
Respuesta1
Recientemente también me enfrenté a este problema. Descubrí que mi enrutador agrega una regla IP para la dirección IP del servidor (tabla 31):
captura de pantalla de la tabla de rutas LUCI
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
Si habilito el cliente Wireguard y luego elimino manualmente esta regla usando ip rule del from all fwmark 0x60000/0x60000 lookup 31
el comando, puedo hacer ping/ssh desde la red LAN a la IP del servidor Wireguard directamente.
Encontré algunos lugares donde se agrega esta regla:
/etc/init.d/wireguard
/etc/vpn.user
He comentado líneas con comandos para agregar reglas de IP, y ahora puedo apagar y encender el cliente Wireguard y seguir accediendo a WAN IP:
#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
Tenga en cuenta que no soy un experto en enrutamiento y no sé si este truco rompe algo (en los comentarios dice "arreglar conflicto de ddns", no estoy seguro de lo que significa), pero para mí funciona bien y no rompe nada. (Estoy usando una conexión Wireguard para acceder a la red remota únicamente). Además, no soy un experto en OpenWRT, por lo que no puedo garantizar que estos cambios se guarden al reiniciar el enrutador.