Ping no és una prova: proveu el camí entre dos llocs

El túnel està aixecat, les passarel·les es responen, i els usuaris d'un lloc encara no poden obrir la carpeta compartida de l'altre. Algú fa ping des de la passarel·la, obté una resposta i declara la xarxa sana. Aquella resposta va viatjar entre dos dispositius que mai van ser el problema. Una prova útil comença a l'amfitrió que necessita el servei, fa servir el protocol que fa servir l'aplicació i reprodueix la condició en què falla. Tota la resta és un llum verd per a un camí que ningú no recorre.

Comenceu pel client que necessita el servei

Anoteu quatre coses abans de provar res: l'adreça del client, l'adreça de destinació, el nom d'amfitrió i el port de l'aplicació. Després confirmeu que el servei funciona localment al seu propi lloc, des d'un amfitrió del costat. Sense aquesta línia base no podeu distingir un túnel trencat d'un servei trencat, i la meitat d'aquests tiquets són el segon.

Proveu el nom d'amfitrió documentat i, on el servei ho permet, una comprovació d'adreça directa del mateix port. Una cerca de nom fallida i una adreça resolta inabastable us porten per camins diferents. Si substituïu un nom d'amfitrió per una IP, no desactiveu la comprovació d'identitat HTTPS perquè funcioni; un avís de certificat és informació, no un obstacle.

Recorreu el camí a cada extrem

Llegiu la ruta que tria el client, després la ruta que tria la passarel·la per a aquesta destinació, després els comptadors o una captura limitada a cada extrem. Cerqueu dos fets: si la petició va arribar a la LAN remota i si va tornar una resposta. Els comptadors d'interfície inclouen tots els altres fluxos, així que correlacioneu per marca de temps exacta i parell d'adreces en lloc de per la forma del gràfic. Una captura presa a l'extrem equivocat és pitjor que cap, perquè sembla 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

Si la petició apareix a l'extrem remot sense cap resposta darrere, el problema és a l'altre costat: un tallafoc, una ruta de retorn que falta o un amfitrió que no accepta l'origen. Si la petició no apareix mai, la ruta local o els selectors del túnel no la van portar, i l'altre costat encara no val la pena investigar-lo.

Feu servir el protocol que fa servir l'aplicació

ICMP és una sonda feble. Es pot filtrar, limitar per velocitat o tractar amb una política diferent de la del servei, cosa que fa ambigus tant l'èxit com el fracàs. Proveu el port real i, quan pugueu, l'encaixada de mans real del protocol.

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 encaixada de mans TCP completada demostra abastabilitat i política per a aquell port. No demostra que l'aplicació funcioni: l'autenticació, una càrrega o una crida API concreta encara poden fallar. Proveu l'operació que els usuaris fan realment, amb un equivalent inofensiu en lloc de tornar a enviar una transacció real.

Reproduïu la condició que falla

Les fallades que només apareixen amb transferències grans són un problema de mida, no de connectivitat. Envieu un paquet gran amb el bit don't-fragment activat i mireu on s'atura. Si una petició petita té èxit i una de gran es penja, l'MTU del túnel i el tractament de l'MSS a les passarel·les són els següents sospitosos.

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

Si només falla una subxarxa, mireu els selectors de trànsit, els anuncis de rutes i la passarel·la de retorn d'aquella subxarxa. Si només falla el nom d'amfitrió, seguiu el DNS, incloent-hi quin resolutor va fer servir el client i si la vista remota és visible des d'aquell lloc. Tres fallades diferents, tres correccions diferents, i la prova de ping no en distingeix cap.

Després de la correcció, repetiu la mateixa prova

Torneu a executar el mateix client, destinació, port i càrrega. Després reconnecteu o proveu el camí de commutació si el disseny en té, perquè una correcció que només funciona mentre la instància original del túnel és viva no s'ha provat. Manteniu la prova lligada a un origen real, una destinació real i una operació real en lloc d'un sol indicador verd en un tauler.

Registreu els quatre valors de base i el resultat. El proper informe del mateix símptoma podrà començar llavors des de proves en lloc d'un ping.