Android always-on VPN: endpoint атауы неге бірінші шешіледі

Телефон қайта жүктеледі, always-on қосулы, «VPN жоқ қосылымдарды блоктау» қосулы, бірақ туннель ешқашан көтерілмейді. Ешнәрсе дұрыс емес конфигурацияланбаған: блоктау өз жұмысын істеп тұр және клиенттің өз endpoint-іне жету әрекеті соған бағынады. Endpoint атауы туннель пайда болғанға дейін, қалған барлық қолданбаларға рұқсат етілмеген кезде желімен сөйлесуге рұқсаты бар клиент арқылы шешілуі керек. Қай компонент мұны жасайтынын және қандай ретпен жасайтынын түсіну осы жұмбақты конфигурация мәселесіне айналдырады.

VPN құрастырушы шын мәнінде нені сұрайды

Android VPN қолданбасы платформаға сервер мекенжайын бермейді. Ол жергілікті интерфейс құрады: туннель үшін мекенжайлар мен маршруттар, қолданбалар оның ішінде пайдалануы тиіс шешкіштер, содан кейін establish() қолданба шикі IP пакеттер ретінде оқитын және жазатын файл дескрипторын қайтарады. Қашықтағы endpoint бұл құрастырушыда мүлде көрінбейді.

Бұл негізгі құрылымдық факт. Платформа tun интерфейсін жасап, оған саясатты қолданады; қолданба тасымалды пайдаланушы кеңістігінде іске асырады, яғни қолданбаның өзі endpoint атауын шешіп, шифрланған қосылымды ашады. Сондықтан хост атауы түріндегі endpoint мүмкін — платформа атауларды қолдайтындықтан емес, платформа endpoint-ті ешқашан көрмейтіндіктен.

Құрастырушының бір өрісі ғана мекенжай қабылдайды: DNS серверлері. Олар сандық шешкіш мекенжайлары болуы керек, әдетте оператор туннель арқылы сұрағысы келетіндер. Бұл өріс туннель көтерілгеннен кейін қолданбалар сұрауларды қайда жіберетінін сипаттайды. Ол клиенттің endpoint-ті қалай табатыны туралы ештеңе айтпайды, және осы екі параметрді бірдей деп қарау шатасудың бастауы.

Бір емес, екі DNS сұрағы

Бірінші сұрақ: туннель көтерілгеннен кейін қолданбалар сұрауларды қайда жібереді? Жауап — туннельдің ішіндегі шешкіш мекенжайы, tun интерфейсі арқылы қолжетімді және құрылысы бойынша сандық.

Екінші сұрақ: клиент өзінің endpoint-ін осы туннель пайда болғанға дейін қалай табады? Бұл іздеу туннельден тыс жерде, негізгі желіде, клиент процесінде жүреді. Ол атауды пайдалана алады және құрылғы VPN-сіз жете алатын шешкішті пайдалануы керек.

Үш кезең, үш түрлі белгі. «Қосылу мүмкін емес» деген бір қате хабарламасы оларды біріктіріп жібереді, сондықтан адамдар сол өріс оқылғанға дейін болатын мәселені түзету үшін DNS сервері өрісін өңдей бастайды.

Bootstrap неге тұйыққа тірелуі мүмкін

Always-on қосулы блоктаумен VPN ішінде емес трафиктің тасталатынын білдіреді, соның ішінде VPN-ге ие қолданбаның трафигі де. Шығу жолы айқын: қолданба сокетте protect() шақырады, бұл оны негізгі желіге байланыстырады, сондықтан ол туннельді айналып өтіп, сыртқа шығуға рұқсат алады. Әрбір VPN клиенті мұны өз тасымалы үшін жасауы керек, әйтпесе серверге ешқашан жетпейді.

Енді endpoint атауын білетін жалғыз шешкіш туннельдің ішінде болатын орналастыруды қарастырайық. Клиентке атауды шешу үшін туннель керек, ал туннельді құру үшін атау керек. Бұл шынайы циклдік тәуелділік және оны ешбір клиент конфигурациясы шешпейді. Бұл дизайн қатесі, баг емес.

