Повикот се прекинува кога ќе го поминете работ на градот, и иконата за VPN исчезнува во истиот момент. Примамливо е тоа да се запише како „промената на кулата го уби тунелот“. Се случија две различни работи и само една од нив е за кули. Радио предавање може да ја остави вашата IP адреса, стандардната рута и сесијата целосно недопрени, додека вистинска промена на адресата ќе го прекине секој тунел што не може да се движи со неа. Корисна вежба е да се спореди како клиентите се справуваат со вториот случај, бидејќи ви кажува дали гледате проектирано однесување или грешка.

Промената на кула не е нужно промена на адреса

Мобилните мрежи ја држат пакетната сесија жива при предавањата додека сидрото за мобилност на операторот останува исто. Радио врската се менува, тунелот не го забележува и во ниту еден дневник не треба да се појави повторно поврзување. Ова е вообичаениот случај за движење во град.

Адресата ја менува преместување меѓу сидра, премин од Wi-Fi на мобилна мрежа или повторно воспоставување на тунелот од страната на операторот по долга пауза. Тие настани ја заменуваат изворната адреса што ја носат вашите пакети, а партнерот на VPN гледа партнер што се преместил.

Практичната последица е дека движењето не е доказ. Уред што поминал четириесет километри можеби ја задржал едната адреса целиот пат, а уред што стои можеби ја сменил адресата двапати затоа што мрежата така одлучила. Запишувањето на настанот е единствениот начин да се разликуваат.

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

Клиентите се разликуваат по тоа колку им е важно што надворешниот извор се променил. Некои го врзуваат тунелот за адресата на која е изграден и бараат целосно повторно воспоставување. Други го проверуваат секој пакет независно и само ажурираат каде ги праќаат одговорите.

MechanismBehaviour after the source changesWhat the user notices
WireGuardEndpoint updated on the next authenticated packetUsually nothing; the tunnel continues
IKEv2 with MOBIKESecurity association moves to the new addressShort pause, no re-authentication
OpenVPN over UDP with floatPeer address may change without a restartMight survive, depending on timing
Client bound to one addressSession dies and is rebuiltA visible reconnect and a new authentication

Горниот ред објаснува многу збунувачки извештаи. 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 за поврзување ги опишува повратните повици што ја разликуваат достапноста од промена на стандардната мрежа, и токму таа разлика му треба на вашиот извештај. Останатото е приказна за возење.

Поврзани статии