Cómo dar a una LAN de pruebas su propia salida WireGuard

Tres diseños resuelven el mismo problema de laboratorio: una LAN pequeña que debe salir por un par WireGuard mientras la puerta de enlace conserva su enlace ascendente habitual. El atajo tentador es mover la ruta predeterminada del router dentro del túnel, pero eso rompe la propia ruta de gestión del equipo y todo lo demás que reenvía. La opción interesante es el enrutamiento por políticas limitado a una interfaz y un prefijo. Elija entre ellos respondiendo tres preguntas sobre la máquina que realmente tiene.

Decida dónde vive la salida

Primera pregunta: ¿reenvía este host para algo más? Una puerta de enlace de laboratorio dedicada puede vivir con una política de reenvío que descarta por defecto. Un router con deberes de producción no puede, y superponer un conjunto de reglas competidor sobre un cortafuegos gestionado es exactamente cómo se programan las caídas. Segunda: ¿puede poseer dos objetos de política y su orden entre reinicios? Tercera: ¿el par que tiene autoriza la dirección de origen de su túnel y ofrece salida a internet? Un par que solo expone una red privada es otro producto, y ningún cambio local de enrutamiento lo arregla. Si cualquier respuesta es no, ponga la salida en un espacio de nombres o en una máquina virtual desechable.

Un espacio de nombres o una VM cuestan memoria y le dan un radio de impacto limpio. El enrutamiento por políticas cuesta dos reglas y le deja una sola máquina que depurar.

Elija la salida que autoriza su origen

La mayoría de los fallos en este laboratorio ocurren antes de que exista una sola regla de cortafuegos. El operador de la salida debe aceptar la dirección de origen que llevan sus paquetes tras la traducción, que en este diseño es la dirección del túnel y no el prefijo de la LAN. Por eso el enmascaramiento pertenece al diseño desde el principio y no como un añadido tardío.

Confirme tres cosas con el operador: el par autoriza la dirección de su túnel, reenvía IPv4 en lugar de terminar en sí mismo y aplica NAT de salida. Sin lo primero, sus paquetes llegan y desaparecen. Sin lo tercero, salen con un origen privado y mueren en el siguiente salto. Después compruebe que wg-quick no instala su propia ruta predeterminada, lo que evita Table = off; ese ajuste suprime la creación de rutas, no las comprobaciones de AllowedIPs del par ni su manejo de DNS.

Dos objetos de política hacen la dirección

La dirección necesita una tabla y una regla. La tabla contiene dos rutas: el prefijo de la LAN fuera de la interfaz LAN y una predeterminada fuera del túnel. La regla envía el tráfico que llega por la interfaz LAN y lleva ese prefijo hacia la tabla. Use el selector iif junto con la coincidencia de origen, porque los paquetes WireGuard propios de la puerta de enlace se originan localmente y nunca coinciden con una interfaz entrante.

El guardián va antes de la consulta, no después. Ese orden es toda la propiedad de seguridad del diseño.

El guardián es una segunda regla sobre el mismo selector cuyo veredicto es unreachable. Deles una prioridad numérica más alta para que la consulta siga ganando mientras el túnel está levantado. Cuando la ruta del túnel desaparece, la consulta no devuelve nada y el guardián detiene la búsqueda en lugar de dejarla caer a la ruta predeterminada WAN de la tabla principal.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Cierre la brecha de repliegue antes de abrirla

Instale primero el guardián y la consulta después. Hacerlo al revés deja una ventana de segundos en la que el tráfico de un cliente de pruebas puede alcanzar el enlace ascendente.

El filtro completa el cuadro. En el gancho forward acepte la dirección de la LAN al túnel para el prefijo de pruebas y la dirección de retorno establecida, y luego descarte todo lo demás; el NAT de ese prefijo hacia la interfaz del túnel va en postrouting. Dejar policy drop en la cadena de reenvío es lo que convierte una ruta ausente en silencio en vez de en una fuga. El filtrado de ruta inversa necesita modo laxo en la interfaz del túnel, porque un origen público que llega desencapsulado tiene su mejor ruta inversa en el lado WAN. Linux toma el mayor de los valores all y por interfaz, así que configurar la interfaz del túnel no es lo mismo que debilitar la validación en todas partes.

Demuéstrelo con el caso de fallo

Pregunte al núcleo algo preciso nombrando la dirección de origen del cliente y la interfaz por la que llega. Una consulta sin ambas responde otra pregunta y parecerá correcta en ambos casos. Después mire los contadores del cortafuegos, el estado de transferencia del par y el propio servicio del cliente.

Pruebe la retirada como es debido. Detenga el túnel dejando la regla y el filtro en su sitio: el cliente debería atascarse y el tráfico propio de la puerta de enlace debería seguir funcionando. Después detenga el par sin tocar la interfaz local, que es el caso que atrapa los diseños que confían solo en la presencia de la ruta. Por último reinicie y vuelva a comprobar el orden de las reglas, porque un gancho de desmontaje que elimina el guardián devuelve todo el diseño a la tabla principal. Anote el número de tabla, las prioridades y los nombres de interfaz en el tíquet de cambio, porque la siguiente persona que añada una regla será la que rompa esto.