Ping não é prova: teste o caminho entre dois locais

O túnel está ativo, os gateways respondem uns aos outros, e os utilizadores de um local continuam a não conseguir abrir a partilha de ficheiros do outro. Alguém faz ping a partir do gateway, recebe uma resposta e declara a rede saudável. Essa resposta viajou entre dois dispositivos que nunca foram o problema. Um teste útil começa no anfitrião que precisa do serviço, usa o protocolo que a aplicação usa e reproduz a condição em que falha. Tudo o resto é luz verde para um caminho onde ninguém está.

Comece no cliente que precisa do serviço

Anote quatro coisas antes de testar qualquer coisa: o endereço do cliente, o endereço de destino, o nome do anfitrião e a porta da aplicação. Depois confirme que o serviço funciona localmente no próprio local, a partir de um anfitrião ao lado. Sem essa linha de base não consegue distinguir um túnel quebrado de um serviço quebrado, e metade destes casos são o segundo.

Experimente o nome de anfitrião documentado e, onde o serviço o permite, uma verificação direta do endereço da mesma porta. Uma procura de nome falhada e um endereço resolvido inalcançável levam-no por caminhos diferentes. Se substituir um nome de anfitrião por um IP, não desative a verificação de identidade HTTPS para que funcione; um aviso de certificado é informação, não um obstáculo.

Percorra o caminho em cada extremidade

Leia a rota que o cliente escolhe, depois a rota que o gateway escolhe para esse destino, depois os contadores ou uma captura limitada em cada extremidade. Procura dois factos: se o pedido chegou à LAN remota e se voltou uma resposta. Os contadores de interface incluem todos os outros fluxos, por isso correlacione por marca temporal exata e par de endereços em vez da forma do gráfico. Uma captura feita na extremidade errada é pior do que nenhuma, porque parece uma prova.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Se o pedido aparece na extremidade remota sem resposta por trás, o problema está do outro lado: uma firewall, uma rota de retorno em falta ou um anfitrião que não aceita a origem. Se o pedido nunca aparece, a rota local ou os seletores do túnel não o transportaram, e o outro lado ainda não merece a investigação.

Use o protocolo que a aplicação usa

ICMP é uma sonda fraca. Pode ser filtrado, limitado em taxa ou tratado por uma política diferente da do serviço, o que torna ambíguos tanto o seu sucesso como o seu falhanço. Teste a porta real e, quando puder, o aperto de mão real do protocolo.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Um aperto de mão TCP concluído prova alcançabilidade e política para essa porta. Não prova que a aplicação funciona: a autenticação, um carregamento ou uma chamada API específica ainda podem falhar. Teste a operação que os utilizadores realmente executam, com um equivalente inofensivo em vez de submeter repetidamente uma transação real.

Reproduza a condição que falha

Falhas que só aparecem com transferências grandes são um problema de tamanho, não de conetividade. Envie um pacote grande com o bit don't-fragment definido e observe onde para. Se um pedido pequeno tem sucesso e um grande fica pendurado, a MTU do túnel e o tratamento de MSS nos gateways são os próximos suspeitos.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Se falhar apenas uma sub-rede, veja os seletores de tráfego, os anúncios de rotas e o gateway de retorno dessa sub-rede. Se falhar apenas o nome de anfitrião, siga o DNS, incluindo que resolvedor o cliente usou e se a vista remota é visível a partir desse local. Três falhas diferentes, três correções diferentes, e o teste de ping não distingue nenhuma.

Depois da correção, repita o mesmo teste

Execute novamente o mesmo cliente, destino, porta e carga. Depois reconecte ou exercite o caminho de comutação por falha se o desenho tiver um, porque uma correção que só funciona enquanto a instância original do túnel está viva não foi testada. Mantenha o teste ligado a uma origem real, um destino real e uma operação real em vez de a um indicador verde no painel.

Registe os quatro valores de base e o resultado. O próximo relatório do mesmo sintoma poderá então começar por provas em vez de um ping.