Debuxa a ruta descifrada: onde un dispositivo VPN aplica a política

Os diagramas dos provedores adoitan deterse no listener cifrado, porque esa é a parte cun enderezo público. A pregunta que decide a postura de seguridade é que ocorre despois do descifrado, cando o paquete se converte en IP ordinaria e pode alcanzar todo o que permite a táboa de rutas. Se ninguén debuxou ese tramo, ninguén é o seu dono. O runbook de abaixo debúxao primeiro e logo compara as ubicacións polo que a solicitude descifrada atravesa realmente.

Debuxa o paquete despois do descifrado, non antes

A ruta externa é a parte que os provedores documentan: un extremo público, unha política de transporte que admite a conexión e un servizo que a termina. A ruta interna comeza no momento en que o paquete perde a súa cabeceira de túnel, e desde aí govéraa regras de enrutamento e filtrado que non teñen nada que ver co túnel. Pon ambas na mesma páxina, porque un diagrama só coa primeira insinúa que a admisión e a autorización son unha soa decisión. Non o son, e a fenda entre elas é onde fallan a maioría das ubicacións.

Escribe o tramo interno como unha secuencia numerada con tipos de dispositivo nomeados, non como unha frecha. Unha frecha oculta se a solicitude atravesa un filtro, e atravesalo ou non é toda a cuestión. Cada salto de abaixo nomea o dispositivo e o conxunto de regras que actúa alí, de modo que un filtro ausente aparece como un oco en lugar de quedar insinuado por unha liña.

1. Cliente remoto: o dispositivo do usuario que orixina o túnel.
2. Política de borde: o conxunto de regras que admite o transporte externo ao listener público.
3. Dispositivo terminador: o extremo VPN que desencapsula e entrega o paquete á IP ordinaria.
4. Filtro interno: o conxunto de regras de reenvío ou de grupos de seguridade que limita o tráfico de cliente a servizo.
5. Host de aplicación: o servizo que recibe a solicitude descifrada.

Dúas políticas, dous propietarios

A política externa responde quen pode establecer un túnel, e exprésase nas regras que admiten o transporte cara ao servizo terminador. A política interna responde a que servizo pode chegar un usuario autenticado, e vive en regras de reenvío, grupos de seguridade ou a propia aplicación. Un só dispositivo pode aloxar ambas, e un deseño con varios dispositivos segue tendo ambas. Nomealas por separado é o que che permite dicir cal fallou cando un usuario non chega a unha aplicación.

Os controis de admisión como os certificados e a autenticación multifactor responden á identidade e a nada máis. Non deciden a ubicación e non conceden permiso por recurso unha vez que o usuario está dentro.

A ubicación decide que fronteira atravesa a solicitude

Tres ubicacións son habituais, e cada unha cambia que fronteira atravesa a solicitude descifrada. Compáraas polo que termina alí, que pode ver o texto plano, que control aínda pode denegar a solicitude e que falla xunto co dispositivo. A táboa de abaixo usa esas catro columnas en lugar dunha pregunta xenérica, porque cada resposta é unha decisión de deseño separada.

A terceira ubicación é a que elimina a aplicación en silencio, porque un tramo no segmento protexido dálle ao dispositivo unha ruta directa que o diagrama quizais non mostra. Inspecciona as interfaces e as rutas en lugar da imaxe: ip route get 10.20.5.10 informa por que interface sairía o paquete, e a resposta a miúdo non é a que supuxo o deseño. O papel clásico do cortalumes de controlar o tráfico entre posturas, como se describe enNIST SP 800-41, é unha proba útil aquí, porque un dispositivo cun tramo sen restricións cara á rede protexida non controla moito. Unha consulta de ruta é un diagrama máis honesto que o da presentación.

A administración pertence á súa propia ruta explicitamente permitida. Permitir que os usuarios cheguen a unha aplicación nunca esixe permitirlles chegar á interface de control do dispositivo, e ambos permisos deben concederse con regras distintas. Audita ambas rutas por separado, porque unha regra compartida oculta cal se abriu.

A tradución cambia o que poden ver as regras posteriores

A tradución de orixe é cómoda e destrúe información. Tras o masquerade cada cliente parece o dispositivo, así que unha regra posterior escrita para distinguir usuarios xa non pode facelo. Non é só un problema de rexistro, é un problema de política: unha regra baseada no enderezo do cliente convértese en silencio nunha regra baseada na pasarela. Se a política por usuario importa, conserva a orixe ou aplica a política antes da tradución.

A ruta de resposta merece o mesmo escrutinio. Rexistra que ruta escolle o destino para o paquete de volta, porque un retorno asimétrico evita a inspección con estado e produce unha conexión que se establece e logo se atasca. Ambas direccións teñen que cruzar a fronteira que debuxaches, ou a fronteira é decoración.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Acepta unha operación permitida e unha denegada

Proba desde o cliente remoto real e non desde un host de xestión, porque o host de xestión adoita estar nun sitio onde o usuario nunca estará. Unha operación permitida demostra que a ruta funciona, e unha denegada demostra que a política fai algo. Executa ambas tras cada cambio de ubicación e rexistra a identidade de orixe e o destino que usaches. Unha proba que só demostra éxito non distingue unha regra correcta dunha ausente.

Logo proba os casos que cambian de estado: unha reconexión, unha sesión que sobrevive a unha rotación de chaves e un fallo do propio dispositivo. Compara actualizacións, capacidade e recuperación como parte do mesmo deseño, porque un dispositivo que sostén varios controis lóxicos é un só dominio de fallo con varias etiquetas. Unha segunda caixa tampouco é independente cando unha credencial administrativa compartida ou unha ruta sen restricións derrota a fronteira que debía crear.

Documenta o extremo, a ruta descifrada e o control que a restrinxe. Esas tres liñas seguen tendo sentido chámese como se chame a implementación.