Уақыт сол тәуелділікті жұмсақ формаларда көрсетеді. Жүктелу кезінде, бірінші құлпы ашылғанға дейін, құрылғыда әлі жарамды желі болмауы мүмкін; captive portal кезінде желі бар, бірақ порталдан басқаның бәрін бөгейді; Wi-Fi-дан ұялы желіге ауысқанда қорғалған сокеттің негізгі желісі өзгереді және клиент мұны байқап, қайта шешуі керек. Олардың әрқайсысы bootstrap оқиғасы және әрқайсысын түнгі 3-те тапқанша әдейі тексерген жөн.

Неге жауапты бекіту шешім емес

Азғырмалы айналма жол — атауды бір рет шешіп, алынған мекенжайды сандық өріске қою немесе оны теңшелімді жинақта қатты кодтау. Ол жұмыс істеп тұрғандай көрінеді және атауды суретке айналдырады. Оператор endpoint-ті жылжытқанда — көшіру, anycast өзгерісі, жаңа аймақтық мекенжай — клиент ескісіне қоңырау шала береді және интерфейсте ештеңе себебін түсіндірмейді.

DNS жазбаларының өмір сүру уақыты дәл жауаптар өзгеруі мүмкін болғандықтан бар; кэштеу осы мерзіммен анықталады, мәңгілік емес. Жауапты бекіту атауды мекенжайдан артық ететін механизмді тастайды, сонымен бірге атауды пайдаланудың операциялық құнын сақтайды.

Бекіту әдетте екінші жаман әдетпен бірге жүреді: қосылым енді басқаша істен шыққандықтан, сәйкестікті тексеруді әлсірету. Сервер сәйкестігін тексеру bootstrap мәселесінің бөлігі емес және оны әлсірету DNS қолайсыздығын ұстап қалу тәуекеліне айырбастайды.

Қайта жүктеуге төзетін дизайндар

Төзімді шешім әсем емес. Қорғалған сокеттерді дұрыс іске асыратын және endpoint-ін негізгі желіде шешетін клиентті пайдаланыңыз және оған ашық жолмен немесе туннельге дейін қолжетімді шешкіш арқылы шешілетін endpoint атауын беріңіз. Блоктауды қосулы қалдырыңыз; DNS жұмыс істесін деп оны толық өшіру орналастыру бар болуының себебі болып табылатын қасиетті жояды.

Endpoint құпия болып қалуы керек жерде платформа пайдалана алатын айқын bootstrap жолын қамтамасыз етіңіз — туннельсіз қолжетімді шешкіш немесе оператор ұстап тұрған басқару қосылымы — және бұл ерекшелікті тар ұстап, пайдаланушы сөндіргішіне емес, саясатқа тиесілі етіңіз. Android VpnService құжаттамасы платформаның қорғау мен өмірлік цикл бойынша нені кепілдейтінінің анықтамасы, ал VpnService.Builder анықтамасы DNS өрісінің сандық мекенжайларды қабылдайтынын растайды.

Содан кейін қайта жүктеуден кейінгі жаңа қосылымда үш кезеңді ретімен тексеріңіз: endpoint атауы шешіледі, туннель орнайды және серіктес аутентификациядан өтеді, құпия атау туннель шешкіші арқылы шешіледі. Бірінші кезең сәтсіз болса, кейінгі ешнәрсе жұмыс істемейді және түзету bootstrap жолына тиесілі — ешқашан шешкіш өрісіне емес.

• Endpoint-ті шешу қолданбаның ішінде, туннельден тыс, қорғалған сокетте жүреді.
• Құрастырушыдағы DNS өрісі туннель ішіндегі қолданбаларға арналған, клиенттің өз endpoint-іне емес.
• Тек туннель арқылы қолжетімді шешкіш — баяу басталу емес, тұйық.
• Қайта жүктеуден кейін endpoint-ті, аутентификацияны және құпия іздеуді бөлек тексеріңіз.