TAP, թե՞ TUN։ Android-ի OpenVPN հաճախորդներ և կամրջված սերվերներ
TAP-ը փոխանցում է Ethernet-ի շրջանակներ, TUN-ը՝ IP փաթեթներ, իսկ Android հավելվածը ստանում է միայն երկրորդ տեսակը։ Համեմատեք երկուսը, ապա ուղղեք սերվերի կողմը։
Նոութբուքի վրա աշխատող պրոֆիլը ձախողվում է հեռախոսում։ Ակնհայտ քայլը հաճախորդի կարգավորումներում մեկ բառ փոխելն է։ Այդ բառը չի օգնի, որովհետև երկու ծայրերը նույն տեսակի երթևեկության մասին չեն խոսում։
TAP-ը փոխանցում է Ethernet-ի շրջանակներ։ TUN-ը փոխանցում է IP փաթեթներ։ Android VPN հավելվածին տրվում է IP ինտերֆեյս, ինչը հնարավոր է դարձնում երկու դասավորություններից մեկը և անհնար՝ մյուսը, անկախ նրանից՝ ինչ է ասում կարգավորումը։
Համեմատությունը կարճ է, բայց այն որոշում է՝ կարող եք դա ուղղել հեռախոսում, թե պետք է փոխել ծառայությունը։
Երկու տեսակի թունել՝ տարբեր բեռնվածությամբ
TAP ինտերֆեյսը վարվում է Ethernet ադապտերի պես։ Այն փոխանցում է շրջանակներ, այսինքն՝ ARP, հեռարձակում և այն ամենը, ինչ LAN-ը փոխանցում է IP-ից ներքև։ Հենց դա է հնարավոր դարձնում կամրջումը. թունելը ընդլայնում է հեռարձակման տիրույթը, և հաճախորդները վարվում են այնպես, կարծես միացված են կոմուտատորին։
TUN ինտերֆեյսը փոխանցում է իրեն հասցեագրված IP փաթեթները։ Չկա համաձայնեցնելու կապող շերտ, չկա ARP և չկա հեռարձակում։ Երթուղավորումն է որոշում, թե ինչ է մտնում թունել, և սերվերի կողմի կարգավորումը կամուրջի փոխարեն օգտագործում է ենթացանց։
Երկու ծայրերը պետք է համաձայնեն, թե այդ երկուսից որն են անում։ Մի կողմում dev tap-ը dev tun-ով փոխելը չի վերափոխում ծառայությունը. ստացվում է հաճախորդ, որը սպասում է երթուղավորված թունելի, և սերվեր, որը դեռ շրջանակներ է ուղարկում, և ձեռքսեղմումը կարող է հաջողվել, մինչ օգտակար ոչինչ չի անցնում։
Ինչ է Android-ը փաստացի տալիս հավելվածին
Հարթակի VpnService API-ն հավելվածին տալիս է վիրտուալ ինտերֆեյս IP փաթեթների համար՝ կարգավորված հասցեներով, երթուղիներով և MTU-ով։ Այդ API-ում Ethernet ադապտեր չկա, և հավելվածը չի կարող այն հորինել։
Այդ պատճառով OpenVPN Connect-ը Android-ում փաստագրում է երթուղավորված TUN միացումների աջակցություն, այլ ոչ TAP կամրջում։ Android-ի հաճախ տրվող հարցերը այդ սահմանի հաճախորդային կողմի ձևակերպումն են, և այն համապատասխանում է հարթակի API-ին։
Root իրավունքներով ցանցային գործիքները, հատուկ որոնվածը կամ բացահայտ թարգմանության շերտ իրականացնող ապրանքը այլ դասավորություններ են։ Սովորական դեպքն այն է, ինչի շուրջ պետք է պլանավորել. հավելված, որը կարող է ներմուծել ձեր ֆայլը և աշխատել որպես սովորական օգտվող՝ IP ինտերֆեյսով և ոչինչ դրա տակ։
Ինչպիսին է այն, երբ այնուամենայնիվ փորձում եք
Միացումը սովորաբար հաստատվում է։ Հենց դա է ձախողումը շփոթեցնող դարձնում. հաճախորդը հաղորդում է միացման մասին, սերվերի մատյանը ցույց է տալիս զուգընկերոջ, և ոչ մի հավելված չի աշխատում։
Հեռախոսին տրված հասցեին ուղղված երթևեկությունը չի հասնում, որովհետև սերվերը շրջանակները կամրջում է MAC հասցեի, որը հեռախոսը երբեք չի ունեցել։ Հեռարձակումից կախված հայտնաբերումը մնում է դատարկ։ Եթե LAN-ը կամուրջով կախված է DHCP-ից, հեռախոսը այդպես վարձակալություն չի ստանա, և կամրջված ենթացանցում ձեռքով տրված հասցեն դեռ չի ստեղծում բացակայող ինտերֆեյսը։
Որոշ հաճախորդներ ավելի վաղ են ձախողվում՝ պրոֆիլի ներմուծման ժամանակ, երբ տեսնում են սարքի տեսակ, որը չեն կարող իրականացնել։ Երկու վարքագծերն էլ նույնն են նշանակում, և ոչ մեկը չի ուղղվում երթուղիներ ավելացնելով, DNS-ը փոխելով կամ թունելի հասցեների տիրույթը լայնացնելով։
Ինչ պետք է փոխի սերվերի կողմը
Ուղղումը պատկանում է նրան, ով շահագործում է VPN ծառայությունը, և այն սովորաբար հավելում է, ոչ թե միգրացիա։ Գործարկեք երկրորդ OpenVPN օրինակ՝ երթուղավորված սարքով, սեփական հաճախորդային ենթացանցով և սերվերի կողմի կարգավորումով, որը հասցեներ է տալիս և ուղարկում հեռախոսներին անհրաժեշտ երթուղիները։ Գոյություն ունեցող կամրջված օրինակը շարունակում է սպասարկել այն սարքերին, որոնց իսկապես պետք է Ethernet։
Երկու մանրամասն այն դարձնում են գործնականում աշխատունակ։ LAN-ին պետք է վերադարձի երթուղի նոր հաճախորդային ենթացանցի համար՝ ուղղված VPN հոսթին, այլապես պատասխանները երբեք չեն վերադառնա։ Եվ թունելի հոսթի ֆայրվոլը պետք է փոխանցի թունելի ինտերֆեյսի և LAN-ի միջև, և հենց այդ քայլն է ամենից հաճախ բաց թողնվում, երբ հոսթից իսկ արված փորձարկումը հաջողվում է։
Եթե օպերատորը չի կարող ծառայություն ավելացնել, այլընտրանքը սարքն է, որը կարող է միանալ կամրջին, այսինքն՝ նոութբուք կամ երթուղիչ, որը գործում է հեռախոսի անունից։ Դա սեփական կառավարման ծախսով շրջանցում է, ոչ թե Android կարգավորում։
Որոշեք հավելվածից, ոչ թե թունելից
Հարցրեք, թե հեռախոսն իսկապես ինչին պետք է հասնի, ապա քարտեզագրեք այն։ Անունով կամ հասցեով հասանելի ֆայլերի փոխանակումը կամ ինտրանետ կայքը IP պահանջ է, և երթուղավորված թունելը բավարարում է այն, երբ DNS-ը լուծում է անունը և երթուղին գոյություն ունի։ Տեղական հեռարձակման տիրույթը շրջող հայտնաբերման գործիքը IP պահանջ չէ, և երթուղավորման ոչ մի քանակություն այն չի լրացնի։
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
Այդ աղյուսակը նաև ուղարկվող հարցումն է։ Նշեք հավելվածը, դրա օգտագործած հասցեն կամ անունը և այն, թե արդյոք այն կախված է հայտնաբերումից։ Օպերատորը կարող է գործել այդ նկարագրով, ինչը ոչ ոք չի կարող անել չմիացող հեռախոսով։
Վերջապես, պահեք TAP ծառայությունը այն սարքերի համար, որոնց այն պետք է, փոխարենը ստիպելու յուրաքանչյուր հաճախորդի ընդօրինակել LAN ադապտեր։ Երկու հստակ նպատակով ծառայություններն ավելի հեշտ է աջակցել, քան մեկը, որն ամենքի համար կիսով է աշխատում։