Ang ping ay hindi patunay: subukan ang landas sa pagitan ng dalawang site

Buhay ang tunnel, nagtutugon ang mga gateway sa isa't isa, at hindi pa rin mabuksan ng mga user sa isang site ang file share sa isa. May nag-ping mula sa gateway, nakakuha ng tugon at idineklarang malusog ang network. Ang tugon na iyon ay naglakbay sa pagitan ng dalawang device na kailanman ay hindi naging problema. Ang kapaki-pakinabang na pagsubok ay nagsisimula sa host na nangangailangan ng serbisyo, gumagamit ng protocol na ginagamit ng app at nagre-recreate ng kondisyon kung saan ito nabibigo. Lahat ng iba ay berdeng ilaw para sa landas na walang tao.

Magsimula sa kliyenteng nangangailangan ng serbisyo

Isulat ang apat na bagay bago subukan ang anuman: address ng kliyente, address ng destinasyon, hostname at port ng app. Pagkatapos, kumpirmahin na gumagana ang serbisyo nang lokal sa sarili nitong site, mula sa katabing host. Kung wala ang baseline na iyon, hindi mo matutukoy ang sirang tunnel sa sirang serbisyo, at kalahati ng mga ticket na ito ay ang pangalawa.

Subukan ang dokumentadong hostname at, kung pinapayagan ng serbisyo, isang direktang pagsuri ng address ng parehong port. Ang bigong paghahanap ng pangalan at ang hindi maabot na naresolbang address ay nagdadala sa iyo sa magkaibang landas. Kung papalitan mo ng IP ang hostname, huwag patayin ang HTTPS identity check para gumana ito; ang babala sa certificate ay impormasyon, hindi hadlang.

Lakbayin ang landas sa bawat gilid

Basahin ang rutang pinipili ng kliyente, pagkatapos ang rutang pinipili ng gateway para sa destinasyong iyon, pagkatapos ang mga counter o limitadong capture sa bawat gilid. Naghahanap ka ng dalawang katotohanan: nakarating ba ang kahilingan sa malayong LAN, at may tugon bang bumalik. Kasama sa mga interface counter ang lahat ng ibang daloy, kaya iugnay sa eksaktong timestamp at pares ng address sa halip na hugis ng graph. Ang capture sa maling gilid ay mas masama kaysa wala, dahil mukha itong ebidensya.

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

Kung lumitaw ang kahilingan sa malayong gilid na walang tugon sa likod nito, ang problema ay nasa kabilang panig: isang firewall, nawawalang return route o host na hindi tumatanggap ng source. Kung hindi kailanman lumitaw ang kahilingan, hindi ito nadala ng lokal na ruta o ng mga tunnel selector, at ang kabilang panig ay hindi pa karapat-dapat imbestigahan.

Gamitin ang protocol na ginagamit ng app

Mahinang pagsusuri ang ICMP. Maaari itong i-filter, limitahan sa bilis o pangasiwaan ng ibang patakaran kaysa sa serbisyo, na ginagawang malabo ang tagumpay at kabiguan nito. Subukan ang tunay na port at, kung kaya, ang tunay na handshake ng 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

Ang kumpletong TCP handshake ay nagpapatunay ng maabot at patakaran para sa port na iyon. Hindi nito pinapatunayan na gumagana ang app: ang pagpapatunay, pag-upload o partikular na API call ay maaaring mabigo pa rin. Subukan ang operasyong talagang ginagawa ng mga user, gamit ang hindi nakakapinsalang katumbas sa halip na paulit-ulit na magsumite ng tunay na transaksyon.

Muling likhain ang kondisyon na nabibigo

Ang mga kabiguan na lumilitaw lamang sa malalaking paglilipat ay problema sa laki, hindi sa konektibidad. Magpadala ng malaking packet na nakatakda ang don't-fragment bit at panoorin kung saan ito humihinto. Kung nagtagumpay ang maliit na kahilingan at nakabitin ang malaki, ang MTU ng tunnel at ang paghawak ng MSS sa mga gateway ang mga susunod na suspek.

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

Kung isang subnet lang ang nabibigo, tingnan ang traffic selectors, mga anunsyo ng ruta at ang return gateway ng subnet na iyon. Kung hostname lang ang nabibigo, sundan ang DNS, kasama kung aling resolver ang ginamit ng kliyente at kung nakikita ba ang malayong view mula sa site na iyon. Tatlong magkaibang kabiguan, tatlong magkaibang pagwawasto, at wala sa kanila ang natutukoy ng ping test.

Pagkatapos ng pagwawasto, ulitin ang parehong pagsubok

Patakbuhin muli ang parehong kliyente, destinasyon, port at payload. Pagkatapos, muling kumonekta o subukan ang failover path kung mayroon ang disenyo, dahil ang pagwawastong gumagana lang habang buhay ang orihinal na instance ng tunnel ay hindi pa nasusubukan. Panatilihing nakatali ang pagsubok sa tunay na source, tunay na destinasyon at tunay na operasyon sa halip na isang berdeng indicator sa dashboard.

Itala ang apat na baseline na halaga at ang resulta. Ang susunod na ulat ng parehong sintomas ay makapagsisimula na sa ebidensya sa halip na sa ping.