Ping nav pierādījums: pārbaudiet ceļu starp divām vietām

Pings no vārtejas neko nepasaka par pakalpojumu. Ejiet ceļu no īsta klienta, izmantojiet lietotnes protokolu un atkārtojiet izmēru vai nosaukumu, kas neizdodas.

Tunelis ir uzcelts, vārtejas atbild viena otrai, un tomēr vienas vietas lietotāji joprojām nevar atvērt otras vietas failu koplietojumu. Kāds izdara ping no vārtejas, saņem atbildi un pasludina tīklu veselu. Šī atbilde ceļoja starp divām ierīcēm, kas nekad nebija problēma. Noderīgs tests sākas uz resursdatora, kuram vajadzīgs pakalpojums, izmanto protokolu, ko izmanto lietotne, un atkārto nosacījumu, kuros tas neizdodas. Viss pārējais ir zaļa gaisma ceļam, pa kuru neviens neiet.

Sāciet ar klientu, kuram vajadzīgs pakalpojums

Pirms kaut ko testēt, pierakstiet četras lietas: klienta adresi, galamērķa adresi, resursdatora nosaukumu un lietotnes portu. Pēc tam apstipriniet, ka pakalpojums darbojas lokāli savā vietā, no blakus esoša resursdatora. Bez šīs bāzes līnijas jūs nevarat atšķirt salauztu tuneli no salauzta pakalpojuma, un puse no šiem biļetēm ir otrais gadījums.

Izmēģiniet dokumentēto resursdatora nosaukumu un, kur pakalpojums atļauj, tiešu tā paša porta adreses pārbaudi. Neizdevusies nosaukuma meklēšana un nesasniedzama atrisinātā adrese ved pa dažādiem ceļiem. Ja aizstājat resursdatora nosaukumu ar IP, neizslēdziet HTTPS identitātes pārbaudi, lai tas darbotos; sertifikāta brīdinājums ir informācija, nevis šķērslis.

Ejiet ceļu katrā malā

Izlasiet maršrutu, ko izvēlas klients, pēc tam maršrutu, ko izvēlas vārteja šim galamērķim, pēc tam skaitītājus vai ierobežotu uztveršanu katrā malā. Jūs meklējat divus faktus: vai pieprasījums nonāca attālajā LAN, un vai atbilde atgriezās. Interfeisa skaitītāji ietver katru citu plūsmu, tāpēc korelējiet pēc precīza laikspiedola un adrešu pāra, nevis pēc grafika formas. Uztveršana nepareizajā malā ir sliktāka par nekādu, jo tā izskatās pēc pierādījuma.

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

Ja pieprasījums parādās attālajā malā bez atbildes aiz tā, problēma ir otrā pusē: ugunsmūris, trūkstošs atgriešanās maršruts vai resursdators, kas nepieņem avotu. Ja pieprasījums nekad neparādās, vietējais maršruts vai tuneļa selektori to nav pārnesuši, un otrā puse vēl nav izmeklēšanas vērta.

Izmantojiet protokolu, ko izmanto lietotne

ICMP ir vāja pārbaude. To var filtrēt, ierobežot ātrumā vai apstrādāt ar citādu politiku nekā pakalpojumu, kas padara gan tā panākumus, gan neveiksmi divdomīgus. Testējiet faktisko portu un, kur iespējams, faktisko protokola roku paspiešanu.

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

Pabeigta TCP roku paspiešana pierāda sasniedzamību un politiku šim portam. Tā nepierāda, ka lietotne darbojas: autentifikācija, augšupielāde vai konkrēts API izsaukums joprojām var neizdoties. Testējiet darbību, ko lietotāji faktiski veic, izmantojot nekaitīgu ekvivalentu, nevis atkārtoti iesniedzot īstu darījumu.

Atkārtojiet nosacījumu, kuros tas neizdodas

Neveiksmes, kas parādās tikai lielos pārraidēs, ir izmēra problēma, nevis savienojamības. Nosūtiet lielu paketi ar iestatītu don't-fragment bitu un vērojiet, kur tā apstājas. Ja mazs pieprasījums izdodas un liels iestrēgst, tuneļa MTU un MSS apstrāde vārtejās ir nākamie aizdomās turamie.

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

Ja neizdodas tikai viena apakštīkla, apskatiet trafika selektorus, maršrutu paziņojumus un šīs apakštīklas atgriešanās vārteju. Ja neizdodas tikai resursdatora nosaukums, sekojiet DNS, tostarp to, kuru risinātāju klients izmantoja un vai attālais skats ir redzams no šīs vietas. Trīs dažādas kļūmes, trīs dažādi labojumi, un ping tests nevienu no tām neatšķir.

Pēc labojuma atkārtojiet to pašu testu

Palaidiet vēlreiz to pašu klientu, galamērķi, portu un slodzi. Pēc tam pievienojieties no jauna vai izmēģiniet rezerves ceļu, ja dizainā tāds ir, jo labojums, kas darbojas tikai tik ilgi, kamēr dzīva sākotnējā tuneļa instance, nav pārbaudīts. Turiet testu saistītu ar īstu avotu, īstu galamērķi un īstu darbību, nevis ar vienu zaļu indikatoru informācijas panelī.

Pierakstiet četras bāzes vērtības un rezultātu. Nākamais ziņojums par to pašu simptomu tad varēs sākties ar pierādījumiem, nevis ar ping.

Saistītie raksti