Android always-on VPN. ինչպես է նախ լուծվում վերջնակետի անունը
Android-ը արգելափակում է թրաֆիկը մինչև թունելի ստեղծումը, սակայն հաճախորդը դեռ պետք է լուծի իր վերջնակետի անունը։ Ահա հերթականությունը և այն տեղը, որտեղ առաջանում է փակուղին։
Հեռախոսը վերագործարկվում է, always-on-ը միացված է, «block connections without VPN»-ը գործում է, բայց թունելը այդպես էլ չի բարձրանում։ Ոչինչ սխալ կարգավորված չէ. արգելափակումն անում է իր գործը, և հաճախորդի սեփական փորձը՝ հասնելու իր վերջնակետին, ենթարկվում է դրան։ Վերջնակետի անունը պետք է լուծվի մինչև թունելի գոյությունը, և դա անում է մի հաճախորդ, որին թույլատրվում է խոսել ցանցի հետ, մինչդեռ մնացած բոլոր հավելվածներին՝ ոչ։ Հասկանալը, թե որ բաղադրիչն է դա անում և ինչ հերթականությամբ, այս առեղծվածը վերածում է կարգավորման հարցի։
Ինչ է իրականում պահանջում VPN-ի կառուցիչը
Android VPN հավելվածը հարթակին չի տալիս սերվերի հասցե։ Այն կառուցում է լոկալ ինտերֆեյս՝ թունելի հասցեները և երթուղիները, այն լուծիչները, որ հավելվածները պետք է օգտագործեն դրա ներսում, և ապա establish()-ը վերադարձնում է ֆայլային դեսկրիպտոր, որը հավելվածը կարդում և գրում է որպես հում IP փաթեթներ։ Հեռավոր վերջնակետը այդ կառուցիչում ընդհանրապես չի հայտնվում։
Սա էական կառուցվածքային փաստ է։ Հարթակը ստեղծում է tun ինտերֆեյս և կիրառում է քաղաքականություն դրա վրա. հավելվածն իրականացնում է տրանսպորտը օգտագործողի տարածքում, այսինքն՝ հավելվածն ինքն է լուծում իր վերջնակետի անունը և բացում գաղտնագրված կապը։ Այսպիսով, անվան տեսքով վերջնակետը հնարավոր է. ոչ այն պատճառով, որ հարթակը աջակցում է անուններին, այլ այն պատճառով, որ հարթակը երբեք չի տեսնում վերջնակետը։
Մեկ դաշտ կառուցիչում այնուամենայնիվ ընդունում է հասցեներ՝ DNS սերվերները։ Դրանք պետք է լինեն լուծիչների թվային հասցեներ, սովորաբար այնպիսիները, որ օպերատորը ցանկանում է հարցնել թունելի միջոցով։ Այդ դաշտը նկարագրում է, թե ուր են հավելվածները ուղարկում հարցումները թունելի բարձրանալուց հետո։ Այն ոչինչ չի ասում այն մասին, թե ինչպես է հաճախորդը գտնում վերջնակետը, և հենց այս երկու կարգավորումների նույնացումն է, որտեղից սկսվում է շփոթությունը։
Երկու DNS հարց, ոչ մեկը
Առաջին հարցը. ուր են հավելվածները ուղարկում հարցումները, երբ թունելն արդեն բարձրացած է։ Պատասխանը թունելի ներսում գտնվող լուծիչի հասցե է, հասանելի tun ինտերֆեյսի միջոցով, ըստ կառուցվածքի՝ թվային։
Երկրորդ հարցը. ինչպե՞ս է հաճախորդը գտնում իր սեփական վերջնակետը մինչև այդ թունելի գոյությունը։ Այդ որոնումը տեղի է ունենում թունելից դուրս, հիմքում ընկած ցանցում, հաճախորդի պրոցեսում։ Այն կարող է օգտագործել անուն և պետք է օգտագործի լուծիչ, որը սարքը կարող է հասանել առանց VPN-ի։
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
Երեք փուլ, երեք տարբեր ախտանիշ։ Մեկ սխալի հաղորդագրություն, որն ասում է «հնարավոր չէ միանալ», միավորում է դրանք, և այդ պատճառով մարդիկ սկսում են խմբագրել DNS սերվերի դաշտը՝ ուղղելու համար խնդիր, որն առաջանում է դեռևս այդ դաշտը կարդալուց առաջ։
Ինչու bootstrap-ը կարող է փակուղի մտնել
Always-on-ը միացված արգելափակմամբ նշանակում է, որ VPN-ից դուրս թրաֆիկը դեն է նետվում, ներառյալ այն հավելվածի թրաֆիկը, որին պատկանում է VPN-ը։ Ելքը բացահայտ է. հավելվածը կանչում է protect() socket-ի վրա, ինչը կապում է այն հիմքում ընկած ցանցին, այնպես որ այն շրջանցում է թունելը և թույլատրվում է դուրս։ Յուրաքանչյուր VPN հաճախորդ պետք է դա անի իր տրանսպորտի համար, այլապես երբեք չի հասնի սերվերին։
Այժմ դիտարկենք տեղակայում, որտեղ միակ լուծիչը, որ գիտի վերջնակետի անունը, ինքն է թունելի ներսում։ Հաճախորդին թունել է պետք անունը լուծելու համար, և անուն՝ թունելը կառուցելու համար։ Սա իսկական շրջանաձև կախվածություն է, և ոչ մի հաճախորդի կարգավորում այն չի լուծում։ Սա ձևավորման սխալ է, ոչ թե բագ։
Ժամանակը նույն կախվածությունը ցույց է տալիս ավելի մեղմ ձևերով։ Բեռնման պահին՝ մինչև առաջին ապակողպումը, սարքը կարող է դեռ օգտագործելի ցանց չունենալ. captive portal-ի դեպքում ցանցը կա, բայց արգելափակում է ամեն ինչ, բացի պորտալից. Wi-Fi-ից բջջային ցանցին անցնելիս պաշտպանված socket-ի հիմքում ընկած ցանցը փոխվում է, և հաճախորդը պետք է նկատի դա և նորից լուծի անունը։ Դրանցից յուրաքանչյուրը bootstrap իրադարձություն է, և յուրաքանչյուրը արժե դիտավորյալ փորձարկել, այլ ոչ թե հայտնաբերել գիշերվա 3-ին։
Ինչու պատասխանի ամրացումը լուծում չէ
Գայթակղիչ շրջանցումը անունը մեկ անգամ լուծելն ու ստացված հասցեն թվային դաշտում տեղադրելն է, կամ այն կոշտ կոդավորելը հատուկ կառուցվածքում։ Թվում է, թե աշխատում է, և այն անունը վերածում է պատկերի։ Երբ օպերատորը տեղափոխում է վերջնակետը՝ միգրացիա, anycast փոփոխություն, նոր տարածաշրջանային հասցե, հաճախորդը շարունակում է զանգահարել հինին, և ինտերֆեյսում ոչինչ չի բացատրում ինչու։
DNS գրառումները կրում են կյանքի ժամկետ հենց նրա համար, որ պատասխանները կարող են փոխվել. քեշավորումը սահմանվում է այդ ժամկետով, ոչ թե ընդմիշտ։ Պատասխանի ամրացումը դեն է նետում այն մեխանիզմը, որն անունը դարձնում է ավելի լավ, քան հասցեն, միաժամանակ պահպանելով անուն օգտագործելու գործառնական ծախսը։
Ամրացումը սովորաբար ուղեկցվում է երկրորդ վատ սովորությամբ՝ ինքնության ստուգման թուլացմամբ, քանի որ կապն այժմ այլ կերպ է ձախողվում։ Սերվերի ինքնության ստուգումը bootstrap խնդրի մաս չէ, և դրա թուլացումը DNS անհարմարությունը փոխանակում է ընդհատման ռիսկի հետ։
Լուծումներ, որոնք դիմանում են վերագործարկմանը
Կայուն լուծումը անշուք է։ Օգտագործեք հաճախորդ, որը ճիշտ է իրականացնում պաշտպանված socket-ները և լուծում է իր վերջնակետը հիմքում ընկած ցանցում, և տվեք նրան վերջնակետի անուն, որը լուծվում է հրապարակայնորեն կամ թունելից առաջ հասանելի լուծիչի միջոցով։ Թողեք արգելափակումը միացված. այն ամբողջությամբ անջատելը, որպեսզի DNS-ը աշխատի, հեռացնում է այն հատկությունը, որի համար գոյություն ունի տեղակայումը։
Այնտեղ, որտեղ վերջնակետը պետք է մնա մասնավոր, ապահովեք բացահայտ bootstrap ուղի, որը հարթակը կարող է օգտագործել՝ թունելից առանց հասանելի լուծիչ, կամ օպերատորի պահպանած կառավարման կապ, և պահեք այդ բացառությունը նեղ և պատկանող քաղաքականությանը, ոչ թե օգտագործողի անջատիչին։ Android VpnService-ի փաստաթղթերը հղումն են այն բանի, թե ինչ է երաշխավորում հարթակը պաշտպանության և կենսացիկլի վերաբերյալ, և VpnService.Builder-ի հղումը հաստատում է, որ DNS դաշտը ընդունում է թվային հասցեներ։
Այնուհետև ստուգեք երեք փուլերը հերթականությամբ, վերագործարկումից հետո թարմ կապի վրա. վերջնակետի անունը լուծվում է, թունելը հաստատվում է և զուգընկերը նույնականանում է, և մասնավոր անունը լուծվում է թունելի լուծիչի միջոցով։ Եթե առաջին փուլը ձախողվում է, ոչ մի հետագա բան չի կարող աշխատել, և ուղղումը պատկանում է bootstrap ուղուն՝ երբեք լուծիչի դաշտին։
- Վերջնակետի լուծումը տեղի է ունենում հավելվածում, թունելից դուրս, պաշտպանված socket-ի վրա։
- Կառուցիչի DNS դաշտը նախատեսված է թունելի ներսում գտնվող հավելվածների համար, ոչ թե հաճախորդի սեփական վերջնակետի։
- Լուծիչը, որը հասանելի է միայն թունելի միջոցով, փակուղի է, ոչ թե դանդաղ մեկնարկ։
- Փորձարկեք վերջնակետը, նույնականացումը և մասնավոր որոնումը առանձին՝ վերագործարկումից հետո։