Зашто вам 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 на путу, и задржите оба мрежна контекста у запису да би следећа особа могла да их упореди.