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 порталу мрежа постоји, али блокира све осим портала; при преласку са Wi-Fi на мобилну мрежу основна мрежа заштићеног сокета се мења и клијент то мора да примети и поново разреши. Сваки од тих је bootstrap догађај, и сваки вреди намерно тестирати уместо открити у 3 сата ујутру.

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

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

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

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

Дизајни који преживљавају рестарт

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

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

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

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