TAP чи TUN? Клієнти OpenVPN для Android і сервери з мостом

Профіль, який працює на ноутбуці, не працює на телефоні. Очевидний крок — змінити одне слово в конфігурації клієнта. Це слово не допоможе, бо два боки говорять не про один і той самий тип трафіку.

TAP передає кадри Ethernet. TUN передає IP-пакети. Застосунку VPN на Android надається IP-інтерфейс, і це робить одну з двох схем можливою, а іншу — ні, незалежно від того, що каже конфігурація.

Порівняння коротке, але воно вирішує, чи можна виправити це на телефоні, чи доведеться змінювати службу.

Два типи тунелів з різним корисним навантаженням

Інтерфейс TAP поводиться як адаптер Ethernet. Він передає кадри, тобто ARP, широкомовлення і все інше, що LAN передає нижче IP. Саме це уможливлює міст: тунель розширює домен широкомовлення, а клієнти поводяться так, ніби підключені до комутатора.

Інтерфейс TUN передає IP-пакети, адресовані йому. Немає канального рівня для узгодження, немає ARP і немає широкомовлення. Що потрапляє в тунель, вирішує маршрутизація, а конфігурація на боці сервера використовує підмережу, а не міст.

Обидва боки мають узгодити, який із двох варіантів вони роблять. Заміна dev tap на dev tun з одного боку не перетворює службу; з’являється клієнт, який очікує маршрутизований тунель, і сервер, який усе ще надсилає кадри, і рукостискання може вдатися, поки нічого придатного не проходить.

Що Android насправді дає застосунку

API VpnService платформи дає застосунку віртуальний інтерфейс для IP-пакетів, налаштований адресами, маршрутами і MTU. У цьому API немає адаптера Ethernet, і застосунок не може його вигадати.

Тому OpenVPN Connect документує підтримку маршрутизованих з’єднань TUN на Android, а не мосту TAP. Поширені запитання про Android — це заява з боку клієнта про цю межу, і вона відповідає API платформи.

Мережеві інструменти з root, власна прошивка або продукт із явним шаром трансляції — це інші схеми. Звичайний випадок — той, навколо якого варто планувати: застосунок, який може імпортувати ваш файл і працювати як звичайний користувач, з IP-інтерфейсом і нічим під ним.

Як це виглядає, коли все ж спробувати

З’єднання зазвичай встановлюється. Саме це робить збій заплутаним: клієнт повідомляє про підключення, журнал сервера показує партнера, а жоден застосунок не працює.

Трафік, адресований виданій телефону адресі, не надходить, бо сервер просуває кадри мостом на MAC-адресу, якої телефон ніколи не мав. Виявлення, що залежить від широкомовлення, залишається порожнім. Якщо LAN покладається на DHCP через міст, телефон так не отримає оренди, а вручну призначена адреса в підмережі з мостом усе одно не створює відсутній інтерфейс.

Деякі клієнти здаються раніше, під час імпорту профілю, коли бачать тип пристрою, який не можуть реалізувати. Обидві поведінки означають одне й те саме, і жодну не виправляє додавання маршрутів, зміна DNS чи розширення діапазону адрес тунелю.

Що має змінити бік сервера

Виправлення належить тому, хто експлуатує службу VPN, і зазвичай це доповнення, а не міграція. Запустіть другий примірник OpenVPN із маршрутизованим пристроєм, власною клієнтською підмережею і конфігурацією на боці сервера, яка призначає адреси й передає маршрути, потрібні телефонам. Наявний примірник із мостом продовжує обслуговувати пристрої, яким справді потрібен Ethernet.

Дві деталі роблять це працездатним на практиці. LAN потрібен зворотний маршрут для нової клієнтської підмережі, спрямований на хост VPN, інакше відповіді ніколи не повернуться. І міжмережевий екран на хості тунелю має пересилати між інтерфейсом тунелю і LAN, і це крок, який найчастіше пропускають, коли тест із самого хоста вдається.

Якщо оператор не може додати службу, альтернатива — пристрій, який може увійти в міст, тобто ноутбук або маршрутизатор, що діє від імені телефона. Це обхідний шлях із власними витратами на управління, а не конфігурація Android.

Вирішуйте з огляду на застосунок, а не на тунель

Запитайте, до чого телефону насправді треба дістатися, і потім відобразіть це. Файловий ресурс або сайт інтранету, доступний за іменем чи адресою, — це вимога IP, і маршрутизований тунель задовольняє її, щойно DNS розв’яже ім’я і маршрут існує. Інструмент виявлення, що обходить локальний домен широкомовлення, не є вимогою IP, і жодна кількість маршрутизації його не заповнить.

Ця таблиця — ще й запит, який треба надіслати. Назвіть застосунок, адресу або ім’я, яке він використовує, і чи залежить він від виявлення. Оператор може діяти за цим описом, чого ніхто не може зробити з телефоном, який не підключається.

Насамкінець, збережіть службу TAP для пристроїв, яким вона потрібна, замість того щоб змушувати кожного клієнта імітувати адаптер LAN. Дві служби з ясними цілями підтримувати легше, ніж одну, яка наполовину працює для всіх.