root-ը փոխում է, թե ինչ ցանցային գործողություններ կարող է փորձել պրոցեսը։ Այն հեռախոսին հանրությանը հասանելի հասցե չի տալիս, օպերատորի մոտ մուտքային քարտեզագրում չի վերապահում և վերագործարկումից հետո դեմոնին կենդանի չի պահում։ Եթե որոշում եք՝ կարո՞ղ է Android հեռախոսը հանդես գալ որպես VPN սերվեր, առանձնացրեք երեք հարց՝ կարո՞ղ է նախատեսված հաճախորդն ընդհանրապես հասնել լսողին, ի՞նչ արտոնությունների մոդել է պետք սերվերի իրականացմանը, և ի՞նչ պետք է փոխանցվի, երբ թունելն արդեն կանգնած է։

Ով և որտեղից պետք է հասնի հեռախոսին

Նույն թույլատրված LAN-ի հաճախորդը և բջջային տվյալների հաճախորդը փորձարկում են երկու տարբեր ցանցեր։ Նախ որոշեք նախատեսվածը, որովհետև պատասխանները չեն փոխանցվում։ Wi-Fi-ում չպահանջված մուտքային երթևեկությունը սովորաբար պահանջում է քարտեզագրում վերին երթուղիչում և դրանից այն կողմ օգտագործելի հանրային ուղի։ Բջջային ցանցում օպերատորի մակարդակի NAT-ը նշանակում է, որ մուտքային IPv4-ը հաճախ անհասանելի է, ինչ էլ թույլատրի հեռախոսը։

Հենց վերջին կետն է, որին root-ը չի կարող դիպչել։ Հեռախոսի տեղական firewall-ը և օպերատորի NAT-ը տարբեր համակարգեր են, և առաջինը փոխելը երկրորդի վրա ազդեցություն չունի։ Մասնավոր ինտերֆեյսի հասցեն, բջջային տվյալների պատկերակը կամ լսող socket-ը հասանելիության ապացույց չեն։ Եթե օպերատորի ուղին այնուամենայնիվ տրամադրում է գլոբալ երթուղվող IPv6, դրա համար դեռ պետք է նպատակային լսողի և firewall-ի քաղաքականություն. հասցե ունենալը նույնը չէ, ինչ միացումներ ընդունելը։

Client pathWhat actually decides reachability
Same LANThe phone's listener and its local firewall
Wi-Fi, from the internetA mapping on the upstream router plus a usable public path beyond it
Cellular IPv4The carrier's NAT, which the handset does not control
Cellular IPv6Address, listener and firewall policy together

Սպասարկումը և փոխանցումը երկու տարբեր հաջողություններ են

Ավարտված VPN ձեռքսեղմումը ապացուցում է, որ թունելը գոյություն ունի։ Այն չի ապացուցում, որ հաճախորդը կարող է հասնել հեռախոսի հետևի LAN-ին, և չի ապացուցում, որ հեռախոսը կարող է ծառայել որպես ինտերնետի ելք։ Դրանք առանձին կազմաձևեր են, որոնք կառուցվում են ներքին հասցեային պլանի, երթուղիների, վերադարձի վարքագծի և ձեր իրականում ուզած առաջադրանքի համար նեղ սահմանված փոխանցման քաղաքականության վրա։

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

Արտոնությունների մոդելը ընտրություն է, ոչ թե root կամ ոչինչ

Սովորական OpenVPN դեմոնը, որն օգտագործում է միջուկի TUN սարք, պահանջում է համապատասխան կարողություններ, հասանելիություն սարքի հանգույցին և Android-ի անվտանգության քաղաքականության համագործակցություն։ root-ը SELinux-ից համապարփակ բացառություն չէ. արտոնյալ պրոցեսը դեռ սահմանափակված է հարթակի քաղաքականությամբ։ Այդ պատճառով Linux սերվերում հանգիստ աշխատող բինարը կարող է ձախողվել հեռախոսում՝ առանց թույլտվությունների մասին ակնհայտ սխալի։

Օգտատիրոջ տարածությունում gateway-ի իրականացումը կարող է բոլորովին այլ արտոնությունների մոդել ունենալ, ուստի այն տարածված պնդումը, թե Android-ում յուրաքանչյուր VPN սերվեր root է պահանջում, չափազանց լայն է։ root-ը ձեզ տալիս է ավելի շատ գործողություններ փորձելու հնարավորություն, ոչ թե երաշխիք, որ դրանք կթույլատրվեն կամ արդյունքը հասանելի կլինի։

Android-ի սեփական VPN ծառայության գրանցումը ևս առանձին մեխանիզմ է։ Այն հավելվածին տալիս է կառավարվող հաճախորդի ինտերֆեյս՝ սահմանված կենսացիկլով. այն ընդհանուր սերվերի տեղադրիչ չէ, և տերմինալից դեմոն գործարկելը նրան չի տալիս մշտական կառավարում, հավելվածային քաղաքականություն կամ սեփական վերականգնման ուղի։

Եթե ելքի կետ եք ուզում, փոխեք ճարտարապետությունը

Երբ նպատակը պարզապես հեռախոսի միջոցով հեռավոր ինտերնետ ելքն է, այլ ոչ թե գոյություն ունեցող OpenVPN պրոֆիլի հետ համատեղելիությունը, ավելի հարմար լուծում է աջակցվող overlay ցանցի ելքային հանգույցը։ Tailscale-ը փաստաթղթավորում է Android ելքային հանգույցի դերը՝ իր գրանցման, թույլտվության և հաճախորդի ընտրության քայլերով։

Փոխանակումն իրական է և արժե ուղիղ ասել. դուք ընդունում եք այլ արձանագրություն, այլ վստահության մոդել և կախվածություն այդ հաշվից ու համակարգող ծառայությունից։ Այն չի ստիպում չփոփոխված OpenVPN հաճախորդին միանալ overlay ցանցին և ձեզ հանրային հասցեում OpenVPN լսող չի տալիս։

Ինչ է դեռ պետք տեղակայմանը

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

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

Առնչվող հոդվածներ