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

Минете четирите проверки по ред и спрете на първата, която се провали.

Кой адрес всъщност се промени

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

Питайте конкретно: промени ли се външният източник, промени ли се вътрешният адрес на тунела или и двете? Само първото обяснява връстник, който продължава да изпраща към път, който вече не съществува.

Оставете протокола да се справи с преместването

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

Това, което не бива да правите, е да приемете неавтентикирано съобщение като доказателство, че идентичността на връстник се е преместила. Подправянето на датаграма, която твърди нов адрес, е тривиално, а клиент, който вярва, че може да бъде насочен към крайната точка на нападател. Автентикираният протокол е механизмът; известието не е.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Изчистете остарялата външна обвързаност

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

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

Тествайте отново с нова заявка

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

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

Ако нова заявка успее, а старата така и не се възобнови, тунелът е бил поправен и приложението просто трябва да се свърже отново.

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