Android винаги включен VPN: как името на крайната точка се разрешава първо

Телефонът се рестартира, винаги включено е активирано, блокиране на връзки без VPN е включено, а тунелът така и не се вдига. Нищо не е конфигурирано грешно: блокадата си върши работата и собственият опит на клиента да достигне крайната точка също е подчинена на нея. Крайната точка трябва да се разреши, преди тунелът да съществува, от клиент, на който е разрешено да говори с мрежата, докато на всяко друго приложение не е. Разбирането кой компонент прави това и в какъв ред превръща загадката в конфигурационен въпрос.

Какво всъщност иска конструкторът на VPN

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

Това е ключовият структурен факт. Платформата създава tun интерфейс и налага политика върху него; приложението реализира транспорта в потребителско пространство, тоест самото то разрешава името на крайната точка и отваря криптираната връзка. Затова име на хост е възможно, не защото платформата поддържа имена, а защото платформата никога не вижда крайната точка.

Едно поле на конструктора приема адреси: DNS сървърите. Те трябва да са числови адреси на резолвери, обикновено тези, които операторът иска да бъдат питани през тунела. Това поле описва къде приложенията изпращат заявки, след като тунелът е вдигнат. То не казва нищо за това как клиентът намира крайната точка, а да се третират двете като една настройка е началото на объркването.

Два DNS въпроса, не един

Първият въпрос е: къде приложенията изпращат заявки, след като тунелът е вдигнат? Отговорът е адрес на резолвер вътре в тунела, достъпен през tun интерфейса, числов по конструкция.

Вторият въпрос е: как клиентът намира собствената си крайна точка, преди този тунел да съществува? Това търсене става извън тунела, в подлежащата мрежа, в процеса на клиента. То може да ползва име и трябва да ползва резолвер, до който устройството достига без VPN.

Три етапа, три различни симптома. Едно съобщение за грешка като не може да се свърже ги слива и затова хората редактират полето за DNS сървър, за да оправят проблем, който се случва, преди то изобщо да бъде прочетено.

Защо първоначалното стартиране може да блокира

Винаги включено с активирана блокада означава, че трафикът извън VPN се изхвърля, включително трафикът на приложението, което притежава VPN. Изходът е изричен: приложението извиква protect() върху сокет, което го обвързва с подлежащата мрежа, така че заобикаля тунела и му е позволено да излезе. Всеки VPN клиент трябва да направи това за собствения си транспорт, иначе никога не би стигнал до сървър.

Представете си внедряване, при което единственият резолвер, който знае името на крайната точка, е самият той вътре в тунела. Клиентът се нуждае от тунела, за да разреши името, и от името, за да построи тунела. Това е истинска кръгова зависимост и никаква клиентска конфигурация не я решава. Това е грешка в дизайна, не бъг.

Времето показва същата зависимост в по-лека форма. При стартиране преди първото отключване устройството може още да няма използваема мрежа; в пленен портал мрежата съществува, но блокира всичко освен портала; при преминаване от Wi-Fi към мобилна мрежа подлежащата мрежа на защитения сокет се сменя и клиентът трябва да го забележи и да разреши отново. Всяко от тези е събитие по стартирането и заслужава съзнателен тест, вместо да бъде открито в 3 часа през нощта.

Защо заковаването на отговора не е решение

Изкушаващото решение е името да се разреши веднъж и адресът да се постави в числово поле или да се твърдо кодира в собствена сборка. Изглежда, че работи, и превръща името в снимка. Когато операторът премести крайната точка, чрез миграция, anycast промяна или нов регионален адрес, клиентът продължава да набира стария и нищо в интерфейса не обяснява защо.

DNS записите носят време за живот точно за да могат отговорите да се менят; кеширането се определя от този срок, а не завинаги. Заковаването на отговор изхвърля механизма, който прави името по-добро от адреса, но запазва оперативната цена на използването на име.

Заковаването често върви с втори лош навик: разхлабване на проверките за идентичност, защото връзката сега се проваля по друг начин. Проверката на самоличността на сървъра не е част от проблема със стартирането и смекчаването и разменя едно DNS неудобство срещу риск от прихващане.

Дизайни, които издържат на рестарт

Издръжливата уредба е невпечатляваща. Използвайте клиент, който правилно реализира защитени сокети и разрешава крайната си точка в подлежащата мрежа, и му дайте име на крайна точка, което се разрешава публично или през резолвер, достъпен преди тунела. Оставете блокадата включена; изключването и напълно, за да работи DNS, премахва свойството, за което съществува внедряването.

Където крайната точка трябва да остане частна, осигурете изричен път за стартиране, който платформата може да ползва, например резолвер, достъпен без тунела, или управляваща връзка, поддържана от оператора, и дръжте това изключение тясно и притежавано от политика, а не от потребителски превключвател. Документацията на Android VpnService е източникът за това какво гарантира платформата за защита и жизнен цикъл, а справката за VpnService.Builder потвърждава, че полето за DNS приема числови адреси.

После проверете в трите етапа, по ред, на нова връзка след рестарт: името на крайната точка се разрешава, тунелът се установява и партньорът се удостоверява, а частно име се разрешава през резолвера на тунела. Ако първият етап се провали, нищо след него не може да работи и поправката е в пътя за стартиране, никога в полето за резолвер.

• Разрешаването на крайната точка става в приложението, извън тунела, върху защитен сокет.
• Полето за DNS в конструктора е за приложения вътре в тунела, не за собствената крайна точка на клиента.
• Резолвер, достъпен само през тунела, е задънена улица, не бавно стартиране.
• Тествайте крайната точка, удостоверяването и частното търсене поотделно след рестарт.