Чаму 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 на шляху, і захавайце абодва сеткавыя кантэксты ў апісанні, каб наступны чалавек мог іх параўнаць.