Wi-Fi өзгергенде немесе Ethernet қосылғанда VPN неге үзіледі
'Жаңа SSID, қатынау нүктелері арасындағы роуминг және қосылған кабель туннельді үш түрлі жерде үзеді. Бастауыш мекенжайды, содан кейін маршрутты, содан кейін протоколды тексеріңіз.'
Екі нәрсе бір ақау ретінде хабарланады: ноутбук басқа Wi-Fi желісіне көшті, немесе Wi-Fi қосылып тұрғанда кабель қосылды. Клиент әлі де қосылған дейді, белгіше сау көрінеді, ал туннель ештеңе тасымайды. Астында тек үш күй бөлігі ғана жылжи алады - байланыс, жергілікті мекенжай, әдепкі маршрут - және қайсысы жылжығаны туннельдің өздігінен қалпына келетінін немесе қайта қосылу керектігін анықтайды. Мен оларды осы ретпен тексеремін, өйткені тіркелгі параметрлерін өзгерту олардың ешқайсысын ешқашан түзетпеген.
Байланыс, мекенжай және маршрут тәуелсіз жылжиды
Бір желінің қатынау нүктелері арасындағы роуминг әдетте L2 оқиғасы. Радио қайта бірігеді, интерфейс өз мекенжайы мен шлюзін сақтайды, және туннель тәуелді ештеңе өзгермейді, сондықтан үлкен кеңседе жүру кейде байқалмай өтеді. Басқа SSID-ға қосылу бұлай емес: ескі интерфейс түсіп қалуы мүмкін, DHCP жаңа мекенжай, жаңа шлюз және жаңа шешушілер береді, ал туннель пайдаланған сыртқы ағын жойылады.
Ethernet үшінші пішінді қосады. Wi-Fi ешқашан түспейді, сондықтан байланыс оқиғасы мүлдем туындамайды, бірақ сымды интерфейс өз мекенжайымен пайда болады және көбінесе метрика бойынша әдепкі маршрутты ұтып алады. Туннель енді таңдаулы емес жолмен жұмысын жалғастырады, немесе клиент өз сокетін бастаған сымсыз желіге бекітіп ұстайды. Браузерден екеуі де бірдей көрінеді: кабель дырылдаған сәтте беттер тоқтайды.
Сондықтан бірінші сұрақ Wi-Fi өзгерді ме емес. Сұрақ - туннель қосулы тұрғанда сіз байланған мекенжай немесе соңғы нүктеге барар маршрут өзгерді ме.
Сыртқы сокет дәл қазір жоғалған мекенжайға бекітілген
Әрбір туннель сыртқы ағын: жергілікті мекенжай мен порт сервердің мекенжайымен және портымен сөйлеседі. Linux-та бұл ескі көзге байланған UDP сокеті; мекенжайды ұстап тұрған интерфейс жойылғанда, жіберулер EADDRNOTAVAIL-мен сәтсіз аяқталады немесе сервер ешқашан көрмеген көзбен жаңа интерфейстен шығады.
Алыс жақ өз бекітпесін сақтайды. MOBIKE жоқ IKEv2 SA мекенжай жұбымен анықталады, ал 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 қолжетімді желілерді және бөлек әдепкіні хабарлайды, ал сокетті Network нысанына байлайтын VPN қолданбасы қайта байламайынша сол байлауды ұстайды. 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 DF орнатылған 1500 байттық пакет жібереді; тыныштық жол сіз ойлағаннан кішірек дегенді білдіреді.
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-қа қараңыз, және екі желілік контексті де жазбада сақтаңыз, келесі адам оларды салыстыра алуы үшін.