Ping non è una prova: verificate il percorso tra due sedi

Il tunnel è attivo, i gateway si rispondono e gli utenti di una sede non riescono ancora ad aprire la condivisione file dell'altra. Qualcuno esegue un ping dal gateway, riceve una risposta e dichiara la rete sana. Quella risposta ha viaggiato tra due dispositivi che non sono mai stati il problema. Un test utile parte dall'host che ha bisogno del servizio, usa il protocollo che usa l'applicazione e riproduce la condizione in cui fallisce. Tutto il resto è luce verde per un percorso che nessuno sta seguendo.

Partite dal client che ha bisogno del servizio

Annotate quattro cose prima di testare qualsiasi cosa: l'indirizzo del client, l'indirizzo di destinazione, il nome host e la porta dell'applicazione. Poi confermate che il servizio funziona localmente nella propria sede, da un host accanto. Senza questa linea di base non potete distinguere un tunnel rotto da un servizio rotto, e metà di questi ticket è il secondo caso.

Provate il nome host documentato e, dove il servizio lo consente, un controllo diretto dell'indirizzo sulla stessa porta. Una risoluzione del nome fallita e un indirizzo risolto irraggiungibile vi portano su percorsi diversi. Se sostituite un nome host con un IP, non disattivate il controllo di identità HTTPS per farlo funzionare; un avviso di certificato è un'informazione, non un ostacolo.

Percorrete il percorso a ogni estremità

Leggete la rotta che sceglie il client, poi la rotta che sceglie il gateway per quella destinazione, poi i contatori o una cattura circoscritta a ogni estremità. Cercate due fatti: se la richiesta è arrivata sulla LAN remota e se è tornata una risposta. I contatori di interfaccia includono ogni altro flusso, quindi correlate per marca temporale esatta e coppia di indirizzi invece che per la forma del grafico. Una cattura presa all'estremità sbagliata è peggio di nessuna, perché sembra una 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 la richiesta compare all'estremità remota senza una risposta dietro, il problema è dall'altra parte: un firewall, una rotta di ritorno mancante o un host che non accetta l'origine. Se la richiesta non compare mai, la rotta locale o i selettori del tunnel non l'hanno trasportata, e l'altra parte non merita ancora l'indagine.

Usate il protocollo che usa l'applicazione

ICMP è una sonda debole. Può essere filtrato, limitato in velocità o gestito da una politica diversa da quella del servizio, il che rende ambigui sia il suo successo sia il suo fallimento. Testate la porta reale e, quando potete, la stretta di mano reale del protocollo.

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

Una stretta di mano TCP completata dimostra raggiungibilità e politica per quella porta. Non dimostra che l'applicazione funzioni: l'autenticazione, un caricamento o una chiamata API specifica possono ancora fallire. Testate l'operazione che gli utenti eseguono davvero, con un equivalente innocuo invece di inviare ripetutamente una transazione reale.

Riproducete la condizione che fallisce

I guasti che compaiono solo con trasferimenti grandi sono un problema di dimensione, non di connettività. Inviate un pacchetto grande con il bit don't-fragment impostato e osservate dove si ferma. Se una richiesta piccola riesce e una grande si blocca, l'MTU del tunnel e la gestione MSS sui gateway sono i prossimi sospetti.

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 fallisce una sola sottorete, guardate i selettori di traffico, gli annunci di rotta e il gateway di ritorno di quella sottorete. Se fallisce solo il nome host, seguite il DNS, incluso quale resolver ha usato il client e se la vista remota è visibile da quella sede. Tre guasti diversi, tre correzioni diverse, e il test di ping non ne distingue nessuno.

Dopo la correzione, ripetete lo stesso test

Rieseguite lo stesso client, destinazione, porta e carico. Poi riconnettete o provate il percorso di failover se il progetto ne prevede uno, perché una correzione che funziona solo finché l'istanza originale del tunnel è viva non è stata testata. Tenete il test legato a un'origine reale, una destinazione reale e un'operazione reale invece che a un solo indicatore verde su una dashboard.

Registrate i quattro valori di base e il risultato. La prossima segnalazione dello stesso sintomo potrà allora partire da prove invece che da un ping.