Ինչու է kill switch-ը դադարեցնում երթևեկությունը սերվերը փոխելիս
Ինչու է kill switch-ը արգելափակում երթևեկությունը սերվերի փոփոխության ընթացքում, ինչ է անում հաճախորդը այդ պատուհանում և ինչպես տարբերել սովորական դադարը կախված արգելափակումից։
Դուք ընտրում եք մոտիկ թվացող սերվեր, սեղմում միանալ, և դիտարկիչը դադարում է բեռնել նախքան նոր թունելի բարձրանալը։ Պատկերակը անցնում է միացման վիճակի և մնում այնտեղ, մինչև յուրաքանչյուր ներդիրի ժամկետը լրանա։ Այդ դադարը սովորաբար kill switch-ն է, որն աշխատում է ինչպես նախատեսված է՝ երթևեկությունն արգելափակված է, քանի դեռ հաճախորդը թունել չունի այն ուղարկելու համար։ Դադարն ընդունելի է, թե ոչ, կախված է նրանից, թե ինչ է անում հաճախորդը այդ վայրկյաններին և արդյոք արգելափակումը հանվում է, երբ նա ասում է, որ հանված է։
Ինչ է անում հաճախորդը երկու սերվերների միջև
Վերջնակետի փոփոխությունը մի քանի քայլ է, ոչ թե մեկ անջատիչ։ Հաճախորդը քանդում է ընթացիկ թունելը, թարմացնում է իր արգելափակման կանոնները, լուծում և հասնում է նոր վերջնակետին թունելից դուրս, ապա տեղադրում է նոր երթուղիները և հանում արգելափակումը։ Ձեր զգացած բացը առաջին և վերջին քայլի միջև է։
Այստեղ հերթականությունը ավելի կարևոր է, քան արագությունը։ Եթե արգելափակման կանոնները գործարկվեն նոր վերջնակետի բացառությունից առաջ, հաճախորդը չի կարող ավարտել ձեռքսեղմումը և մնում է միացող վիճակում մինչև ժամկետի լրանալը։ Եթե բացառությունը հին սերվերի հասցեի պատճենն է, նոր ձեռքսեղմումը նման է ցանկացած այլ ելքային փաթեթի և դեն է նետվում։ Երկու դեպքերն էլ դիտարկիչից նույնն են երևում, դրա համար էլ վեց վայրկյան հետո վերականգնվող փոփոխությունը և երբեք չվերականգնվողը կարող են նույն պատճառն ունենալ։
Նոր վերջնակետին անցք է պետք արգելափակման մեջ
Թունելը կառուցելու համար հաճախորդը պետք է փաթեթներ ուղարկի նոր սերվերի հասցեին և պորտին ֆիզիկական ինտերֆեյսով, օրինակ UDP 51820 սովորական WireGuard պրոֆիլի համար կամ 1194 և 443 OpenVPN-ի համար, ինչ էլ որ ձեր պրոֆիլը սահմանի։ Այդ երթևեկությունը այն թունելի մեջ չէ, որը հենց նոր է ստեղծվելու, ուստի ամբողջ սարքի համար արգելափակումը կուլ է տալիս այն, եթե համապատասխան թույլտվության կանոն չկա։
Հոսթանունի վրա հիմնված պրոֆիլները ավելացնում են երկրորդ պահանջը՝ ինքը որոնումը։ Եթե հաճախորդը լուծում է վերջնակետը մինչև արգելափակման բարձրանալը, կարող է օգտագործել քեշավորված հասցե, բայց երբ պրոֆիլը փոխում է հասցեները կամ քեշի գրառումը հնանում է, ձեռքսեղմումը գնում է դեպի հասցե, որը թույլտվության կանոնը չի ծածկում։ IPv6-ը դա տեսանելի է դարձնում, քանի որ կրկնակի կույտով վերջնակետը կարող է հրապարակել և՛ A, և՛ AAAA գրառում, իսկ միայն v4 հասցեն ծածկող թույլտվության կանոնը հաճախորդին թողնում է նորից փորձել արգելափակված v6 հասցեի դեմ։
Տարբերակների անունները և լռելյայն արժեքները տարբերվում են ըստ հաճախորդի և տարբերակի, ուստի կարդացեք ձերինը վերաբերող փաստաթղթավորված ցանկը՝ էկրանի նկարներից գուշակելու փոխարեն։ OpenVPN Connect-ի կարգավորումների տեղեկանքը openvpn.net/connect-docs/app-settings-windows հասցեում մեկ օրինակ է, թե ինչպես է հաճախորդը նկարագրում իր արգելափակման և բաժանված թունելի տարբերակները։
Fail-closed-ը վիճակների մեքենա է, ոչ թե անջատիչ
Հաճախորդների մեծ մասը արգելափակումն արտահայտում է որպես հրապատի քաղաքականություն երեք վիճակում՝ թունելը վերևում, երթևեկությունը թունելով և արգելափակում չկա․ թունելը ներքևում, արգելափակումը ակտիվ է․ և անցում, երբ արգելափակումը ակտիվ է գումարած ժամանակավոր բացառություններ վերջնակետի համար։ Հենց երրորդ վիճակում են ապրում սխալները, որովհետև այն պետք է երկու անգամ փոխվի մի քանի վայրկյանում, և դրանից դուրս չգալը ճիշտ նույն տեսքն ունի, ինչ մշտական արգելափակումը։
Մեխանիզմը տարբերվում է ըստ հարթակի, և ձախողումը նույնպես։ Windows Filtering Platform-ի զտիչները կշիռ ունեն, ուստի ձեր թույլտվությունը գերազանցող արգելափակող զտիչը շարունակում է փաթեթները դեն նետել, նույնիսկ եթե թույլտվությունը կա, և սպանված հաճախորդի պրոցեսի թողած զտիչները կարող են մեքենան առանց ցանցի պահել այն բանից հետո, երբ հավելվածն այլևս չկա։ macOS-ի հաճախորդները սովորաբար pf կանոնները գրում են խարիսխի մեջ, որտեղ կանոնների հերթականությունը և արագ որոշումները որոշում են, թե որ կանոնն է գործում։ Linux-ի հաճախորդները սովորաբար կառավարում են nftables կամ iptables շղթա՝ drop քաղաքականությամբ և հստակ թույլտվություններով վերջնակետի, թունելի ինտերֆեյսի և loopback-ի համար։ Android-ի always-on VPN-ը՝ առանց VPN միացումները արգելափակելու տարբերակով, խմբի մեջ ամենախիստն է, որովհետև օպերացիոն համակարգը արգելափակումը կիրառում է ամբողջ սարքի վրա, ոչ թե յուրաքանչյուր հավելվածի։
WireGuard-ին իր առանձին նշումն է պետք, որովհետև AllowedIPs-ը երթուղային ընտրիչ է, ոչ թե արգելափակիչ։ Այն որոշում է, թե որ նպատակակետերն են մտնում թունել. այն ոչինչ չի անում, որպեսզի թունել չունեցող փաթեթը Wi-Fi-ով դուրս չգա։ Միայն WireGuard-ով և առանց հրապատի կանոնի կարգավորման դեպքում kill switch-ը իրականում երթուղու բացակայությունն է, և դեն նետված ձեռքսեղմումից հետո ֆիզիկական ինտերֆեյսով կարող է իրական փաթեթ դուրս գալ։
Չափեք բացը՝ պատկերակին նայելու փոխարեն
Հետևեք փաթեթներին, ոչ թե վիճակի լույսին։ Linux-ում մեկ տերմինալում դանդաղ ping սկսեք հանրային հասցեին, իսկ մյուսում բռնեք թունելի տրանսպորտային պորտը ֆիզիկական ինտերֆեյսի վրա։
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Փոխեք սերվերը հաճախորդում, մինչ երկուսն էլ աշխատում են։ Երեք բան կարևոր է՝ որքան է դադարում ping-ը, արդյոք գրառումը ցույց է տալիս ձեռքսեղմման հասնելը նոր վերջնակետին, և արդյոք երթևեկությունը վերադառնում է մինչև հաճախորդի վիճակը միացված դառնալը, թե դրանից հետո։ Եթե ping-ի բացը առաջինն ավարտվի, ապա կա՛մ արգելափակումը վաղ է հանվել, կա՛մ թունելը բարձրացել է նախքան ցուցիչի դա ընդունելը։ Եթե բացը ավելի ուշ ավարտվի, ցուցիչը չափից ավելի լավատես է։
Windows-ում netsh wfp show state-ը ստեղծում է պատկեր, որտեղ կարող եք փնտրել արգելափակող զտիչներ, որոնք դեռ կան, մինչ հաճախորդը պնդում է, որ անջատված է։ macOS-ում sudo pfctl -sr-ը թվարկում է բեռնված կանոններն ու դրանց հերթականությունը։ Զուգավորեք ցանկացած պատկեր հաճախորդի սեփական մատյանի հետ. ձեր ping-ի ժամանակագրությունը ասում է՝ արգելափակումը ուշ ավարտվե՞ց, թե՞ երբեք։
Սովորական մթնում ընդդեմ կախված արգելափակման
Ինչ-որ ընդհատում այս հատկության իմաստն է, ուստի նախ դասակարգեք, ապա փոխեք որևէ կարգավորում։
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Եթե հայտնվեք երկրորդ կամ հինգերորդ տողում, մի անջատեք kill switch-ը փորձարկելու համար, որովհետև դա երթուղային սխալը վերածում է արտահոսքի։ Վերագործարկեք հաճախորդի ծառայությունը կամ վերագործարկեք մեքենան այնտեղ, որտեղ զտիչները վերապրում են պրոցեսի սպանությունը, ապա տեսեք՝ արգելափակումը մաքրվում է արդյոք։ Եթե մաքրվում է, սխալը փոփոխության ընթացքում մաքրելու մեջ է, ոչ թե հենց արգելափակման։
Ձեր հաջորդ փոփոխությունից առաջ հաստատեք չորս բան՝ վերջնակետի թույլտվությունը ծածկում է ձեր պրոֆիլի լուծած յուրաքանչյուր հասցեային ընտանիք, հաճախորդի մատյանը ցույց է տալիս ավարտված անցում, ձեր ping-թեստը չափում է բացը, ոչ թե պատկերակը, և հաճախորդի փակումը վերականգնում է սովորական կապը։ Այն kill switch-ը, որը դիմանում է փոփոխության ընթացքում և հետո բաց թողնում, անում է իր գործը։ Այն, որը վաղ է բաց թողնում կամ երբեք, արժե վրիպազերծել։