Защо една VPN може да изглежда свързана, когато нищо не работи
„Свързано“ може да описва процес, интерфейс или асоциация, а не използваем път. Изпратете една нова заявка и прочетете какво доказва, че трафикът е тръгнал.
Клиентът ви съобщава „свързано“, интерфейсът е вдигнат, а браузърът изтича по време, и нито едно от тези три твърдения не е лъжливо. „Свързано“ описва слой, който няма нищо общо със страницата, която сте поискали. Да се реши кой слой съобщава, изисква една нова заявка и един поглед към брояча, който би доказал, че трафикът е тръгнал. Рестартът изхвърля това доказателство и изгражда наново условията, които сте се опитвали да наблюдавате.
Три различни неща, наричани „свързано“
Най-отдолу „свързано“ може да означава, че процес на клиента работи и държи сокет към партньор. Над това може да означава, че съществува интерфейс с адрес, който постоянно устройство или процедура за възстановяване могат да създадат без жива сесия зад него. На ниво управление може да означава, че е договорена асоциация, което не казва нищо за това дали един пакет е преминал под нея. Всяко от тях оцелява при откази, при които другите не оцеляват, и клиентът обикновено показва най-силното, което може да претендира.
Зелена икона и мъртъв тунел следователно са съвместими, а не противоречиви; те съобщават за различни обекти. Точно затова тази повреда постоянно се диагностицира погрешно като бъг в клиента.
Изпратете една безобидна заявка до дестинация, която наистина ви трябва, преди да пипате демона, и задръжте изисквания блок за директен трафик, докато работите. Рестартът изтрива реда на събитията и после ги пресъздава достатъчно близо, за да скрие причината, поради което същият тикет се връща след седмица без нищо ново в него. Една заявка, едно отчитане на брояч и задействащото условие, което е причинило повредата, са минималното доказателство.
Кой брояч доказва, че пакетите са тръгнали
В 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 по адрес успее, а приложението още отказва, мрежата е доставила заявката и услугата я е отхвърлила, което е съвсем по-късен етап.
Запишете задействащото условие, после сменете едно нещо
Запишете какво е предшествало повредата: период на бездействие, промяна в мрежата, подновяване на ключ, възобновен лаптоп или възстановена система. Те дават различни механизми и само възстановената система обикновено се поправя сама, което е точно случаят, който не ви учи на нищо. Рестартът премахва реда на събитията и после пресъздава условия достатъчно близки, за да скрие причината. Запишете задействащото условие, докато още е възпроизводимо.
После направете една подкрепена корекция и повторете първоначалната заявка заедно със задействащото условие, което е причинило повредата. Бездействието е най-лесното за възпроизвеждане условие, затова то е най-бързото потвърждение, че поправката е адресирала механизма, а не симптома.
Това, което искате да съобщите, е доказателство, че трафикът, който сте възнамерявали да изпратите, е достигнал услугата, до която сте възнамерявали да стигнете. Икона, която позеленява, кеширана страница, която се зарежда, и брояч, който се движи, всички доказват по-малко от една завършена заявка към желаната дестинация. Пазете заявката, отчитането на брояча и задействащото условие заедно, за да може следващият човек да различи поправка от съвпадение.