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.com

Logo 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-numbers

Ningunha 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.

Artigos relacionados