Ինչու է ձեր VPN-ը կտրվում, երբ Wi-Fi-ը փոխվում է կամ Ethernet-ը միանում
'Նոր 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-ը հաղորդում է հասանելի ցանցերը և առանձին լռելյայն, և 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-ին, և պահեք երկու ցանցային համատեքստերն էլ գրառման մեջ, որպեսզի հաջորդ մարդը կարողանա համեմատել դրանք։