Ping non é unha proba: probe o camiño entre dúas sedes

Un ping desde a pasarela non di nada do servizo. Percorra o camiño desde un cliente real, use o protocolo da aplicación e reproduza o tamaño ou o nome que falla.

O túnel está activo, as pasarelas respóndense e os usuarios dunha sede seguen sen poder abrir o recurso compartido da outra. Alguén fai ping desde a pasarela, obtén resposta e declara a rede san. Esa resposta viaxou entre dous dispositivos que nunca foron o problema. Unha proba útil comeza no host que necesita o servizo, usa o protocolo que usa a aplicación e reproduce a condición na que falla. Todo o demais é luz verde para un camiño que ninguén percorre.

Comece no cliente que necesita o servizo

Anote catro cousas antes de probar nada: o enderezo do cliente, o enderezo de destino, o nome de host e o porto da aplicación. Despois confirme que o servizo funciona localmente na súa propia sede, desde un host contiguo. Sen esa liña base non pode distinguir un túnel roto dun servizo roto, e a metade destes casos son o segundo.

Probe o nome de host documentado e, onde o servizo o permite, unha comprobación de enderezo directa do mesmo porto. Unha busca de nome fallida e un enderezo resolto inalcanzable lévanlle por camiños distintos. Se substitúe un nome de host por un IP, non desactive a comprobación de identidade HTTPS para que funcione; un aviso de certificado é información, non un obstáculo.

Percorra o camiño en cada extremo

Lea a ruta que escolle o cliente, despois a ruta que escolle a pasarela para ese destino, despois os contadores ou unha captura acoutada en cada extremo. Busca dous feitos: se a petición chegou á LAN remota e se volveu unha resposta. Os contadores de interface inclúen todos os demais fluxos, así que correlacione por marca de tempo exacta e par de enderezos en lugar de pola forma do gráfico. Unha captura tomada no extremo equivocado é peor que ningunha, porque parece unha proba.

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 a petición aparece no extremo remoto sen resposta detrás, o problema está no outro lado: un devasado, unha ruta de retorno ausente ou un host que non acepta a orixe. Se a petición nunca aparece, a ruta local ou os selectores do túnel non a transportaron, e o outro lado aínda non merece a investigación.

Use o protocolo que usa a aplicación

ICMP é unha sonda débil. Pódese filtrar, limitar por velocidade ou tratar cunha política distinta á do servizo, o que fai ambiguos tanto o seu éxito como o seu fallo. Probe o porto real e, cando poida, o apretón de mans 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

Un apretón de mans TCP completado demostra alcanzabilidade e política para ese porto. Non demostra que a aplicación funcione: a autenticación, unha carga ou unha chamada API concreta aínda poden fallar. Probe a operación que os usuarios realizan de verdade, cun equivalente inofensivo en lugar de enviar repetidamente unha transacción real.

Reproduza a condición que falla

Os fallos que só aparecen con transferencias grandes son un problema de tamaño, non de conectividade. Envíe un paquete grande co bit don't-fragment activado e observe onde se detén. Se unha petición pequena ten éxito e unha grande se colga, a MTU do túnel e o tratamento de MSS nas pasarelas son os seguintes sospeitosos.

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 só falla unha subrede, mire os selectores de tráfico, os anuncios de rutas e a pasarela de retorno desa subrede. Se só falla o nome de host, siga o DNS, incluído que resolutor usou o cliente e se a vista remota é visible desde esa sede. Tres fallos distintos, tres solucións distintas, e a proba de ping non distingue ningún.

Despois da corrección, repita a mesma proba

Volva executar o mesmo cliente, destino, porto e carga. Logo reconecte ou exercite a ruta de conmutación por erro se o deseño ten unha, porque unha corrección que só funciona mentres a instancia orixinal do túnel está viva non se probou. Manteña a proba ligada a unha orixe real, un destino real e unha operación real en lugar de a un indicador verde nun panel.

Rexistre os catro valores de base e o resultado. O seguinte informe do mesmo síntoma poderá entón comezar desde probas en lugar de desde un ping.

Artigos relacionados