Android always-on VPN: како прво се решава името на крајната точка

Телефонот се рестартира, always-on е вклучен, „блокирај врски без VPN“ е вклучено, а тунелот никогаш не се крева. Ништо не е погрешно конфигурирано: блокирањето ја врши својата работа, а обидот на самиот клиент да ја достигне својата крајна точка исто така му е подложен. Името на крајната точка мора да се реши пред тунелот да постои, од клиент на кој му е дозволено да разговара со мрежата додека на сите други апликации не им е дозволено. Разбирањето кој компонент го прави тоа и по кој редослед, ја претвора оваа загатка во конфигурациско прашање.

Што всушност бара градителот на VPN

Android VPN апликација не и дава на платформата адреса на сервер. Таа гради локален интерфејс: адреси и маршрути за тунелот, резолверите што апликациите треба да ги користат внатре во него, а потоа establish() враќа датотечен дескриптор што апликацијата го чита и пишува како сурови IP пакети. Оддалечената крајна точка воопшто не се појавува во тој градител.

Тоа е клучниот структурен факт. Платформата создава tun интерфејс и применува политика врз него; апликацијата го имплементира транспортот во кориснички простор, што значи дека самата апликација го решава името на својата крајна точка и ја отвора шифрираната врска. Затоа крајна точка во вид на име на домаќин е возможна — не затоа што платформата поддржува имиња, туку затоа што платформата никогаш не ја гледа крајната точка.

Едно поле во градителот сепак прима адреси: DNS серверите. Тие мора да бидат нумерички адреси на резолвери, обично оние што операторот сака да ги праша преку тунелот. Тоа поле опишува каде апликациите ги праќаат барањата откако тунелот ќе се крене. Не кажува ништо за тоа како клиентот ја наоѓа крајната точка, и токму изедначувањето на овие две поставки е почетокот на конфузијата.

Две DNS прашања, не едно

Првото прашање е: каде апликациите ги праќаат барањата кога тунелот е кренат? Одговорот е адреса на резолвер внатре во тунелот, достапна преку tun интерфејсот, и по конструкција нумеричка.

Второто прашање е: како клиентот ја наоѓа својата крајна точка пред тој тунел да постои? Тоа пребарување се случува надвор од тунелот, на основната мрежа, во процесот на клиентот. Може да користи име, и мора да користи резолвер што уредот може да го достигне без VPN.

Три фази, три различни симптоми. Една порака за грешка што вели „не може да се поврзе“ ги спојува, и затоа луѓето почнуваат да го уредуваат полето за DNS сервер за да решат проблем што се случува пред тоа поле воопшто да се прочита.

Зошто bootstrap може да се заглави

Always-on со вклучено блокирање значи дека сообраќајот што не е внатре во VPN се отфрла, вклучително и сообраќајот на апликацијата што го поседува VPN-от. Излезот е експлицитен: апликацијата повикува protect() на сокет, што го врзува за основната мрежа, па тој го заобиколува тунелот и му е дозволено да излезе. Секој VPN клиент мора да го прави тоа за својот транспорт, инаку никогаш нема да стигне до сервер.

Сега разгледај распоредување каде единствениот резолвер што го знае името на крајната точка е самиот внатре во тунелот. На клиентот му треба тунелот за да го реши името, и името за да го изгради тунелот. Тоа е вистинска кружна зависност, и ниту една конфигурација на клиентот не ја решава. Тоа е грешка во дизајнот, не грешка во програмата.

Времето ја покажува истата зависност во поблаги форми. При подигнување пред првото отклучување, уредот може сè уште да нема употреблива мрежа; на captive portal мрежата постои но блокира сè освен порталот; при премин од Wi-Fi на мобилна мрежа, основната мрежа на заштитениот сокет се менува и клиентот мора да го забележи тоа и повторно да го реши името. Секој од нив е bootstrap настан, и секој вреди намерно да се тестира, наместо да се открие во 3 часот наутро.

Зошто фиксирањето на одговорот не е решение

Примамливиот заобиколен пат е да се реши името еднаш и добиената адреса да се залепи во нумеричко поле, или да се вгради во прилагодена изградба. Изгледа дека работи, и го претвора името во снимка. Кога операторот ја преместува крајната точка — миграција, промена на anycast, нова регионална адреса — клиентот продолжува да ѕвони на старата и ништо во интерфејсот не објаснува зошто.

DNS записите имаат време на живеење точно затоа што одговорите можат да се променат; кеширањето се дефинира според тој рок, не засекогаш. Фиксирањето на одговор го отфрла механизмот што го прави името подобро од адресата, додека ги задржува оперативните трошоци од користењето на име.

Фиксирањето обично оди заедно со втора лоша навика: олабавување на проверката на идентитетот бидејќи врската сега не успева поинаку. Проверката на идентитетот на серверот не е дел од bootstrap проблемот, и нејзиното слабеење ја заменува DNS непријатната страна за ризик од пресретнување.

Дизајни што преживуваат рестартирање

Трајното решение е ненаметливо. Користи клиент што правилно имплементира заштитени сокети и ја решава својата крајна точка на основната мрежа, и дај му име на крајна точка што се решава јавно, или преку резолвер достапен пред тунелот. Остави го блокирањето вклучено; целосното исклучување за DNS да работи ја отстранува особината поради која распоредувањето постои.

Каде крајната точка мора да остане приватна, обезбеди експлицитен bootstrap пат што платформата може да го користи — резолвер достапен без тунел, или управувачка врска што ја одржува операторот — и држи го тој исклучок тесен и во сопственост на политиката, а не на корисничко копче. Документацијата на Android VpnService е референца за тоа што платформата гарантира за заштитата и животниот циклус, и референцата за VpnService.Builder потврдува дека DNS полето прима нумерички адреси.

Потоа провери ги трите фази, по ред, на нова врска по рестартирање: името на крајната точка се решава, тунелот се воспоставува и партнерот се автентицира, и приватното име се решава преку резолверот на тунелот. Ако првата фаза не успее, ништо подоцна не може да работи, и поправката припаѓа на bootstrap патот — никогаш на полето за резолвер.

• Решавањето на крајната точка се случува во апликацијата, надвор од тунелот, на заштитен сокет.
• DNS полето во градителот е за апликации внатре во тунелот, не за сопствената крајна точка на клиентот.
• Резолвер достапен само преку тунелот е заглавување, не бавно стартување.
• Тестирај ги крајната точка, автентикацијата и приватното пребарување одделно по рестартирање.