Por que os resultados da varredura de portas mudam atrás de uma saída VPN?
Mude a saída e uma porta pode responder de forma diferente sem que o serviço saia do lugar. Separe a observação do caminho do inventário de que você realmente precisa.
Execute a mesma verificação de porta a partir de uma linha de escritório e de uma saída VPN, e as duas respostas podem discordar sobre um endereço que ninguém mudou. Essa diferença vem da rota e de qual host respondeu, não de o serviço estar no ar ou fora do ar. Três perguntas separam essas explicações: o que a sonda realmente perguntou, qual host respondeu e o que o seu próprio servidor registrou. Percorra-as nessa ordem e escreva cada resposta antes de passar para a próxima.
Corrija a sonda antes de comparar duas execuções
Uma palavra de estado só é comparável a outra palavra de estado quando ambas saíram do mesmo experimento. Cinco campos fixam isso: o endereço de origem que o lado remoto viu, o destino resolvido, a porta, o tipo de varredura e a hora. Mude qualquer um deles e você fez um segundo experimento em vez de medir o primeiro duas vezes.
Verifique a origem antes de tudo, porque um cliente VPN pode estar ativo enquanto o tráfego ainda sai pela interface física. Pergunte ao lado remoto o que ele vê e depois pergunte ao kernel qual interface ele escolheu:
curl -s https://ifconfig.me
ip route get 203.0.113.20Dois endereços em redes diferentes significam que a explicação já está na mão, e o resto dessas verificações só vai confirmá-la. Quando concordarem, capture a sonda com o sinalizador de motivo ligado, para que o estado volte ligado a uma explicação em vez de ficar sozinho como uma palavra nua. O tipo de varredura também pertence a esse registro, porque descreve o que foi perguntado e não o que voltou. Um estado sem origem, sem método e sem carimbo de tempo não pode ser comparado com nada:
nmap -sT -p 443,8443 --reason 203.0.113.20Guarde essa saída ao lado do registro e não em um buffer de rolagem que a próxima pessoa não pode ver. Duas varreduras honestas que discordam só são uma discussão quando ninguém escreveu as condições. Com as condições fixadas, ou os resultados coincidem e a questão se encerra, ou eles diferem e a diferença é um fato sobre o caminho.
Descubra qual host terminou o aperto de mão
Um aperto de mão concluído prova que algum host o concluiu, e esse host não precisa ser o processo que você tem em mente. Um balanceador de carga, um proxy reverso ou um proxy SYN podem responder antes que o servidor real entre em ação, o que é projeto comum e não sintoma. Um certificado válido para o nome esperado também não restringe isso, porque um certificado descreve uma relação de serviço e não diz nada sobre qual máquina encerrou a conexão.
A referência de estados de porta do Nmap trata isso como básico: um estado registra o que uma sonda pôde observar de onde foi enviada, não uma propriedade da porta. Leia uma palavra de estado assim e duas execuções que discordavam começam a parecer consistentes em vez de contraditórias, enquanto a pergunta passa de se a porta está aberta para quem estava na frente dela.
Responda à segunda pergunta no backend e não de fora. Um frontend que aceita conexões e depois não alcança o seu upstream produz exatamente a imagem externa de um serviço saudável com uma aplicação lenta. Só o registro do próprio upstream separa os dois casos:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'A linha de log mostra o endereço de cliente que a aplicação realmente viu, e o segundo comando mostra se o processo que mantém a porta 443 é a sua aplicação ou algo à frente dela. Se os dois discordarem sobre qual endereço se conectou, você está olhando para duas pernas de uma mesma requisição e o ticket deveria dizer isso.
Verifique as suas próprias regras antes de culpar o túnel
A política deliberada é o motivo mais comum de uma porta responder em uma rede e não em outra, e é a explicação menos interessante disponível. Regras de acesso existem para permitir uma origem e descartar o resto, então uma mudança de saída é exatamente o evento para o qual elas foram escritas. Por isso um estado diferente através de uma VPN não mostra que o provedor inspeciona o tráfego. Mostra que o seu endereço de origem agora é diferente, o que é uma afirmação muito menor.
Essas regras podem ser lidas no servidor, então leia-as em vez de especular sobre o meio da rede. Liste as regras de filtro que mencionam qualquer uma das duas faixas de endereços e depois verifique se a conexão chegou ao daemon:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Um segundo resultado vazio é informativo, porque nada chegou ao daemon e a pergunta pertence a um filtro, a um grupo de segurança ou ao próprio caminho. Um acerto significa que o serviço viu a sua origem e escolheu a sua resposta, e essa decisão costuma estar escrita em uma regra que você pode ler. Nenhum dos dois resultados sustenta uma história sobre o provedor, e ambos são mais baratos de verificar do que uma captura de pacotes.
Leia transporte, certificado e resposta separadamente
Três camadas produzem três observações, e uma sonda que testa uma delas não pode informar sobre as outras duas. Mantenha-as como linhas separadas no registro em vez de dobrá-las em um único veredito, porque cada linha falha à sua maneira e o modo de falha diz onde olhar em seguida.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Um único comando produz as três primeiras linhas contra um serviço que você controla. Coloque a saída no registro ao lado da varredura e não em uma mensagem de chat:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Leia a saída em ordem: o aperto de mão responde à pergunta de transporte, o assunto do certificado à pergunta do nome e o corpo da resposta à pergunta da aplicação. Quando a linha do aperto de mão tem sucesso e a da resposta não, você tem um frontend com upstream quebrado e não uma porta bloqueada. Esse é um ticket diferente do que você abriu, e vale a pena dizer isso claramente.
Termine escrevendo quatro fatos no ticket: endereço de origem, tipo de varredura, o host que respondeu e a hora. Tudo de que uma comparação posterior precisa vive nesses quatro, e quem pegar o caso depois não terá o histórico do seu terminal. Se você não consegue preencher os quatro, a execução não terminou.