Ping ei ole tõestus: testi teed kahe asukoha vahel

Tunnel on püsti, lüüsid vastavad üksteisele ja ühe asukoha kasutajad ei saa ikkagi teise asukoha failijagamist avada. Keegi pingib lüüsist, saab vastuse ja kuulutab võrgu terveks. See vastus reisis kahe seadme vahel, mis ei olnud kunagi probleem. Kasulik test algab hostist, mis teenust vajab, kasutab protokolli, mida rakendus kasutab, ja taastab tingimuse, mille korral see ebaõnnestub. Kõik muu on roheline tuli teel, kus kedagi ei ole.

Alusta kliendist, mis teenust vajab

Kirjuta enne mis tahes testimist üles neli asja: kliendi aadress, sihtaadress, hostinimi ja rakenduse port. Seejärel kinnita, et teenus töötab lokaalselt oma asukohas, kõrvalasuvast hostist. Ilma selle baasjooneta ei erista sa katkist tunnelit katkisest teenusest ja pooled neist piletitest on teine juhtum.

Proovi dokumenteeritud hostinime ja, kui teenus lubab, sama pordi otsest aadressikontrolli. Ebaõnnestunud nimeotsing ja kättesaamatu lahendatud aadress viivad sind eri teedele. Kui asendad hostinime IP-ga, ära lülita HTTPS-i identiteedikontrolli välja, et see töötaks; sertifikaadi hoiatus on informatsioon, mitte takistus.

Käi tee läbi igal serval

Loe marsruut, mille klient valib, seejärel marsruut, mille lüüs selle sihtkoha jaoks valib, seejärel loendurid või piiratud püüdmine igal serval. Otsid kahte fakti: kas päring jõudis kaugesse kohtvõrku ja kas vastus tuli tagasi. Liidese loendurid sisaldavad iga teist voogu, seega korreleeri täpse ajatempli ja aadressipaari järgi, mitte graafiku kuju järgi. Valel serval tehtud püüdmine on hullem kui mitte ükski, sest see näeb välja nagu tõend.

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

Kui päring ilmub kaugel serval ilma vastuseta selle taga, on probleem teisel pool: tulemüür, puuduv tagasitee või host, mis ei võta allikat vastu. Kui päringut ei ilmu kunagi, ei kandnud seda kohalik marsruut ega tunneli valijad, ja teine pool ei ole veel uurimist väärt.

Kasuta protokolli, mida rakendus kasutab

ICMP on nõrk sond. Seda saab filtreerida, kiirusega piirata või käsitleda teistsuguse poliitikaga kui teenust, mis muudab nii selle õnnestumise kui ka ebaõnnestumise mitmetähenduslikuks. Testi tegelikku porti ja, kui saad, tegelikku protokolli kättlust.

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

Lõpetatud TCP kättlus tõestab kättesaadavust ja poliitikat selle pordi jaoks. See ei tõesta, et rakendus töötab: autentimine, üleslaadimine või konkreetne API-kutse võib ikkagi ebaõnnestuda. Testi toimingut, mida kasutajad tegelikult teevad, kasutades kahjutut ekvivalenti, mitte korduvalt päris tehingu esitamist.

Taasta tingimus, mis ebaõnnestub

Tõrked, mis ilmnevad ainult suurte ülekannete korral, on suuruse probleem, mitte ühenduvuse probleem. Saada suur pakett don't-fragment bitiga seatud ja vaata, kus see peatub. Kui väike päring õnnestub ja suur jääb rippuma, on tunneli MTU ja MSS-i käsitlemine lüüsides järgmised kahtlusalused.

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

Kui ebaõnnestub ainult üks alamvõrk, vaata liiklusvalijaid, marsruuditeateid ja selle alamvõrgu tagasilüüsi. Kui ebaõnnestub ainult hostinimi, järgi DNS-i, sealhulgas millist lahendajat klient kasutas ja kas kaugvaade on sellest asukohast nähtav. Kolm erinevat riket, kolm erinevat parandust ja ping-test ei erista neist ühtegi.

Pärast parandust korda sama testi

Käivita uuesti sama klient, sihtkoht, port ja kasulik koormus. Seejärel ühenda uuesti või proovi varuteed, kui disainis see on, sest parandus, mis töötab ainult seni, kuni algne tunneli eksemplar elab, ei ole testitud. Hoia test seotud päris allika, päris sihtkoha ja päris toiminguga, mitte ühe rohelise näidikuga armatuurlaual.

Kirjuta üles neli baasväärtust ja tulemus. Järgmine sama sümptomi aruanne saab siis alata tõenditest, mitte pingist.