Reglas de VPN en el router: empareja el origen y el destino
Una regla de VPN en el router tiene dos extremos: el dispositivo que envía tráfico y el destino que debe usar el túnel. Decide primero la intersección y el comportamiento de reserva.
Las páginas de compra de routers presentan el enrutamiento VPN como una casilla, y la frase esconde tres preguntas distintas. ¿La regla coincide con el dispositivo que envía el tráfico, con el servidor que lo recibe o con ambos? ¿Qué ocurre con el tráfico que no coincide con ninguno? Y cuando dos reglas se solapan, ¿cuál gana? Escribir la respuesta como un par de origen y destino convierte una vaga lista de funciones en un diseño comprobable.
El nombre de la función esconde dos extremos
Un reproductor multimedia que debe usar el túnel es una coincidencia de origen. Un prefijo de oficina privado que debe ser accesible por el túnel es una coincidencia de destino. Una estación de trabajo que debe usar el túnel solo para un servicio es ambas cosas, y esa intersección es el caso que la mayoría del firmware de consumo maneja mal.
Escribe el requisito como un par antes de comparar productos. Ese par es lo que probarás después.
Un producto que ofrece una lista de dispositivos o una lista global de destinos puede no expresar «solo este dispositivo, solo estos destinos». La diferencia no es estética: una regla global de destino envía el tráfico de todos los dispositivos hacia ese sitio por el túnel, y una regla de dispositivo envía todo el tráfico de ese dispositivo. Ninguna de las dos es el requisito. Prueba ese caso con dos dispositivos antes de fiarte de la pantalla.
Construye la regla como una intersección
Una tabla mantiene honesto el diseño. Pon el escenario a la izquierda y luego nombra por separado la coincidencia de emisor y la de destino:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
La tercera fila es la interesante, porque necesita las dos mitades a la vez. Si el firmware solo puede expresar un eje, el requisito debe dividirse en dos reglas o trasladarse a un dispositivo que sí pueda.
Mantén estable la identidad del origen. Una reserva DHCP, un segmento dedicado o un mecanismo de identidad de dispositivo funcionan, pero una dirección que cambia al vencer el arrendamiento no. Incluye IPv6, porque una dirección IPv4 no identifica todo el tráfico de un dispositivo.
La prioridad decide el solapamiento
El solapamiento de reglas es normal. Una regla amplia de dispositivo y una regla estrecha de destino pueden describir un mismo flujo, y el orden de prioridad documentado decide cuál gana. Una pantalla de ajustes atractiva no te dice ese orden.
Lee el manual para el orden y para el caso sin coincidencia, y luego prueba ambos con tráfico que puedas observar:
ip rule show
ip route get 203.0.113.10
Si la documentación no indica el orden, supón que la regla más estrecha puede no ganar y diseña teniéndolo en cuenta. Dos reglas que no pueden entrar en conflicto son más fáciles de mantener que una regla ingeniosa con una precedencia no documentada.
Los nombres necesitan una política de actualización
Un destino escrito como dominio añade un problema de mantenimiento. El router debe resolverlo, actualizar el mapeo, gestionar varias direcciones y subdominios y lidiar con el DNS de aplicaciones que evita el resolutor esperado.
Copiar un resultado de búsqueda en una regla IP es una instantánea, no una política de dominio.
Decide cuánto puede envejecer una respuesta antes de que la regla sea incorrecta y qué hace el router cuando falla la resolución. Una regla que conserva la última dirección conocida puede sobrevivir a una migración de servicio; una regla que descarta la entrada puede detener el túnel en silencio. Cualquiera de los dos comportamientos es aceptable si se anota junto a la regla.
Define el estado no disponible
Una preferencia de ruta no impone tráfico solo por VPN. Cuando el túnel está caído, el router puede bloquear el flujo, enviarlo directo o usar otro túnel, y cada opción tiene una firma de fallo distinta.
Decide cuál necesita el requisito y luego verifícalo deteniendo el túnel y observando el flujo:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10
El tráfico originado por el router es un ámbito aparte. El reenvío DNS, las comprobaciones de actualización y la monitorización pueden iniciar flujos nuevos desde el propio router en lugar de heredar la coincidencia de origen del dispositivo. Ten en cuenta esos flujos de forma explícita, o aparecerán como fugas inexplicadas en los registros.