Uma única página de navegador que mostra um endereço IP não prova quase nada sobre um túnel dividido. Um endereço visível pode ser o certo pelo motivo errado, e um fluxo excluído nunca é exercitado por ela. Anote o resultado esperado antes de testar: qual aplicação ou destino deve usar o túnel, qual deve permanecer direto e o que deve parar quando o túnel falhar. Sem esse plano, qualquer número plausível parece sucesso.

O mito: uma consulta de endereço prova cobertura

A verificação de IP responde a uma pergunta: o que o mundo externo vê de uma aplicação num instante. Não diz nada sobre um prefixo interno, um segundo perfil de navegador ou um nome que deveria ser resolvido em privado. Também não diz nada sobre a falha, e essa é a metade de um projeto de túnel dividido que quebra em produção.

Uma página de endereço também não consegue mostrar a rota, o resolvedor ou a política de falha. Trate-a como uma observação, não como um veredicto.

Exercite um fluxo incluído e um excluído

Envie uma requisição inofensiva a partir da aplicação que deve ser incluída, ou para o prefixo que espera encaminhar pelo túnel, e registre a origem, o destino, a família de endereços e o caminho observado. Faça o mesmo para um fluxo que deve permanecer direto. O lado excluído é o que as pessoas pulam, e é a única prova de que a divisão é deliberada e não acidental. Um processo auxiliar pode carregar uma identidade de política separada, então teste no processo que possui o socket.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

É por isso que um teste executado na aplicação errada pode mostrar o oposto do que o projeto pretende. Anote os quatro campos para os dois lados antes de tirar qualquer conclusão.

Acrescente o DNS e o caso de falha

Consulte o resolvedor do sistema e o resolvedor que a aplicação usa, e depois compare essas respostas com o endereço de saída que o site informa. As duas camadas podem divergir por projeto, e uma única consulta do navegador não exercita a política do sistema operacional. Um shell torna a comparação repetível: Quebre o túnel de propósito, depois faça uma requisição que o navegador não tenha em cache; uma página servida do cache não diz nada sobre para que lado foi o fallback. Registre o que realmente aconteceu em vez do que o projeto previa.

curl -s https://ifconfig.me
nslookup intranet.example

Um túnel dividido que falha fechado e um que falha aberto parecem idênticos até você quebrar o túnel de propósito. Registre qual comportamento observou, não qual esperava.

Repita depois da mudança de estado

Repita as mesmas observações depois de uma reconexão, uma troca de rede e uma atualização relevante da aplicação. Uma exclusão armazenada pode continuar apontando para um caminho ou uma identidade de aplicação que já não existe, e o projeto deixa em silêncio de corresponder à sua documentação. Esses três eventos são onde os túneis divididos derivam, e cada um deles é barato de testar de novo. Um teste que só roda uma vez na implantação descreve uma configuração que já não existe.

Se um resultado diferir, encontre o dono da regra e o estágio de processamento antes de mudar várias configurações ao mesmo tempo. Mudar cinco coisas e observar um resultado não é um diagnóstico, é uma configuração nova.

O que o resultado deve estabelecer

Vincule as observações à política e à versão de cliente que você realmente testou. O objetivo é mostrar que esta implantação corresponde à cobertura que afirma, não que toda aplicação futura será privada. É uma afirmação mais estreita, e é a que você realmente pode sustentar com evidências. Escreva a afirmação, a versão e os resultados de quatro campos no registro de mudanças.

Assim, o próximo revisor consegue dizer se mudou o projeto ou o teste. Um túnel dividido é verificado quando os dois lados, a divisão do resolvedor e o comportamento de falha correspondem ao que você anotou no início. Um único resultado de IP não verifica nenhum deles.

Artigos relacionados