Kill-switch-ը Wi-Fi-ից բջջային անցնելուց հետո․ ինչ է կոտրվում

Մի պահ նոութբուքը գրասենյակի Wi-Fi-ում է, հաջորդ պահին՝ կապված հեռախոսին, և թունելի ցուցիչը նորից կանաչ է, նախքան պատուհանները փոխելը կավարտեք։ Կանաչ լույսը միայն հայտնում է, որ թունելը նորից միացավ․ թե ինչ արեց երթուղման և արգելափակման քաղաքականությունը այդ բացվածքի ընթացքում, այլ հարց է։ Այդ քաղաքականությունը համապատասխանության պայմանների հավաքածու է, որը կազմվել է վերջին տեղադրման ժամանակ, և անվանում է ինտերֆեյս, հասցե և հասցեների ընտանիք, որոնք անցումը հենց նոր հեռացրել է։ Ուստի նույն փոփոխությունը տալիս է երեք արդյունք, որոնք նույնական են թվում․ արգելափակումը շարունակվում է, քաղաքականությունն արգելափակում է իր իսկ վերականգնումը, կամ բացվում է ուղի, որը ոչինչ չի ծածկում։

Էկրանին ոչինչ չի տարբերում այդ երեք վիճակները, ուստի հարցրեք, թե որ իդենտիֆիկատորներին էին կապված կանոնները, փոխանակ թե ինչ գույն է ցույց տալիս ցուցիչը։ Linux-ում կանոնը կարող է անվանել ինտերֆեյս կամ դրանից լցված ipset; Android-ում VpnService-ին կարելի է ասել, թե որ հիմնական ցանցերին հետևել setUnderlyingNetworks-ով։ Յուրաքանչյուր կապ մատնացույց է անում մի կապուղու, որը շուտով կփոխարինվի, և յուրաքանչյուրը պետք է վերընթերցվի դրանից հետո։

Ինչ է իրականում վերագրում անցումը

Երբ հին կապուղին անհետանում է, միջուկը հեռացնում է նրա հասցեները, հետ է քաշում դրա միջով անցնող երթուղիները և վերակառուցում աղբյուրի հասցեի ընտրությունը մնացածից։ Լռելյայն երթուղին տեղափոխվում է նոր դարպաս, և ինտերֆեյսի ինդեքսը, որին հղում էին անում հին կանոնները, անհետացել է կամ վերամշակվել է այլ սարքի համար։ Կապուղու համար լուծիչները նույնպես թարմացվում են, թեև ոչ երթուղիների հետ նույն պահին։ Այս ամենը տեղի է ունենում VPN հաճախորդից ներքև, ուստի հաճախորդը, որը հետևում է միայն իր թունելի վիճակին, դրանից ոչինչ չի տեսնում։

Դժբախտությունն այն է, որ կանոնը կոդավորում է կոնկրետ իդենտիֆիկատոր, այլ ոչ թե դրա հետևում եղած մտադրությունը։ Կանոնը, որը գցում է այն ամենը, ինչ դուրս չի գալիս թունելի ինտերֆեյսով, կոդավորում է ինտերֆեյսի անուն; կանոնը, որը թույլ է տալիս վերջնակետը, կոդավորում է հասցե, որը նոր ցանցը կարող է այլուր ուղղել։ Երբ իդենտիֆիկատորը վերանում է, կանոնը տեսանելիորեն սխալ չի դառնում․ այն կա՛մ դադարում է որևէ բանի համապատասխանել, կա՛մ սկսում է համապատասխանել սխալ բանի։

Վերակառուցել արտաքին թունելը՝ անցք չբացելով

Արտաքին տրանսպորտը կապված էր հին աղբյուրի հասցեին, ուստի այն պետք է նոր սոքեթ բացի նորից։ Երբ վերջնակետը հոսթի անուն է, այլ ոչ բառացի հասցե, որոնումը պետք է հաջողվի, քանի դեռ արգելափակումը ուժի մեջ է։ Սա է հերթականության թակարդը․ քաղաքականությունը, որը բավական խիստ է վերջնակետից բացի ամեն ինչ գցելու համար, կգցի նաև այն գտնելու համար անհրաժեշտ որոնումը, եթե լուծումը տեղի չունենա նախքան արգելափակումը վերացնելը կամ չտարվի դեռ կենդանի թունելով։ Երկու հերթականություններից որևէ մեկը կարող է աշխատել, բայց միայն այն դեպքում, երբ հաճախորդը գիտի, թե որում է գտնվում։

Հաճախորդներն այստեղ տարբերվում են մի կերպ, որը նշանակություն ունի ախտորոշելիս։ Ոմանք նախ լուծում են, հետո տեղադրում կանոնները, ուստի անցումը տեսանելի ընդհատում է արժենում և հետո ինքն իրեն վերականգնվում; մյուսները պահում են արգելափակումը և հույսը դնում վերապրած թունելի վրա, որ այն կտանի որոնումը, ինչը լիովին ձախողվում է, երբ թունելը մահացել է կապուղու հետ։ Լայն ուղիղ լռելյայն երթուղի ավելացնելը՝ կապը վերականգնելու համար, միշտ անցկացնում է թեստը և միշտ թողնում է այն արտահոսքը, որը դուք կանխում էիք։

Հին դարպասին դեռ մատնացույց անող երթուղին տալիս է նույն խրված վերականգնումը այլ պատճառից, ուստի կարդացեք աղյուսակը՝ նախքան հաճախորդին մեղադրելը։ Ներքևի հրամանները անվանում են այն ինտերֆեյսը և աղբյուրի հասցեն, որոնք միջուկը իսկապես կօգտագործի, և դա մեկ տողով որոշում է, թե հին ուղին դեռ տեղադրված է արդյոք։

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Երբ նոր կապուղին բերում է IPv6, իսկ կանոնները՝ ոչ

