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-ыг хараад, дараагийн хүн харьцуулах боломжтой байхын тулд хоёр сүлжээний контекстийг бичигт үлдээнэ үү.