Защо VPN връзката пада, когато Wi-Fi се смени или се включи Ethernet
'Нов SSID, роуминг между точки за достъп и включен кабел чупят тунела на три различни места. Проверете адреса на източника, после маршрута, после протокола.'
Две неща се съобщават като една повреда: лаптопът е преминал към друга Wi-Fi мрежа или е включен кабел, докато Wi-Fi е останал активен. Клиентът още казва, че е свързан, иконата изглежда здрава, а тунелът не пренася нищо. Отдолу могат да се преместят само три части от състоянието - връзката, локалният адрес, маршрутът по подразбиране - и коя от тях се е преместила решава дали тунелът ще се възстанови сам, или ще е нужно повторно свързване. Проверявам ги в този ред, защото промяната на настройките на акаунта никога не е оправяла нито една от тях.
Връзката, адресът и маршрутът се местят независимо
Роумингът между точки за достъп в една и съща мрежа обикновено е събитие на L2. Радиото преасоциира, интерфейсът запазва адреса и шлюза си и нищо, от което зависи тунелът, не се променя, затова разходка из голям офис понякога остава незабелязана. Присъединяването към друг SSID не е това: старият интерфейс може да падне, DHCP дава нов адрес, нов шлюз и нови резолвери, а външният поток, който тунелът използваше, престава да съществува.
Ethernet добавя трета форма. Wi-Fi никога не пада, така че не се задейства никакво събитие по връзката, но кабелният интерфейс се появява със свой адрес и често печели маршрута по подразбиране по метрика. Тунелът продължава да работи по път, който вече не е предпочитан, или клиентът държи сокета си закрепен към безжичната мрежа, от която е започнал. От браузъра двете изглеждат еднакво: страниците забиват в момента, в който кабелът щракне.
Значи първият въпрос не е дали Wi-Fi се е сменил. А дали адресът, към който сте вързани, или маршрутът към крайната точка, се е сменил, докато тунелът е бил активен.
Външният сокет е закрепен към адрес, който току-що изчезна
Всеки тунел е външен поток: локален адрес и порт, които говорят с адреса и порта на сървъра. В Linux това е UDP сокет, вързан към стария източник; когато интерфейсът, който държи адреса, бъде премахнат, изпращанията или се провалят с EADDRNOTAVAIL, или излизат през новия интерфейс с източник, който сървърът никога не е виждал.
Отсрещната страна пази своята закачалка. SA на IKEv2 без MOBIKE се идентифицира по двойката адреси, а OpenVPN сесия е вързана към адреса на партньора, който е научила, а NAT съпоставянето принадлежи на частния адрес, порта и публичния адрес, които са го създали. Преместете се зад друг NAT и всеки отговор се изпраща към съпоставяне, което вече не съществува. Нищо на вашата машина не е конфигурирано грешно; петорката сочи към мрежа, която сте напуснали.
Прочетете състоянието, преди да теоретизирате:
ss -unpпоказва локалния адрес и порт, които всеки сокет на тунел всъщност държи.ip route get 203.0.113.10отпечатва адреса на източника и устройството, което ядрото би използвало за крайната точка точно сега.wg show wg0 endpoints,swanctl --list-sasили журналът на клиента показва адреса на партньора, с който според отсрещната страна разговаря.
Ако адресът на сокета и търсенето на маршрут не съвпадат, намерили сте прекъсването и никаква промяна на идентификационните данни няма да го засегне.
Какво прави всеки протокол с нов адрес на източника
Клиентите поемат промяната в различна степен и таблицата е това, с което сравнявам конфигурацията на клиента, вместо да гадая по поведението при повторно свързване.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
Правилото за роуминг на WireGuard работи само в една посока: клиентът трябва първо да изпрати от новия адрес. Сокет, все още вързан към стария интерфейс, никога не го прави, затова тунелът може да изглежда жив, докато таймерът му за ръкостискане остарява. описанието на протокола посочва точно условието за обновяване на крайната точка и си заслужава да се прочете, преди да промените конфигурация.
MOBIKE се договаря, не се предполага. Ако сървърът не го предлага, клиентът трябва да установи връзката наново и това е факт, който потвърждавате от списъка със SA или журнала, а не извеждате от въртящо се колелце.
Предпочитанието на маршрута решава пътя, не иконата на Wi-Fi
Когато и двата интерфейса са вдигнати, ядрото избира по метрика и дължина на префикса. ip route show default изброява кандидатите, а ip route get 203.0.113.10 решава истинското решение, включително адреса на източника. Кабелен маршрут по подразбиране с метрика 100 и безжичен с 600 означават, че крайната точка се мести в момента, в който кабелът се намести, докато всяко приложение, отворило сокет по-рано, пази стария си източник.
Windows прави същото с автоматични метрики на интерфейсите, пристрастени от скоростта на връзката. Get-NetRoute -DestinationPrefix 0.0.0.0/0 сортира кандидатите, а Find-NetRoute -RemoteIPAddress 203.0.113.10 връща интерфейса и източника, които стекът би избрал. Клиент, който вързва външния си сокет към един интерфейс, продължава да го използва, след като метриката се обърне; това е решение за вързване, а не дефект в маршрутизацията.
Android прави разделянето видимо: ConnectivityManager съобщава наличните мрежи и отделен маршрут по подразбиране, а VPN приложение, което вързва сокет към обект Network, държи това вързване, докато не го върже отново. В macOS, scutil --nwi отпечатва основния интерфейс и реда, който системата би използвала.
DNS, MTU и IPv6 се местят с прикачването
Ново прикачване носи нови резолвери. С systemd-resolved DNS е за всяка връзка, resolvectl status показва коя връзка отговаря на име, а гостуваща мрежа, която дава собствен резолвер, може да остави DNS, изпратения от тунела, неизползван, докато връзката не стане отново предпочитана. Затварящ портал го влошава: на първата HTTPS заявка отговаря порталът, а не крайната точка, и клиентът записва мъртъв сървър.
MTU на пътя също се променя. Ethernet и Wi-Fi обикновено носят 1500 байта, PPPoE 1492, а мобилните връзки често по-малко. Тунел, който наследява по-малък MTU, забива при големи пакети, докато малките заявки успяват, което се чете като наполовина счупена връзка. ping -M do -s 1472 203.0.113.10 изпраща пакет от 1500 байта с вдигнат DF; тишината означава, че пътят е по-малък, отколкото предполагахте.
IPv6 е другата половина. Мрежа, която дава нов префикс, променя източника, който би използвал клиент с двоен стек, а тунел само за v4 оставя трафика v6 извън себе си, докато политиката не настигне. ip -6 route show default и ip -6 addr show отговарят дали новата връзка има изобщо път за v6.
Възпроизведете прехода, вместо да го описвате
Изберете една безобидна заявка и пуснете същите три команди от двете страни на промяната: ip -br addr, ip route show default, ip route get 203.0.113.10. После наблюдавайте дали тунелът още излъчва пакети - tcpdump -ni any udp port 51820 за WireGuard, съответния порт за всичко останало. Пакети, излизащи от стария източник, означават проблем с вързването. Пакети от новия източник без отговор означават отсрещната страна или NAT по пътя.
Отбележете кое събитие съвпадна с първата повреда: падане на връзката, смяна на адреса или смяна на маршрута по подразбиране. Те сочат към различни собственици - клиент, който трябва да се върже наново, адрес, който трябва да се придобие наново, или маршрут, който принадлежи на конфигурационен файл, а не на постоянно правило за заобикаляне.
Преди да го обявите за оправено, потвърдете, че блокът за директен трафик още се държи по време на прекъсването и че имената се решават през новото прикачване. Ако клиентът пази стария край на връзката след превключването, първо оправете настройката за роуминг или float. Ако роумингът е правилен и пак няма отговор, погледнете идентичността на партньора в сървъра и NAT по пътя и запазете двата мрежови контекста в описанието, за да може следващият човек да ги сравни.