Actualmente estamos intentando enrutar todos los paquetes desde la subred de nuestra VLAN invitada (eth1.251) a través de un túnel Wireguard hacia Internet. Para lograr esto, utilizamos enrutamiento basado en políticas con una regla para usar la tabla de enrutamiento 10 cuando el tráfico proviene de nuestra subred invitada:
32765: from 10.251.0.0/16 lookup 10
En la tabla de enrutamiento 10, estamos creando una ruta predeterminada hacia nuestra interfaz de túnel:
default dev wg1 scope link
Todos nuestros clientes en nuestra red de invitados pueden acceder a Internet a través del túnel de protección de cables que se espera, sin embargo, los clientes no pueden llegar a la puerta de enlace de la red de invitados (10.251.0.1). TCPDump muestra que la respuesta de eco ICMP se enruta a través de la wg1interfaz hasta el punto final de nuestro túnel, lo que obviamente no es lo previsto. Una solución rápida para esto es agregar la ruta del enlace de alcance para la eth1.251interfaz VLAN invitada al enrutamiento table 10:
default dev wg1 scope link
10.251.0.0/16 dev eth1.251 proto kernel scope link
Ahora el cliente puede acceder a la interfaz del enrutador y sus servicios.
En este enrutador hay otra interfaz eth1 con la subred 192.168.0.1/16. Cuando eliminamos nuestra 10.251.0.0/16ruta recién agregada ya table 10no podemos acceder a la interfaz del enrutador 10.251.0.1, sin embargo,todavía capaz de alcanzarla interfaz 192.168.0.1de un cliente en la 10.251.0.0/16subred. Los clientes (por ejemplo 192.168.0.2, ) detrás del enrutador en la 192.168.0.0/16subred no se pueden recargar desde 10.251.0.0/16.
Pregunta principal: ¿Por qué podemos acceder a la 192.168.0.1IP de la interfaz de nuestro enrutador sin una entrada explícita en la tabla de enrutamiento, pero no a la 10.251.0.1IP de la interfaz de nuestros clientes en la 10.251.0.0/16subred invitada?
A continuación se ofrece una descripción general de la estructura de la red. Creo que esto ayuda a comprender nuestra configuración.
Respuesta1
No hay una explicación general, solo es cuestión de seguir lo que sucede en la configuración de enrutamiento.
10.251.0.1, es a la vez una dirección de enrutador local y parte de 10.251.0.0/16.
Al recibir un paquete a unlocaldirección, el enrutador coincide con lalocaltabla usando el primero ip rulecon menor preferencia: 0, antes de la regla para la tabla 10, y coincide. Recuerde que las tablas de enrutamiento coinciden endestinos, mientras que normalmente las reglas personalizadas están configuradas para coincidirfuentes.
Cuando el enrutador responde, esta vez la tabla local no coincide: 10.251.0.2 no es localdestino. La siguiente regla se verifica y coincide from 10.251.0.0/16, busca la tabla 10 y el paquete pasawg1.
Para 192.168.0.1, recibir el paquete es exactamente igual que antes con ellocalmesa. Ahora la respuesta no coincide con la regla adicional y se aplica la tabla de enrutamiento principal: funciona como siempre: un sistema Linux responderá desde cualquiera de sus IP.
Nuevamente, para 192.168.0.2: no es unlocalIP, por lo que no coincide con lalocaltabla, pero la consulta coincide con la regla agregada: los paquetes se pierdenwg1.
Por lo tanto, es útil copiar una parte de la tabla de enrutamiento principal a la tabla adicional para evitar efectos secundarios.
Mucho de esto se puede probar con ip route getla sintaxis correcta, siempre y cuando no haya marcas involucradas:
Sin la entrada adicional en la tabla 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
RTNETLINK answers: Invalid cross-device link
# sysctl -w net.ipv4.conf.eth1/251.rp_filter=2 #relax reverse path filtering
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.1
local 192.168.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.2
192.168.0.2 from 10.251.0.2 dev wg1 table 10
cache iif eth1.251
ruta de respuesta:
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev wg1 table 10 uid 0
cache
# ip route get from 192.168.0.1 10.251.0.2
10.251.0.2 from 192.168.0.1 dev eth1.251 uid 0
cache
Al agregar la entrada en la tabla 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1 #even with strict reverse path filtering, since the reverse route is correct
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev eth1.251 table 10 uid 0
cache