Tras o descifrado: que política ve primeiro o teu tráfico VPN
O cable non di nada sobre que regra procesou o fluxo. Nomea o gancho de política e o seguinte salto, e demostra que a resposta cruza o mesmo camiño.
Un fluxo VPN pode estar perfectamente cifrado e perfectamente autenticado e aínda así acabar onde ninguén o planificou. O cable que conectas non determina que regra procesa o paquete interno; fáino o gancho de política e a ruta. Por iso dous deseños que parecen idénticos nun diagrama de rack poden ter unha aplicación completamente distinta. Escoller entre eles comeza por nomear o control que ve primeiro o fluxo descifrado.
Decide polo gancho de política, non polo porto
Cada plataforma VPN avalia o tráfico descifrado nalgún punto antes de reenvialo, e ese punto ten un nome na configuración. Nunha plataforma é un filtro de política de grupo, noutra unha política de interface ou un par de zonas, e nun aparello que encamiña pode ser simplemente a cadea forward. O gancho é o que aplica a regra, mentres que o porto do conmutador é só onde remata o cable. Atopar o gancho é a primeira decisión, porque todo o demais é colocación respecto del.
Antes de mirar hardware, escribe o fluxo: quen é a orixe, a onde vai, que protocolo o transporta e que servizo está permitido. Logo atopa o control que aplica cada un deses catro feitos.
Dous camiños, dúas historias de aplicación
Dúas formas son comúns e cada unha pode ser correcta para un requisito distinto.
endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnetA primeira forma pode aplicar todo o necesario na porta de enlace, sempre que a política estea escrita para ese destino e o servidor non teña unha ruta que a rodee. A segunda engade unha fronteira, pero só se as rutas e a política fan que o tráfico a atravese de verdade. Un servidor no mesmo segmento que o punto final pode non seguir nunca o salto intermedio imaxinado. O diagrama mostra a intención e a táboa de rutas mostra que ocorre.
Verifica cunha consulta de ruta e non co debuxo. A interface pola que sae un paquete e o seguinte salto que escolle deciden se a segunda forma se comporta como se deseñou.
ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20Separa a topoloxía do illamento
Compartir unha subrede non fai que un lugar sexa pouco fiable, e un tránsito adicado non o fai protexido. O que decide é a restrición realmente aplicada, o reenvío que realmente ocorre e quen administra cada peza. Contar conmutadores non di nada sobre ningún dos tres. Decide desde a política e a ruta, e deixa que a topoloxía siga a decisión.
Trata tamén as poboacións de tráfico por separado. Os grupos de acceso remoto, os prefixos sitio a sitio e as redes de liña privada poden compartir un aparello e necesitar regras distintas, porque a súa identidade e o seu risco difiren. Unha regra escrita para unha poboación cobre en silencio as demais cando comparten un plan de enderezos.
Comproba fallo e xestión en cada emprazamento
Cada emprazamento ten un modo de fallo, e a pregunta útil é que segue funcionando cando un compoñente se detén. Varias interfaces lóxicas nun só equipo morto non dan recuperación independente, e un cortafogos posterior que comparte a mesma alimentación ou o mesmo administrador non é unha segunda fronteira. Pregunta por onde pasa a ruta de xestión, porque unha consola accesible só polo túnel non é ningunha ruta de recuperación; ssh [email protected] true desde fóra do túnel é a forma máis barata de demostrar que a consola non depende del. A documentación de política de grupo dunha plataforma coloca o seu filtro en tráfico posterior ao descifrado e previo ao cifrado, que é exactamente o tipo de gancho nomeado que hai que buscar en calquera produto.
Escribe a historia de fallo de cada candidato xunto á historia de aplicación. Un emprazamento que gaña en inspección e perde en recuperación é un intercambio, e debe rexistrarse como tal en lugar de descubrirse durante un incidente.
Acepta cun fluxo permitido e un denegado
Cun plan de probas aprobado, comproba tres cousas desde a orixe VPN real: unha aplicación que debería funcionar, un recurso que non debería, e a dirección pola que volve a resposta. A denegación é a evidencia de que a política está activa, mentres que o fluxo permitido só demostra que existe un camiño.
Conserva a ruta elixida e o resultado da política xuntos, porque un resultado sen ruta non se pode reproducir e unha ruta sen resultado non se pode defender. Ese par é moito máis útil para escoller un punto de conexión que calquera afirmación sobre que capa de conmutación é intrinsicamente máis segura.