☰

¿Por qué mis paquetes salen por la interfaz incorrecta según la tabla de enrutamiento de Linux?

tag-icon • tag-icon linux networking routing
¿Por qué mis paquetes salen por la interfaz incorrecta según la tabla de enrutamiento de Linux?

Tengo una máquina Ubuntu Bionic con enlace wifi; y he configurado un túnel wireguard en él:

# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 5502  bytes 545376 (545.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5502  bytes 545376 (545.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 10.0.0.3  netmask 255.255.0.0  destination 10.0.0.3
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 22980  bytes 2777236 (2.7 MB)
        RX errors 75  dropped 0  overruns 0  frame 75
        TX packets 23467  bytes 12255956 (12.2 MB)
        TX errors 0  dropped 362 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.218  netmask 255.255.0.0  broadcast 192.168.255.255
        ether dc:85:de:f3:3f:65  txqueuelen 1000  (Ethernet)
        RX packets 103227  bytes 54970550 (54.9 MB)
        RX errors 0  dropped 103695  overruns 0  frame 0
        TX packets 41654  bytes 15633577 (15.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Anteriormente había estado redirigiendo todo el tráfico a través del túnel Wireguard, pero ahora lo he invertido para permitir que el par reenvíe a través de este host. Sin embargo, parece que mis paquetes todavía quieren pasar a través del túnel por alguna razón.

Aquí está mi tabla de enrutamiento:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wlan0
10.0.0.0        0.0.0.0         255.255.0.0     U     0      0        0 wg0
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.1.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlan0
192.168.100.1   192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0

Si intento hacer ping o hacer curl a una dirección externa, siempre se cuelga. Traceroute muestra que está intentando enrutar paquetes a través del túnel (el par está actualmente configurado para descartarlos):

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  68.393 ms  74.587 ms  74.328 ms^C

Pero si se usa traceroute 8.8.8.8 -i wlan0para forzar a traceroute a usar wlan0, como debería exigir la tabla de enrutamiento anterior, entonces funciona.

¿Qué podría estar pasando? ¿No dice la tabla de enrutamiento que los paquetes destinados a 8.8.8.8 deben salir de wlan0 a 192.168.1.1 para su reenvío?

(En caso de que importe, mis únicas iptables ahora son -A FORWARD -i wg0 -j ACCEPTy -t nat -A POSTROUTING -o wlan0 -j MASQUERADE)

Respuesta1

Parece que wg-quick upagrega rutas a otra tabla que no aparece usando route -no ip route show. Si corres ip route show table all, podrás verlo. En este caso, estaba en una tabla llamada 51820y tenía prioridad sobre la tabla predeterminada.

información relacionada