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'ка караңыз, жана кийинки адам салыштыра алышы үчүн эки тармактык контекстти тең жазууда сактаңыз.