O que um firewall corporativo pode e não pode ver dentro de uma VPN
Um firewall pode bloquear um túnel e mesmo assim não ler o seu interior. Verifique o que o cabeçalho externo expõe, se a inspeção TLS se aplica e valide a cadeia.
O mesmo portátil chega à VPN de casa e não consegue ligar-se a partir do escritório, portanto alguém deve estar a ler o tráfego. Bloquear e ler são poderes separados, e só o segundo precisa de um ponto no caminho mais um certificado em que o cliente confia. Um elemento intermédio que descarta o seu handshake não aprendeu nada sobre o que teria enviado. Decidir qual dos dois tem à frente é todo o trabalho.
Bloquear e ler são poderes diferentes
Uma recusa é barata e ruidosa: o socket abre-se e nada responde, ou chega um reset de imediato. Nada disso implica inspeção, porque nenhuma carga atravessou o cabo.
Ler exige um ponto final que termine a proteção, se prove com um certificado e inicie uma ligação nova em frente. Esse ponto tem de estar no caminho e ser de confiança para o cliente. Um firewall que apenas reencaminha pacotes não tem posição nem credencial.
O que a embalagem oferece de graça
Cada pacote do túnel tem um exterior, e o exterior tem de ser encaminhável. Isso significa dois endereços, um protocolo, uma porta e um comprimento, além de tempos e volume. Qualquer router já trata esses campos, e um NAT reescreve o endereço e a porta para manter a sua tabela de mapeamento coerente. A carga continua selada, por isso a observação para no facto de existir um túnel entre dois anfitriões.
Um nome de anfitrião não está entre eles. Os sites escapam por outras portas, e a mais larga é o DNS: se o portátil ainda pergunta ao resolver local, os nomes aparecem em claro.
Os tempos e o volume merecem respeito sem exagero. Bytes por minuto podem mostrar que uma transferência grande começa às 14:20; não podem mostrar que ficheiro se moveu. É uma revelação real sobre o comportamento, e uma categoria diferente de ler conteúdo.
A interceção TLS exige uma raiz em que já confia
Um aparelho de inspeção não quebra o TLS; termina-o. O cliente recebe como resposta um certificado de uma raiz que a organização possui, e uma segunda ligação segue para o destino real. O cliente aceita isto porque essa raiz está no seu armazenamento de confiança, e é por isso que um portátil gerido não mostra qualquer aviso. A criptografia nunca foi derrotada; o ponto final foi deslocado.
É também por isso que a disposição deixa provas. O emissor da cadeia apresentada pertence à organização e não a uma CA pública, e um cliente consegue vê-lo sem ferramentas especiais. Uma cadeia que termina numa raiz interna é a assinatura da interceção, não uma avaria.
Porque um canal VPN não é uma sessão HTTPS
Um canal de dados VPN não dá ao inspetor esse ponto de apoio. O IKEv2 e o WireGuard executam os seus próprios handshakes e calendários de chaves, sem TLS para terminar, enquanto o OpenVPN pede TLS emprestado para o seu canal de controlo de forma modificada antes de proteger os dados à sua maneira. Um proxy feito para HTTPS não reconhece essa sessão como algo que consiga analisar.
Um aparelho que não consegue analisar uma sessão continua a poder descartá-la. É por isso que o bloqueio de VPN costuma parecer um tempo limite e não um aviso de certificado, e por isso uma exceção não muda nada.
Verifique a partir da sua própria máquina
Comece pela cadeia que o site apresenta. Os detalhes do site no navegador mostram o emissor, e a linha de comandos relata o mesmo sem o resumo:
openssl s_client -connect example.com:443 -servername example.comDepois separe um handshake recusado do tráfego interno filtrado com contadores. Registe a porta de transporte antes de qualquer regra de descarte e leia-os depois da tentativa:
iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbersNenhuma linha de registo no socket exterior significa que o handshake nunca saiu, logo o caminho recusa o túnel. Um handshake concluído com apenas alguns destinos a falhar significa que o túnel funciona e a política lá dentro não. Nenhum dos resultados exigiu ler um byte de carga.
A leitura que realmente acontece está nas margens: um túnel dividido entrega o HTTPS interno a um proxy corporativo, e um concentrador propriedade da entidade empregadora expõe tudo à saída. Encontre o que encontrar, não desative a verificação de certificados para forçar uma ligação, porque essa verificação é a única coisa que separa a inspeção de um atacante.