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