Dos saltos de VPN seguidos: ¿quién ve realmente tu tráfico?
Los saltos en serie descifran y vuelven a cifrar en la primera puerta; los saltos anidados solo quitan la capa exterior. Recorra ambos diseños y vea qué operador lee qué.
Cada perfil de cliente nombra un servidor, así que desde el asiento del usuario hay un túnel y un lugar donde termina la protección. Lo que ocurre tras esa primera puerta es una decisión de diseño que el cliente nunca ve, y los dos diseños habituales se comportan de forma muy distinta bajo inspección. En una cadena en serie la primera puerta descifra y vuelve a cifrar. En una cadena anidada quita una capa exterior y reenvía un túnel interior que no puede abrir. El número de saltos es idéntico en ambos, por eso la diferencia hay que dibujarla y no contarla.
Empiece por el cliente y nombre ambos extremos
Empiece donde empieza el usuario, en el perfil de conexión. Contiene una dirección remota, un método de autenticación y, cuando el diseño lo admite, una lista de rutas. Etiquete ese túnel exterior del cliente a la puerta A y dele direcciones de ejemplo: la dirección del túnel del cliente 10.77.0.2, la de A 10.77.0.1 y el extremo público de A 198.51.100.10, tomados del rango de documentación TEST-NET-2 para que nada del ejemplo pueda chocar con un host real.
Nada en ese perfil menciona la puerta B, y eso no es un defecto. El segundo salto pertenece a A, y la única obligación del cliente es entregar el tráfico a A y aceptar lo que vuelve. Si A termina el túnel, lo reenvía o abre uno nuevo es la pregunta que responde el resto de este recorrido, y decide qué puede leer A.
En serie: A descifra y luego vuelve a cifrar
En el diseño en serie A termina el tráfico dos veces. Quita la protección al cliente, obtiene el paquete IP de la aplicación y luego envía ese paquete por un segundo túnel que A origina hacia B. Entre esas dos operaciones el paquete está en la ruta de reenvío de A como un paquete IP corriente dirigido a un destino privado.
Eso produce dos consecuencias que conviene decir sin rodeos. A puede aplicar política al paquete interior, en forma de rutas, reglas de filtrado y registro de origen y destino, y A debe mantener dos juegos de credenciales: uno como servidor para el cliente y otro como cliente de B. La protección existe en cada instante, pero el objeto protegido cambia de identidad en A.
De ahí no se sigue que A lea el texto plano de la aplicación. Cuando el cliente y el servicio usan TLS y verifican los certificados del otro, A ve un flujo de registros TLS en lugar de una petición legible. Confirmar dónde termina esa protección exige mirar la cadena de certificados del servicio, no el diagrama del túnel.
Anidado: A solo quita la capa exterior
En el diseño anidado el cliente construye primero un túnel interior hacia B y luego lleva ese túnel dentro del exterior hasta A. A quita la cabecera exterior, encuentra un túnel interior y lo reenvía sin tener sus claves, así que la protección interior sigue terminando en B.
El enlace ascendente del cliente lleva entonces dos capas, mientras que el camino entre A y B lleva una. A ve las direcciones exteriores del túnel interior, lo que basta para saber que hay tráfico y aproximadamente hacia dónde va, y no basta para leer la carga útil. Esa es toda la diferencia con el caso en serie, y ningún contador de saltos la muestra. Lo que A todavía puede hacer es negarse a reenviar lo que no puede leer, y eso siempre está disponible para el operador de esa puerta.
El anidamiento cobra por esa propiedad. Cada capa añade sobrecarga de cabecera, así que la planificación de MTU y MSS se vuelve obligatoria y no solo ordenada, y un camino que funciona con una capa puede descartar en silencio paquetes grandes con dos. Cada capa necesita además su propio comportamiento de reconexión y de mantenimiento, y un fallo en una capa parece una interrupción parcial a través de la otra.
Dibuje a los observadores, no solo los túneles
Los túneles son la parte fácil del dibujo. Los observadores son el tema del diseño, así que escriba una fila por punto de vista y rellene qué puede leer realmente cada uno.
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
Dos filas se confunden constantemente: el operador de A y el proveedor del túnel del cliente. Pueden ser una sola entidad, y nombres de puerta separados no los hacen independientes. Una propiedad independiente necesita control administrativo separado, credenciales separadas y registro separado.
Los metadatos sobreviven a ambos diseños. El tiempo, los tamaños de paquete y los recuentos de conexiones siguen siendo observables en cada salto, así que dos saltos elevan el coste de la correlación en lugar de eliminar la señal. Un diseño que promete invisibilidad debería contrastarse con esa lista antes de que nadie confíe en él.
Recorra los caminos de fallo antes de elegir
Rompa cosas a propósito desde el cliente, en el orden en que un usuario las encontraría. Empiece por la interfaz y su MTU, porque el anidamiento falla por tamaño de paquete mucho antes de fallar por autenticación.
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1
Luego confirme los extremos de protección en lugar de darlos por supuestos. Pida al servicio su certificado desde dentro del túnel que esté activo, y compare la cadena que ve el cliente con la cadena que el servicio presenta en realidad. Una puerta que refirma o intercepta cambia ese certificado, y la inspección se vuelve visible con un solo comando.
openssl s_client -connect intranet.example.com:443 -brief < /dev/null
Termine con la matriz de reconexión: cae el túnel del cliente, cae el túnel de B, cambia el camino entre A y B. Anote qué vuelve y qué no, y si alguna conexión interior cae alguna vez a una ruta fuera de su portador previsto. Registre las direcciones que usó cada prueba, porque repetirla en otra red de acceso responde a otra pregunta. Repita también la prueba de MTU tras cada reconexión, porque un camino cambiado puede bajar el tamaño utilizable sin que se mueva ni una línea de configuración.
Elija en serie cuando A deba aplicar política al paquete interior, o cuando el cliente no pueda ejecutar dos túneles apilados. Elija el anidamiento cuando la carga interior deba seguir siendo ilegible en A. Escriba la elección con sus observadores y sus cifras de MTU, y la siguiente persona no tendrá que redibujar todo el cuadro para responder una pregunta.