Dibuja la ruta descifrada: dónde un dispositivo VPN aplica la política
Un diagrama que termina en el listener cifrado no muestra la política que importa. Dibuja la ruta descifrada y compara las ubicaciones por lo que atraviesa la solicitud.
Los diagramas de los proveedores suelen detenerse en el listener cifrado, porque esa es la parte con una dirección pública. La pregunta que decide la postura de seguridad es qué ocurre tras el descifrado, cuando el paquete se convierte en IP ordinaria y puede alcanzar todo lo que permite la tabla de rutas. Si nadie dibujó ese tramo, nadie es su dueño. El runbook de abajo lo dibuja primero y luego compara ubicaciones por lo que la solicitud descifrada atraviesa realmente.
Dibuja el paquete después del descifrado, no antes
La ruta externa es la parte que los proveedores documentan: un extremo público, una política de transporte que admite la conexión y un servicio que la termina. La ruta interna empieza en el momento en que el paquete pierde su cabecera de túnel, y desde ahí la gobiernan reglas de enrutamiento y filtrado que no tienen nada que ver con el túnel. Pon ambas en la misma página, porque un diagrama solo con la primera insinúa que la admisión y la autorización son una sola decisión. No lo son, y la brecha entre ellas es donde fallan la mayoría de las ubicaciones.
Escribe el tramo interno como una secuencia numerada con tipos de dispositivo nombrados, no como una flecha. Una flecha oculta si la solicitud cruza un filtro, y cruzar o no cruzar es toda la cuestión. Cada salto de abajo nombra el dispositivo y el conjunto de reglas que actúa allí, de modo que un filtro ausente aparece como un hueco en lugar de quedar insinuado por una línea.
- Cliente remoto: el dispositivo del usuario que origina el túnel.
- Política de borde: el conjunto de reglas que admite el transporte externo al listener público.
- Dispositivo terminador: el extremo VPN que desencapsula y entrega el paquete a la IP ordinaria.
- Filtro interno: el conjunto de reglas de reenvío o de grupos de seguridad que limita el tráfico de cliente a servicio.
- Host de aplicación: el servicio que recibe la solicitud descifrada.
Dos políticas, dos propietarios
La política externa responde quién puede establecer un túnel, y se expresa en las reglas que admiten el transporte hacia el servicio terminador. La política interna responde a qué servicio puede llegar un usuario autenticado, y vive en reglas de reenvío, grupos de seguridad o la propia aplicación. Un solo dispositivo puede alojar ambas, y un diseño con varios dispositivos sigue teniendo ambas. Nombrarlas por separado es lo que te permite decir cuál falló cuando un usuario no puede llegar a una aplicación.
Los controles de admisión como los certificados y la autenticación multifactor responden a la identidad y a nada más. No deciden la ubicación y no conceden permiso por recurso una vez que el usuario está dentro.
La ubicación decide qué frontera cruza la solicitud
Tres ubicaciones son habituales, y cada una cambia qué frontera cruza la solicitud descifrada. Compáralas por lo que termina allí, qué puede ver el texto plano, qué control todavía puede denegar la solicitud y qué falla junto con el dispositivo. La tabla de abajo usa esas cuatro columnas en lugar de una pregunta genérica, porque cada respuesta es una decisión de diseño separada.
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
La tercera ubicación es la que elimina la aplicación en silencio, porque un tramo en el segmento protegido da al dispositivo una ruta directa que el diagrama quizá no muestra. Inspecciona las interfaces y las rutas en lugar de la imagen: ip route get 10.20.5.10 informa por qué interfaz saldría el paquete, y la respuesta a menudo no es la que supuso el diseño. El papel clásico del cortafuegos de controlar el tráfico entre posturas, como se describe enNIST SP 800-41, es una prueba útil aquí, porque un dispositivo con un tramo sin restricciones hacia la red protegida no controla mucho. Una consulta de ruta es un diagrama más honesto que el de la presentación.
La administración pertenece a su propia ruta explícitamente permitida. Permitir que los usuarios lleguen a una aplicación nunca exige permitirles llegar a la interfaz de control del dispositivo, y ambos permisos deben concederse con reglas distintas. Audita ambas rutas por separado, porque una regla compartida oculta cuál se abrió.
La traducción cambia lo que pueden ver las reglas posteriores
La traducción de origen es cómoda y destruye información. Tras el masquerade cada cliente parece el dispositivo, así que una regla posterior escrita para distinguir usuarios ya no puede hacerlo. No es solo un problema de registro, es un problema de política: una regla basada en la dirección del cliente se convierte en silencio en una regla basada en la pasarela. Si la política por usuario importa, conserva el origen o aplica la política antes de la traducción.
La ruta de respuesta merece el mismo escrutinio. Registra qué ruta elige el destino para el paquete de vuelta, porque un retorno asimétrico evita la inspección con estado y produce una conexión que se establece y luego se atasca. Ambas direcciones tienen que cruzar la frontera que dibujaste, o la frontera es decoración.
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGAcepta una operación permitida y una denegada
Prueba desde el cliente remoto real y no desde un host de gestión, porque el host de gestión suele estar en un sitio donde el usuario nunca estará. Una operación permitida demuestra que la ruta funciona, y una denegada demuestra que la política hace algo. Ejecuta ambas tras cada cambio de ubicación y registra la identidad de origen y el destino que usaste. Una prueba que solo demuestra éxito no distingue una regla correcta de una ausente.
Luego prueba los casos que cambian de estado: una reconexión, una sesión que sobrevive a una rotación de claves y un fallo del propio dispositivo. Compara actualizaciones, capacidad y recuperación como parte del mismo diseño, porque un dispositivo que sostiene varios controles lógicos es un solo dominio de fallo con varias etiquetas. Una segunda caja tampoco es independiente cuando una credencial administrativa compartida o una ruta sin restricciones derrota la frontera que debía crear.
Documenta el extremo, la ruta descifrada y el control que la restringe. Esas tres líneas siguen teniendo sentido se llame como se llame la implementación.