Բջջային և հյուր ցանցերը հաճախ տալիս են գլոբալ IPv6 նախածանց, նույնիսկ երբ գրասենյակի լարային LAN-ը երբեք դա չի արել։ Միայն IPv4 կանոններով գրված քաղաքականությունը՝ ձեռքով պատրաստված iptables-ի և nftables-ի բաղադրատոմսերի մեծ մասի լռելյայն ձևը, դրանից ոչինչ չի ծածկում։ Թունելը մնում է միացված, IPv6 հասանելիություն ունեցող հավելվածները դուրս են գալիս նրանից, և ցուցիչը չի կարող ցույց տալ տարբերությունը, որովհետև թունելն իսկապես վերևում է։ Հայելային դեպքը նույնքան սովորական է․ միայն IPv6-ի համար նախատեսված կանոնների հավաքածուն ոչինչ չի անում ցանցում, որը v6 չի առաջարկում։

Համեմատեք, թե ինչ է առաջարկում կապուղին, և ինչ է հիշատակում քաղաքականությունը, անցման երկու կողմերում։ Այս հրամանները տպում են նույն փաստերը, որոնցով աշխատում է հաճախորդը․

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Եթե երկրորդ հրամանը տպում է լռելյայն երթուղի, մինչ երրորդը զրո է վերադարձնում, նոր կապուղին կարող է մեքենան դուրս տանել IPv6-ով՝ առանց որևէ կանոնի հսկողության։ Անցումից հետո նորից գործարկեք բոլոր երեքը, քանի որ հետաքրքիր թիվը երկու գործարկումների տարբերությունն է։ Եթե երկրորդը ոչինչ չի տպում, գործում է հակառակ դեպքը, և ցանկացած v6-ծանր քաղաքականություն այնտեղ միայն զարդարանք է։

Լուծիչը ձեռքեր է փոխում նստաշրջանի կեսին

Ժամանակակից համակարգերում լուծիչները կապված են կապուղիներին, ուստի նոր կապուղին գալիս է լուծիչների նոր հավաքածուով և գուցե split-DNS-ի այլ պատկերով։ systemd-resolved-ը պահում է scope յուրաքանչյուր կապուղու համար և ընտրում նրանց միջև ըստ երթուղու, իսկ macOS-ը կարդում է scoped լուծիչները դինամիկ պահոցից և հարգում ինտերֆեյսների կարգը։ Հաճախորդը, որը տեղադրում է իր լուծիչը, մրցում է կապուղու լուծիչի հետ, և հաղթողին որոշում են առաջնահերթության կանոնները, որոնց ոչ ոք չի հետևում։ Այնուհետև անունների լուծումը կարող է կոտրվել, մինչ փաթեթների զտումը անում է հենց այն, ինչի համար գրվել է։

Կարդացեք ակտիվ լուծիչը, ոչ թե կարգավորվածը։ systemd հոսթում status ենթահրամանը ցույց է տալիս, թե որ կապուղուց է եկել յուրաքանչյուր scope-ը և արդյոք գործում է private-DNS անուն։

resolvectl status --no-pager
resolvectl query intranet.example.com

Եթե հարցումը դուրս է գալիս ֆիզիկական կապուղով, այլ ոչ թունելով, հաճախորդը պարտվել է առաջնահերթության մրցույթում, և ոչ մի հրապատի կարգավորում չի ուղղի անվանումը։ Համեմատեք հարցման ուղին անցման երկու կողմերում՝ տեսնելու, թե որն է տեղաշարժվել։ Անունը, որը լուծվում է մասնավոր հասցեի, որը նոր ցանցը չի կարող երթուղել, երրորդ դեպքն է, և այն երևում է որպես ժամանակի սպառում, այլ ոչ որպես սխալ։

Փորձեք անցումը և պահեք արձանագրությունը

Դիտավորյալ վերարտադրեք փոփոխությունը՝ փոխանակ սպասելու դրան։ Բարձրացրեք թունելը առաջին կապուղու վրա, սկսեք երկարատև փոխանցում և կրկնվող որոնում, ապա փոխեք կապուղին և տեսեք, թե որն է վերապրում։ Նշեք հին կապուղու անհետացման և թունելի միացված-հաղորդման միջև ընկած միջակայքը, քանի որ հենց այդ պատուհանում քաղաքականությունը դիմացավ կամ չդիմացավ։ Գործարկեք հաջորդականությունը նաև հակառակ ուղղությամբ, որպեսզի արդյունքը միակողմանի չլինի։

Բացառությունները պահանջում են իրենց անցումը, քանի որ հին ցանցում արդարացված շրջանցումը նորում ինքնաբերաբար արդարացված չէ։ Տան LAN-ի տպիչը, NAS-ը կամ captive portal-ը բջջայինում համարժեք չունեն, և բացառությունը, որը հասնում էր նրանց, դառնում է համարժեք չունեցող կանոն։

Գրեք ինտերֆեյսների անունները, առաջարկվող ընտանիքները, գործող լուծիչը և ընդհատման տևողությունը յուրաքանչյուր ուղղության համար։ Նորից միանալը ապացուցում է, որ տրանսպորտը վերականգնվել է, ոչ թե որ արգելափակումը դիմացել է բացվածքի ընթացքում, և դրանք առանձին պնդումներ են տոմսի համար։ Այդ արձանագրությամբ հաջորդ անցումը համեմատվում է հայտնի վիճակի հետ, ոչ թե հիշողության։