Ping не доказ: праверце шлях паміж двума сайтамі

Пінг з шлюза нічога не кажа пра сэрвіс. Прайдзіце шлях ад рэальнага кліента, выкарыстайце пратакол праграмы і паўтарыце памер або імя, якое не працуе.

Тунэль узняты, шлюзы адказваюць адзін аднаму, а карыстальнікі на адным сайце ўсё яшчэ не могуць адкрыць агульны каталог на другім. Нехта пінгуе са шлюза, атрымлівае адказ і абвяшчае сетку здаровай. Гэты адказ прайшоў паміж двума прыладамі, якія ніколі не былі праблемай. Карысны тэст пачынаецца на хасце, якому патрэбны сэрвіс, выкарыстоўвае пратакол, які выкарыстоўвае праграма, і паўтарае ўмову, пры якой узнікае збой. Усё астатняе — зялёнае святло для шляху, па якім ніхто не ідзе.

Пачніце з кліента, якому патрэбны сэрвіс

Запішыце чатыры рэчы перад любым тэстам: адрас кліента, адрас прызначэння, імя хаста і порт праграмы. Затым пацвердзіце, што сэрвіс працуе лакальна на сваім сайце, з хаста побач. Без гэтай базавай лініі вы не адрозніце зламаны тунэль ад зламанага сэрвісу, і палова гэтых заявак — другая.

Паспрабуйце дакументаванае імя хаста і, дзе сэрвіс дазваляе, прамую праверку адраса таго ж порта. Няўдалы пошук імя і недасягальны атрыманы адрас вядуць вас рознымі шляхамі. Калі вы замяняеце імя хаста на IP, не адключайце праверку ідэнтычнасці HTTPS, каб гэта запрацавала; папярэджанне пра сертыфікат — гэта інфармацыя, а не перашкода.

Прайдзіце шлях на кожным краі

Прачытайце маршрут, які выбірае кліент, затым маршрут, які выбірае шлюз для гэтага прызначэння, затым лічыльнікі або абмежаваны захоп на кожным краі. Вы шукаеце два факты: ці дайшоў запыт да аддаленай лакальнай сеткі і ці вярнуўся адказ. Лічыльнікі інтэрфейса ўключаюць усе іншыя патокі, таму супастаўляйце па дакладным часе і пары адрасоў, а не па форме графіка. Захоп, зроблены на няправільным краі, горш за адсутнасць, бо ён выглядае як доказ.

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

Калі запыт з'яўляецца на аддаленым краі без адказу за ім, праблема на тым баку: міжсеткавы экран, адсутны зваротны маршрут або хост, які не прымае крыніцу. Калі запыт не з'яўляецца зусім, лакальны маршрут або селектары тунэля не перанеслі яго, і той бок яшчэ не варта даследаваць.

Выкарыстоўвайце пратакол, які выкарыстоўвае праграма

ICMP — слабы занд. Ён можа быць адфільтраваны, абмежаваны па хуткасці або апрацаваны іншай палітыкай, чым сэрвіс, што робіць неадназначнымі і яго поспех, і яго збой. Тэстуйце фактычны порт і, дзе магчыма, фактычнае рукапоцісканне пратакола.

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

Завершанае рукапоцісканне TCP даказвае дасягальнасць і палітыку для гэтага порта. Яно не даказвае, што праграма працуе: аўтэнтыфікацыя, загрузка або пэўны выклік API ўсё яшчэ могуць збаіць. Тэстуйце аперацыю, якую карыстальнікі фактычна выконваюць, выкарыстоўваючы бясшкодны эквівалент замест паўторнай адпраўкі рэальнай транзакцыі.

Паўтарыце ўмову, пры якой узнікае збой

Збоі, якія з'яўляюцца толькі пры вялікіх перадачах, — гэта праблема памеру, а не злучальнасці. Адпраўце вялікі пакет з усталяваным бітам don't-fragment і паглядзіце, дзе ён спыніцца. Калі малы запыт паспявае, а вялікі завісае, наступныя падазроныя — MTU тунэля і апрацоўка MSS на шлюзах.

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

Калі збаіць толькі адна падсетка, глядзіце на селектары трафіку, аб'явы маршрутаў і зваротны шлюз гэтай падсеткі. Калі збаіць толькі імя хаста, ідзіце па DNS, улічваючы, які рэзалвер выкарыстаў кліент і ці бачны аддалены выгляд з таго сайта. Тры розныя збоі, тры розныя выпраўленні, і тэст пінга не адрознівае ніводнага з іх.

Пасля выпраўлення паўтарыце той жа тэст

Паўторна запусціце той жа кліент, прызначэнне, порт і нагрузку. Затым перападключыцеся або праверце шлях пераключэння, калі ён прадугледжаны, бо выпраўленне, якое працуе толькі пакуль жывая першапачатковая копія тунэля, не праверана. Трымайце тэст прывязаным да рэальнай крыніцы, рэальнага прызначэння і рэальнай аперацыі, а не да аднаго зялёнага індыкатара на панэлі.

Запішыце чатыры базавыя значэнні і вынік. Наступная справаздача пра той жа сімптом зможа тады пачацца з доказаў, а не з пінга.

Падобныя артыкулы