VPN се свързва наново по време на шофиране: смяна на радио или на IP?

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

Смяната на кула не е непременно смяна на адрес

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

Адреса променя преместване между котви, преминаване от Wi-Fi към мобилна мрежа или повторно установяване на тунела от страна на оператора след дълга пауза. Тези събития заменят изходния адрес, който носят пакетите ви, и партньор на VPN вижда партньор, който се е преместил.

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

Два подхода: преместете тунела или го изградете наново

Клиентите се различават по това колко ги интересува, че външният източник се е променил. Някои обвързват тунела с адреса, на който е изграден, и изискват пълно повторно установяване. Други удостоверяват всеки пакет независимо и само обновяват къде изпращат отговорите.

Горният ред обяснява много объркващи доклади. WireGuard няма сесия, която да бъде прекъсната: всеки пакет носи индекса на партньора и се удостоверява, затова валиден пакет, пристигащ от нов адрес, по определение е от този партньор, и записаният краен пункт го следва. Клиент, който показва „свързано“ непрекъснато по време на пътуване, казва истината.

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

Наблюдавайте събитието, а не движението

В Android подсистемата за свързаност отчита промените в мрежата като събития и именно тях трябва да свържете с поведението на клиента. Изходът е дълъг, но важните части са мрежата по подразбиране и нейният адрес:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

От страна на сървъра има пряко измерване за случая на роуминг. WireGuard съхранява последния удостоверен краен пункт за всеки партньор, затова промяната на адрес се появява като променена стойност, а не като повторно свързване:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

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

Рестартирането изглежда различно: времевият печат на ръкостискането се нулира към момента на повторното свързване и клиентът записва последователност за инициализация, а не тихо продължение.

Кога повторното свързване е правилното поведение

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

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

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

Запишете наблюдаваната последователност

Полезен доклад назовава източника на събитието: промяна на мрежата по подразбиране с нов адрес, преминаване от Wi-Fi към мобилна мрежа или предаване без никаква промяна на адреса. След това посочва какво е направил клиентът, с времевия печат от страната на сървъра, а не от паметта.

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

И избягвайте израза „смяна на кула“, освен ако журналът на устройството наистина го потвърждава. Документацията на Android за свързаността описва обратните извиквания, които различават наличността от промяна на мрежата по подразбиране, и точно тази разлика е нужна на вашия доклад. Всичко останало е история за шофиране.