O servidor responde na LAN, a regra de encaminhamento de porta parece correta e, mesmo assim, um cliente externo não consegue conectar. Percorrer uma fronteira por vez para fora é mais rápido que editar a regra pela quarta vez, porque cada fronteira deixa a sua própria evidência: a página WAN do router, a tradução do provedor e o ouvinte no host. Comece pela página de administração que já tem aberta e termine com um teste a partir de uma rede que não controla. Anote cada resultado enquanto avança, porque a sequência é o diagnóstico e um número lembrado não é prova. Se só precisa de um túnel de saída, a tradução não é o seu problema: apenas o tráfego de entrada não solicitado é bloqueado.

Comece pela página WAN do router

Entre no router e leia a página de estado em vez da lista de encaminhamentos de porta. Anote o endereço WAN, a interface a que pertence e se o tipo de ligação é DHCP, PPPoE ou algo fornecido pelo provedor. Depois compare esse endereço com o que um serviço externo relata, usando um telemóvel em dados móveis para que a observação não volte pelo mesmo router. Os dois números respondem a perguntas diferentes, e compará-los é todo o objetivo deste passo.

Um endereço WAN diferente do endereço público observado significa que existe pelo menos um tradutor acima do router. Ainda não é uma avaria, porque muitos provedores traduzem por conceção e o serviço continua a funcionar. Se os dois coincidirem, o router provavelmente é dono do endereço e o problema mudou-se para dentro da sua rede. Em qualquer caso, anote o par com a data, porque os provedores reatribuem endereços e uma comparação com as notas do mês passado não vale nada.

Suba um salto

Execute um traceroute a partir do próprio router e leia os primeiros saltos. Endereços públicos repetidos, um primeiro salto que responde com um endereço privado ou um endereço dentro do intervalo partilhado 100.64.0.0/10 apontam todos para um tradutor a montante. RFC 6598 define esse intervalo exatamente para este tipo de implementação, e é por isso que vê-lo no campo WAN é um sinal forte e não uma curiosidade. Dois tradutores no caminho tornam o rasto menos óbvio, por isso leia o padrão e não uma única linha.

Alguns provedores só mostram o endereço atribuído no portal do cliente, por isso olhe lá antes de concluir que o router mente. Um endereço do portal que coincide com a sua observação externa enquanto o router relata outra coisa é a prova mais clara de um tradutor a montante. Guarde as duas páginas no registo de alterações, porque a discussão sobre quem é dono de qual fronteira corre muito mais depressa com duas imagens datadas.

Confirme o ouvinte e o encaminhamento

Um teste na LAN prova que o serviço funciona localmente e não prova nada sobre acessibilidade a partir de fora. Muitos routers respondem à sua própria regra de encaminhamento por dentro, pelo que um teste de hairpin tem sucesso enquanto o caminho externo ainda está fechado. Confirme que o daemon está ligado ao endereço e à porta que presume, e depois teste a partir de fora. Tudo o que segue é apenas de leitura.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Se o teste externo mostrar que nenhum pacote chega ao router, a queda ocorreu a montante e nenhuma regra local a corrige. Se os pacotes chegam e nada responde, a fronteira seguinte é o ouvinte ou a firewall do host. Uma captura de pacotes no host decide qual dos dois está a ver, e leva menos tempo do que outra ronda de adivinhar regras. Mantenha o ouvinte e o seu transporte inalterados durante a comparação, ou o teste seguinte responde a outra pergunta.

Mude a topologia, não a mesma regra

Quando o tradutor é do provedor, a correção é outro caminho e não outro encaminhamento. Um VPS pequeno com endereço público, ligado por um túnel de saída do lado de casa, coloca um extremo alcançável à frente do serviço. Um endereço público fornecido pelo provedor é mais simples onde existe e normalmente mais barato do que manter uma máquina. O IPv6 elimina a tradução por completo, desde que a rede do cliente, os registos DNS e a política da firewall o suportem.

DNS dinâmico apenas atualiza um nome; não cria acessibilidade, e apontá-lo para um endereço partilhado envia os clientes para um gateway do provedor que outros assinantes também usam. Essa falha parece exatamente um servidor morto, e é por isso que o registo dos passos anteriores importa. Anote para que endereço o nome resolveu quando o teste falhou, e guarde a resposta com o resultado do teste.

Reescreva o plano em torno da fronteira que controla: o ouvinte, o túnel e as rotas. Mantenha o encaminhamento antigo apenas enquanto ainda descreve algo verdadeiro, porque uma regra que já não corresponde à topologia é pior do que nenhuma regra. Anote que camada estava realmente a bloquear e que evidência o mostrou. Caso contrário, a próxima pessoa que abrir a página de administração repetirá cada passo deste percurso desde o início.

Artigos relacionados