Que pode e que non pode ver un firewall corporativo dentro dunha VPN
Un firewall pode bloquear un túnel e aínda así non ler o seu interior. Comproba que expón a cabeceira externa, se se aplica a inspección TLS e verifica a cadea.
O mesmo portátil chega á VPN desde casa e non pode conectarse desde a oficina, así que alguén debe estar lendo o tráfico. Bloquear e ler son poderes separados, e só o segundo necesita un punto no camiño máis un certificado no que o cliente confíe. Un elemento intermedio que descarta o teu handshake non aprendeu nada sobre o que enviarías. Decidir con cal dos dous te enfrontas é todo o traballo.
Bloquear e ler son poderes distintos
Un rexeitamento é barato e ruidoso: o socket ábrese e nada responde, ou chega un reset de inmediato. Nada diso implica inspección, porque ningunha carga cruzou o cable.
Ler require un punto final que remate a protección, se acredite cun certificado e abra unha conexión nova cara adiante. Ese punto debe estar no camiño e ser de confianza para o cliente. Un firewall que só reenvía paquetes non ten nin posición nin credencial.
Que regala a envoltura
Cada paquete do túnel ten un exterior, e o exterior debe ser enrutábel. Iso significa dúas direccións, un protocolo, un porto e unha lonxitude, ademais de tempos e volume. Calquera router xa xestiona eses campos, e un NAT reescribe a dirección e o porto para manter coherente a súa táboa de mapeo. A carga segue selada, así que a observación detense no feito de que existe un túnel entre dous hosts.
Un nome de host non está entre eles. Os sitios fíltranse por outras portas, e a máis ancha é DNS: se o portátil aínda pregunta ao resolutor local, os nomes aparecen en claro.
Os tempos e o volume merecen respecto sen esaxeralos. Bytes por minuto poden mostrar que unha transferencia grande comeza ás 14:20; non poden mostrar que ficheiro se moveu. É unha revelación real sobre o comportamento, e unha categoría distinta de ler contido.
A interceptación TLS necesita unha raíz na que xa confíes
Un aparello de inspección non rompe TLS; remátao. Ao cliente respóndelle un certificado dunha raíz que posúe a organización, e unha segunda conexión vai ao destino real. O cliente acepta isto porque esa raíz está no seu almacén de confianza, e por iso un portátil xestionado non mostra ningún aviso. A criptografía nunca foi derrotada; moveuse o punto final.
Tamén por iso o montaxe deixa probas. O emisor da cadea presentada pertence á organización e non a unha CA pública, e un cliente pode velo sen ferramentas especiais. Unha cadea que remata nunha raíz interna é a sinatura da interceptación, non unha avaría.
Por que unha canle VPN non é unha sesión HTTPS
Unha canle de datos VPN non lle dá ao inspector ese punto de apoio. IKEv2 e WireGuard executan os seus propios handshakes e calendarios de claves, sen TLS que rematar, mentres que OpenVPN toma prestado TLS para a súa canle de control nunha forma modificada antes de protexer os datos á súa maneira. Un proxy feito para HTTPS non recoñece esa sesión como algo que poida analizar.
Un aparello que non pode analizar unha sesión aínda pode descartala. Por iso o bloqueo de VPN adoita parecer un tempo de espera e non un aviso de certificado, e por iso unha excepción non cambia nada.
Comprobalo desde a túa propia máquina
Comeza pola cadea que presenta o sitio. Os detalles do sitio no navegador mostran o emisor, e a liña de ordes informa do mesmo sen o resumo:
openssl s_client -connect example.com:443 -servername example.comLogo separa un handshake rexeitado do tráfico interno filtrado con contadores. Rexistra o porto de transporte antes de calquera regra de descarte e lédeos despois do intento:
iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbersNingunha liña de rexistro no socket exterior significa que o handshake nunca saíu, así que o camiño rexeita o túnel. Un handshake completado con só algúns destinos fallando significa que o túnel funciona e a política interior non. Ningún dos dous resultados esixiu ler un byte de carga.
A lectura que si ocorre está nos bordos: un túnel dividido entrega o HTTPS interno a un proxy corporativo, e un concentrador propiedade da empresa expón todo na saída. Atopes o que atopes, non desactives a verificación de certificados para forzar unha conexión, porque esa comprobación é o único que separa a inspección dun atacante.