O HTTP sobre ZeroTier é criptografado? Verifique onde a overlay termina

Percorra estas verificações na ordem e pare na primeira que falhar, porque cada resposta muda o que o passo seguinte significa. A pergunta real é estreita: o HTTP simples numa rede ZeroTier viaja em claro pela internet? Entre dois pares ZeroTier normalmente não, já que a overlay criptografa esse salto. Mas isso é uma afirmação sobre dois endpoints, não sobre cada segmento que um pedido atravessa. Um roteador, uma bridge ou um proxy reverso move o endpoint, e o texto claro recomeça do outro lado dele.

Verificação 1: descubra o endereço que o navegador disca

Compare a URL com o que a máquina realmente tem. ip -brief addr show lista a interface zt e o endereço de overlay atribuído pelo controlador da rede; se a URL usa esse endereço, o socket do navegador entra na overlay.

Quando o nome, em vez disso, resolve para um endereço de LAN, a overlay pode não estar envolvida de modo algum, diga o que disser o indicador de estado do cliente. ip route get 10.147.20.5 imprime a interface e o endereço de origem que o kernel escolheria, então uma interface zt ali significa que o pacote entra na overlay e o nome da sua NIC física significa que não. Os nomes acrescentam outra camada: um registro que aponta para um endereço de overlay se comporta de forma diferente de um que aponta para um endereço de LAN, e um sufixo de busca ou uma entrada no arquivo hosts pode decidir em silêncio qual você recebe.

Verificação 2: confirme que as duas pontas são pares, não um relay que descriptografa

O ZeroTier criptografa entre pares, e onde não existe caminho direto os pacotes são retransmitidos por um root que os encaminha ainda criptografados. zerotier-cli peers marca o caminho de cada par como DIRECT ou RELAY com um número de latência. Um caminho retransmitido custa idas e voltas, não confidencialidade.

O que muda a resposta é um membro que não é realmente um endpoint. Quando o lado oposto é um membro ZeroTier roteando ou fazendo bridge para uma LAN física, a overlay termina nesse membro e o próximo salto é Ethernet comum.

Verificação 3: observe onde o pedido se torna legível

No host que você acredita servir a página, capture a interface de overlay enquanto recarrega: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Uma linha de pedido legível nessa saída prova que o tráfego chegou descriptografado nesse host, e essa é a fronteira que você procura.

Depois capture na interface voltada para o resto da LAN. Se o mesmo pedido aparecer ali em claro, ele deixou a overlay antes de chegar à aplicação e todo dispositivo nesse segmento pode lê-lo. Se nada aparecer do lado da LAN e a página ainda carregar, a aplicação está terminando no próprio host ZeroTier.

Capturar o loopback também importa quando há um proxy reverso à frente, já que um proxy que aceita HTTPS e encaminha HTTP move a fronteira para o seu próprio backend.

Verificação 4: conte cada salto atrás de um roteador ou bridge

Um membro configurado para rotear entre a overlay e uma LAN é um desenho comum e o lugar onde a maioria dessas suposições quebra. A overlay protege o trecho do navegador até o roteador e nada depois disso. Uma bridge conta a mesma história por outro mecanismo: a overlay e o segmento físico se tornam um único domínio de broadcast, então um pedido de um laptop conectado por bridge atravessa Ethernet comum mesmo que esse laptop esteja na rede ZeroTier.

Rastreie em vez de supor. traceroute do cliente até o endereço do serviço mais a tabela de rotas no membro gateway mostra se o último salto é zt ou eth.

O ZeroTier também oferece um modo trusted-path que pode dispensar a segurança de transporte em caminhos locais designados por desempenho. Uma rede que o usa não herda a suposição normal de caminho criptografado, então leia a configuração da rede antes de citar uma. A documentação do protocolo descreve tanto a criptografia entre pares quanto essa exceção.

Verificação 5: decida o que a aplicação ainda precisa fazer

A participação na overlay autentica um dispositivo numa rede e não diz nada sobre se o serviço do outro lado é o que você queria alcançar. O HTTPS responde a outra pergunta ao vincular um nome de host a uma chave, então as duas proteções se sobrepõem sem substituir uma à outra. Um par autorizado ainda pode ser o serviço errado, e um endpoint comprometido lê o pedido tanto antes da criptografia quanto depois da descriptografia. Nenhum dos mecanismos audita o que a aplicação registra.

Para qualquer coisa com sessão reutilizável ou senha, termine o TLS na aplicação ou num proxy que você controla e deixe a validação de certificado ligada. Onde um serviço legado precisa ficar em HTTP simples, anote o caminho exato de host a host que ele pode usar, quem consegue alcançá-lo e qual segmento fica desprotegido; essa nota é o que um revisor futuro precisa.

"A VPN está conectada" não é uma avaliação de nada disso. A versão honesta nomeia as duas pontas, o caminho entre elas e o primeiro salto que não é coberto.

Guarde a saída da captura e a listagem de pares junto da documentação do serviço, para que quem mudar uma rota ou adicionar uma bridge veja qual suposição está prestes a quebrar.