Клиентът ви съобщава „свързано“, интерфейсът е вдигнат, а браузърът изтича по време, и нито едно от тези три твърдения не е лъжливо. „Свързано“ описва слой, който няма нищо общо със страницата, която сте поискали. Да се реши кой слой съобщава, изисква една нова заявка и един поглед към брояча, който би доказал, че трафикът е тръгнал. Рестартът изхвърля това доказателство и изгражда наново условията, които сте се опитвали да наблюдавате.

Три различни неща, наричани „свързано“

Най-отдолу „свързано“ може да означава, че процес на клиента работи и държи сокет към партньор. Над това може да означава, че съществува интерфейс с адрес, който постоянно устройство или процедура за възстановяване могат да създадат без жива сесия зад него. На ниво управление може да означава, че е договорена асоциация, което не казва нищо за това дали един пакет е преминал под нея. Всяко от тях оцелява при откази, при които другите не оцеляват, и клиентът обикновено показва най-силното, което може да претендира.

Зелена икона и мъртъв тунел следователно са съвместими, а не противоречиви; те съобщават за различни обекти. Точно затова тази повреда постоянно се диагностицира погрешно като бъг в клиента.

Изпратете една безобидна заявка до дестинация, която наистина ви трябва, преди да пипате демона, и задръжте изисквания блок за директен трафик, докато работите. Рестартът изтрива реда на събитията и после ги пресъздава достатъчно близо, за да скрие причината, поради което същият тикет се връща след седмица без нищо ново в него. Една заявка, едно отчитане на брояч и задействащото условие, което е причинило повредата, са минималното доказателство.

Кой брояч доказва, че пакетите са тръгнали

В IPsec IKE асоциацията и CHILD асоциацията са отделни обекти и само child носи броячите, които отговарят на този въпрос. Избройте child, наблюдавайте дали пакетите растат в двете посоки и сравнете това с онова, което приложението се опитва да направи. Инсталирана асоциация при нула е различна констатация от такава, която расте, докато приложението още се проваля; първата означава, че трафикът не се избира, втората — че той върви и повредата е по-нататък. Прочетете броячите два пъти с няколко секунди разлика, защото една проба не може да покаже тенденция.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Нулевите броячи сочат към избора: маршрутизация, политика, пространство от имена, от което е излязъл пакетът, или интерфейс, към който клиентът никога не се е обвързал. Растящите броячи сочат далеч от тунела, затова продължете с препращането в далечния край, разрешаването на имена, обратния път и услугата на дестинацията, в този ред. Протокол без отделен child обект показва същото доказателство със свои термини, затова използвайте каквото съобщава за състоянието на партньора и броя пакети, вместо да заемате речника на IPsec. Формата на отчитането е по-важна от инструмента, който го е произвел.

Къде се намира повредата, след като броячите тръгнат

Шлюз, който отговаря на собствения си административен адрес, доказва, че шлюзът работи, а не че нещо зад него обслужва заявката ви, затова тествайте далечната страна, а не кутията по средата. Разрешаването на имена крие повреди най-добре, защото resolver, до който не се стига през тунела, изтича по време точно както мъртва връзка. Две търсения разделят тези случаи и двете са евтини. Попитайте първо resolver-а, който тунелът налага, после попитайте публичен resolver за същото име.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Име, което се разрешава през публичния resolver, но не през тунелния, означава, че DNS пътят е счупен, докато име, което се разрешава през двата и пак изтича по време в браузъра, сочи към обратния път или към услугата. Ако ping по адрес успее, а приложението още отказва, мрежата е доставила заявката и услугата я е отхвърлила, което е съвсем по-късен етап.

Запишете задействащото условие, после сменете едно нещо

Запишете какво е предшествало повредата: период на бездействие, промяна в мрежата, подновяване на ключ, възобновен лаптоп или възстановена система. Те дават различни механизми и само възстановената система обикновено се поправя сама, което е точно случаят, който не ви учи на нищо. Рестартът премахва реда на събитията и после пресъздава условия достатъчно близки, за да скрие причината. Запишете задействащото условие, докато още е възпроизводимо.

После направете една подкрепена корекция и повторете първоначалната заявка заедно със задействащото условие, което е причинило повредата. Бездействието е най-лесното за възпроизвеждане условие, затова то е най-бързото потвърждение, че поправката е адресирала механизма, а не симптома.

Това, което искате да съобщите, е доказателство, че трафикът, който сте възнамерявали да изпратите, е достигнал услугата, до която сте възнамерявали да стигнете. Икона, която позеленява, кеширана страница, която се зарежда, и брояч, който се движи, всички доказват по-малко от една завършена заявка към желаната дестинация. Пазете заявката, отчитането на брояча и задействащото условие заедно, за да може следващият човек да различи поправка от съвпадение.

Подобни статии