VPN enrutada o puenteada: elija según lo que el cliente deba alcanzar

El mismo día llegan dos tickets: un usuario necesita una aplicación web interna y un ingeniero necesita que un instrumento de banco se comporte como si estuviera en el mismo segmento Ethernet. A ambos se les responde con póngalos en la VPN, y ahí empieza el problema. Un túnel enrutado y un túnel puenteado extienden relaciones distintas, y solo una de ellas encaja con cada solicitud. Elegir la topología es una decisión de acceso, no un ajuste de criptografía.

Dos solicitudes que en la ventanilla parecen iguales

El requisito del empleado es un servicio, alcanzable por IP, desde un dispositivo que usted no controla. El requisito del ingeniero es a nivel de enlace: el instrumento espera ver tramas Ethernet y descubrimiento por broadcast, y quizá DHCP del segmento en el que cree estar.

Son preguntas distintas, y responder ambas con un puente amplía el acceso del empleado a toda la LAN de la oficina sin motivo.

Escriba el requisito como una frase antes de elegir: qué destinos, qué protocolos y qué pares deben parecer locales. Si la respuesta es un host y un puerto, el enrutamiento lo cubre. Si la respuesta es una relación a nivel de trama con dispositivos que solo hablan broadcast, el puente puede ser la única opción. Todo lo intermedio merece un segmento de prueba en lugar de la LAN de producción.

Una ruta es más estrecha que la pertenencia a la LAN

Un cliente enrutado obtiene una dirección en una subred de túnel y rutas para los prefijos que elija. Puede alcanzar el servidor de aplicaciones y nada más, si eso dice la política. La puerta de enlace se convierte en el punto de aplicación, siempre que cada camino relevante la cruce.

No confunda una ruta con un permiso. Decirle a un cliente cómo llegar a una subred no le impide probar otro destino.

Aplique el control de acceso donde realmente pueda hacer cumplir el flujo y mantenga los permisos propios de la aplicación. Una regla de reenvío amplia o una segunda interfaz olvidada pueden conceder más de lo que sugiere el diagrama. Lea las reglas efectivas, no las previstas. Luego pruebe un destino que debería fallar, porque una política que nadie ha intentado vulnerar es una hipótesis.

Un puente cambia la pregunta de admisión

El puenteo combina una interfaz física y un dispositivo TAP en un conmutador de software, de modo que los dispositivos remotos se unen al mismo dominio de broadcast. Es una capacidad real y un riesgo real: el dispositivo remoto ya no es un invitado enrutado, es un participante.

Decida qué dispositivos pueden unirse, qué tipos de trama deben cruzar y dónde se bloquea la interacción no deseada. El direccionamiento y la autoridad DHCP pasan a formar parte de la red compartida, y dos servidores DHCP en un segmento producen exactamente el desastre que usted espera.

Para el instrumento, un segmento de prueba dedicado suele encajar mejor que la LAN de la oficina. Mantenga el acceso de gestión fuera del experimento y defina cómo se retira el participante temporal cuando termina el trabajo.

El filtrado existe en ambas topologías

Un puente no es intrínsecamente no filtrable y una ruta no es intrínsecamente segura. El filtrado de puentes de Linux tiene sus propios ganchos y su propia sintaxis de reglas, y una regla escrita para reenvío IP enrutado no se aplica automáticamente a las tramas puenteadas.

Compruebe qué admite realmente la plataforma antes de prometer una frontera:

bridge link show
nft list ruleset

TUN y TAP describen el tráfico de la interfaz, no el cifrado. Cambiar interfaces no arregla nada de eso: la autenticación de pares, una clave robada y una política criptográfica obsoleta sobreviven todas al cambio. Ambos extremos siguen necesitando ajustes que coincidan y que aún se admitan.

Demuestre la frontera con tres intentos

La aceptación son tres observaciones, no una revisión del diagrama. La operación requerida debe funcionar, un destino no relacionado debe fallar y los propios servicios de gestión de la puerta de enlace deben quedar fuera de alcance.

Ejecute el camino permitido y el denegado desde el mismo cliente y registre ambos:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Para un puente, añada las comprobaciones a nivel de enlace: si cruza el tráfico de descubrimiento permitido, si el direccionamiento viene de la autoridad prevista y si el participante temporal ha desaparecido tras retirarlo. Cuando la IP enrutada simple ya satisface el requisito, unirse al segmento Ethernet de la oficina necesita una justificación aparte, y debe escribirse antes del cambio.