Ping er ikke bevis: test vejen mellem to lokationer

Tunnelen er oppe, gatewayerne svarer hinanden, og brugerne på den ene lokation kan stadig ikke åbne fildelingen på den anden. Nogen pinger fra gatewayen, får et svar og erklærer netværket sundt. Det svar rejste mellem to enheder, som aldrig var problemet. En brugbar test starter på den vært, der har brug for tjenesten, bruger den protokol, applikationen bruger, og genskaber den betingelse, hvorunder den fejler. Alt andet er grønt lys for en vej, ingen er på.

Begynd ved den klient, der har brug for tjenesten

Skriv fire ting ned, før du tester noget: klientadressen, destinationsadressen, værtsnavnet og applikationens port. Bekræft derefter, at tjenesten virker lokalt på sin egen lokation, fra en vært ved siden af. Uden den baseline kan du ikke skelne en brudt tunnel fra en brudt tjeneste, og halvdelen af disse sager er den anden.

Prøv det dokumenterede værtsnavn og, hvor tjenesten tillader det, et direkte adressetjek af samme port. Et mislykket navneopslag og en uopnåelig opløst adresse sender dig ad forskellige veje. Hvis du erstatter et værtsnavn med en IP, må du ikke slå HTTPS-identitetstjekket fra for at få det til at virke; en certifikatadvarsel er information, ikke en forhindring.

Gå vejen ved hver kant

Læs den rute, klienten vælger, derefter den rute, gatewayen vælger for den destination, derefter tællerne eller en afgrænset optagelse ved hver kant. Du leder efter to fakta: nåede anmodningen det fjern e LAN, og kom der et svar tilbage. Interfacetællere omfatter enhver anden strøm, så korrelér efter præcist tidsstempel og adressepar i stedet for grafens form. En optagelse ved den forkerte kant er værre end ingen, fordi den ligner bevis.

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

Hvis anmodningen dukker op ved den fjerne kant uden et svar bag sig, er problemet på den anden side: en firewall, en manglende returrute eller en vært, der ikke accepterer kilden. Hvis anmodningen aldrig dukker op, har den lokale rute eller tunnelvælgerne ikke båret den, og den anden side er endnu ikke værd at undersøge.

Brug den protokol, applikationen bruger

ICMP er en svag sonde. Den kan filtreres, hastighedsbegrænses eller håndteres af en anden politik end tjenesten, hvilket gør både dens succes og dens fiasko tvetydig. Test den faktiske port og, hvor du kan, det faktiske protokolhåndtryk.

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

Et fuldført TCP-håndtryk beviser nåbarhed og politik for den port. Det beviser ikke, at applikationen virker: godkendelse, en upload eller et bestemt API-kald kan stadig fejle. Test den handling, brugerne faktisk udfører, med en uskadelig ækvivalent i stedet for gentagne gange at indsende en rigtig transaktion.

Genskab den betingelse, der fejler

Fejl, der kun viser sig ved store overførsler, er et størrelsesproblem, ikke et forbindelsesproblem. Send en stor pakke med don't-fragment-bitten sat og se, hvor den stopper. Hvis en lille anmodning lykkes, og en stor hænger, er tunnelens MTU og MSS-håndteringen på gatewayerne de næste mistænkte.

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

Hvis kun et undernet fejler, se på trafikvælgere, ruteannonceringer og det undernets returgateway. Hvis kun værtsnavnet fejler, følg DNS, inklusive hvilken resolver klienten brugte, og om fjernvisningen er synlig fra den lokation. Tre forskellige fejl, tre forskellige rettelser, og pingtesten skelner ikke en af dem.

Efter rettelsen gentages den samme test

Kør den identiske klient, destination, port og nyttelast igen. Genopret derefter forbindelsen, eller prøv failover-vejen, hvis designet har en, fordi en rettelse, der kun virker, mens den oprindelige tunnelinstans er i live, ikke er testet. Hold testen knyttet til en rigtig kilde, en rigtig destination og en rigtig handling i stedet for en grøn indikator på et dashboard.

Notér de fire basisværdier og resultatet. Den næste rapport om samme symptom kan derefter begynde med bevis i stedet for med et ping.