Երկու VPN հավելված միաժամանակ՝ ո՞ր kill switch-ն է իրոք գործում։
Երկրորդ VPN հաճախորդը երբեք չի ժառանգում առաջինի kill switch-ը։ Թե որ քաղաքականությունն է գործում, որոշում են երեք պայման, և ինչպես ստուգել ձերը։
Երկու VPN հաճախորդ կարող են աշխատել կողք կողքի, սակայն նրանց kill switch-ները չեն միաձուլվում մեկ քաղաքականության մեջ։ Յուրաքանչյուր հաճախորդ տեղադրում է կանոններ իր թունելի համար, և ոչ մեկը չգիտի, որ մյուսը գոյություն ունի։ Ես սրան հանդիպեցի, երբ սկզբում միացված էր աշխատանքային հաճախորդը․ երկրորդ հավելվածը չկարողացավ ավարտին հասցնել ձեռքսեղմումը, տասը րոպե մնաց „Connecting“-ի վրա, և առաջին թունելը լուռ տարավ ամեն ինչ։ Արդյոք երկրորդ հավելվածը կպաշտպանվի, կախված է երեք պայմանից, ոչ թե նրանից, թե երկու պատկերակներն էլ ասում են Միացված։
Ինչով է kill switch-ը իրականում սահմանափակված
Օպերացիոն համակարգում մեկ kill switch դրոշ չկա։ Այնպիսի բան գովազդող հաճախորդը տեղադրում է կանոնների հավաքածու՝ դեն նետիր ամեն ինչ, որ չի ելնում իմ թունելով, և հաճախ fail closed վարվիր, երբ թունելը անհետանում է։ Linux-ում դա սովորաբար nftables կամ iptables շղթա է, Windows-ում Windows Filtering Platform զտիչների հավաքածու, Android-ում և iOS-ում՝ բուն թունելի ծառայության երթուղումը գումարած համակարգային կարգավորումը, որը արգելափակում է առանց VPN կապերը։ Android VPN ուղեցույցը նկարագրում է այդ ծառայության մոդելը, եթե ուզում եք հարթակի տեսակետը։
Ծածկույթը կարևոր մասն է։ „Թույլատրել միայն փաթեթները wg0 ելքային ինտերֆեյսի վրա“ կանոնը չի հետաքրքրվում՝ կա՞ երկրորդ թունել։ Եթե մեկ այլ հաճախորդ բարձրացնի wg1-ը, առաջին հաճախորդի կանոնները այդ փաթեթները կհամարեն սովորական տրաֆիկ՝ սովորաբար դեն են նետվում, երբեմն թույլատրվում։ Ամեն դեպքում որոշում է առաջին հաճախորդը և գաղափար չունի, որ երկրորդ հավելվածը սպասում է։
Երեք պայման, որոնք որոշում են՝ ով կծածկվի
Պետք չէ թվարկել բոլոր համակցությունները։ Երեք հարց դա լուծում է մի քանի րոպեում։
- Հարթակն ընդհանրապես թույլատրու՞մ է երկրորդ թունել։ Android հեռախոսների և iPhone-ների մեծ մասը մեկ օգտվողի պրոֆիլի համար ընդունում է միայն մեկ ակտիվ VPN ծառայություն, ուստի երկրորդ հավելվածը երբեք թունել չի ունենում և ոչինչ չի կիրառում։ Դուք ստանում եք մեկ քաղաքականություն՝ այն հավելվածից, որը հաղթեց տեղը։
- Ո՞ր պրոցեսին է պատկանում լռելյայն երթուղին։ Windows-ը, macOS-ը և Linux-ը հանգիստ տանում են երկու թունել։ Լռելյայն երթուղին պատկանում է այն հաճախորդին, որը այն կարգավորել է վերջինը կամ ավելի լավ մետրիկայով, իսկ մյուս հաճախորդը միացված է, բայց պարապ։ Linux-ում wg-quick-ի լռելյայն երթուղու ռեժիմը օգտագործում է քաղաքականությամբ պայմանավորված երթուղում՝ առանձին աղյուսակով և fwmark կանոնով, ուստի երկրորդ wg-quick թունելը ավելացնում է մրցակցող կանոն՝ առաջինը փոխարինելու փոխարեն։
- Կարո՞ղ է երկրորդ հաճախորդը հասնել իր սեփական սերվերին։ Եթե առաջին kill switch-ը լռելյայն մերժում է, երկրորդ հավելվածի արտաքին վերջնակետը պարզապես ևս մեկ դեն նետված նպատակ է։ Այն լուռ կրկնում է փորձը և երբեք սխալ չի հաղորդում։
Կարճ տարբերակը՝ աջակցության թեմաների համար՝
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Այդ տողերից երկուսը համակարգային սկուտեղի պատկերակից նույնն են երևում, դրա համար էլ պատկերակը այստեղ հասանելի ամենավատ ապացույցն է։
Ինչն է առաջինը խափանվում և ինչպես է երևում
Մի հաճախորդ, որը կախված է „Connecting“-ի վրա, մինչ մյուսը առողջ է, գրեթե միշտ վերջնակետի սով է․ աշխատող kill switch-ը դեն է նետում երկրորդ հաճախորդի ձեռքսեղմումը դեպի իր սեփական սերվերը։ Հաստատեք դա էժանորեն՝ առաջին հաճախորդի արգելափակման կանոնները մեկ փորձով դադարեցնելով։ Եթե երկրորդը անմիջապես միանա, հարցը պատասխանված է։
DNS-ը երկրորդ խափանումն է։ Հաճախորդները լուծիչի կարգավորումը դնում են իրենց ինտերֆեյսի համար, և ոմանք ուղղակի վերագրում են գլոբալ ցանկը։ Երկու թունելներն էլ բարձրացված՝ հարցումները կարող են դուրս գալ մի կողմից, մինչ լուծիչը պատկանում է մյուսին։ Անջատեք հավելվածներից մեկը, և ողջ մնացածը պահում է անհասանելի անունների սերվեր․ էջերը մեկ րոպե կանգ են առնում, ապա նորից լուծվում, մինչ VPN-ը դեռ ցույց է տալիս միացված։
Երրորդը երթուղիների ցնցումն է։ Վերամիացումները վերադասավորում են լռելյայն երթուղին, և ինտերֆեյսին կապված kill switch-ը չի հետևում դրան։ Տրաֆիկը, որը մի պահ առաջ թունելի մեջ էր, հիմա համապատասխանում է դեն նետելու կանոնին, ինչը օգտվողի կողմից կարդացվում է որպես պատահաբար աշխատելը դադարող VPN։
Ստուգեք, թե որ քաղաքականությունն է իրոք ուժի մեջ
Արեք դա անվնաս տրաֆիկով, ոչ թե մի բանով, որ կկարոտեք։
Linux-ում հարցրեք միջուկին՝ ով է հաղթում և ինչին է կապվում հրաձիգ պատը։ ip -4 route show default նշում է թունելը, որին պատկանում է ելքը։ ip rule show ցույց է տալիս՝ քաղաքականությամբ պայմանավորված երթուղումը խաղի մեջ է արդյոք։ sudo nft list ruleset | grep -n oifname ցույց է տալիս՝ դեն նետումները կապված են ինտերֆեյսի անվան, նշանի, թե ամբողջ ելքային շղթայի հետ։
Windows-ում նույն պատմությունը ապրում է երթուղու մետրիկայում և զտիչների ցանկում՝ Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric և Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN"։ macOS-ում՝ netstat -rn -f inet | head -5 և scutil --dns | head -20։
Ապա արեք այն քայլը, որը մարդիկ բաց թողնում են․ դիտավորյալ կանգնեցրեք թունելը և հաստատեք, որ տրաֆիկը, որի ձախողումը սպասում եք, իրոք ձախողվում է։ Միացված պատկերակը ինտերֆեյսի վիճակ է, ոչ թե կիրարկում։
Երբ երկու հաճախորդը սխալ ձևավորում է
Եթե երկրորդ հավելվածի հետևում միակ պահանջը ավելի շատ պաշտպանություն է, հեռացրեք այն։ Երկու փոխազդող արգելափակման քաղաքականություն ավելի քիչ կանխատեսելի է, քան մեկը, և յուրաքանչյուր վերամիացում հնարավորություն է հայտնվելու վիճակում, որը ոչ մի մատակարար չի փորձարկում։
Եթե իրոք պետք է շղթայավորում, օրինակ՝ առևտրային ցատկով հասանելի կորպորատիվ դարպաս, ընտրեք մեկ կիրարկման կետով ձևավորում։ Դա սովորաբար նշանակում է երթուղիչ կամ մեկ հաճախորդ, որը սատարում է շղթան, և ոչ թե երկու աշխատասեղանի հավելված, որոնք մրցում են նույն լռելյայն երթուղու համար։ Կառավարվող սարքում պահեք թույլատրված հաճախորդը և մնացած ամեն ինչ համարեք շրջանակից դուրս՝ անկախ նրանից, թե ինչ է ցույց տալիս սկուտեղում։
Ստուգաթերթ նախքան երկուսն էլ պահելը
Անցեք ցանկը հերթականությամբ․ առաջին ձախողվող կետն այն է, ինչը պետք է ուղղել։
- Հաստատեք, որ ճիշտ մեկ հաճախորդ է տիրապետում լռելյայն երթուղուն և լուծիչին։
- Եթե ուզում եք երկրորդ հաճախորդը բարձրացված, հստակ թույլատրեք նրա սերվերի վերջնակետը և յուրաքանչյուր թարմացումից հետո նորից ստուգեք։
- Գրի առեք սպասվող արդյունքը, երբ թունելներից մեկն ընկնում է, և փորձարկեք հենց այդ դեպքը։
- Ստուգեք խափանման ուղին վերագործարկումից հետո, երբ մեկնարկի հերթականությունը տարբեր է։
- Կառավարվող պրոֆիլում կանգ առեք և նախքան որևէ բան ավելացնելը հարցրեք սեփականատիրոջը։
Եթե երրորդ քայլը ձախողվում է, ազնիվ պատասխանն այն է, որ միայն մեկ հաճախորդ է ձեզ քաղաքականություն տալիս։ Որոշեք, թե որին եք վստահում, և թողեք մյուսը գնա։