TAP или TUN? OpenVPN клиенти за Android и мостови сървъри

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

TAP пренася Ethernet кадри. TUN пренася IP пакети. На приложение за VPN под Android се дава IP интерфейс и това прави една от двете подредби възможна, а другата — не, независимо какво казва конфигурацията.

Сравнението е кратко, но то решава дали можете да го оправите на телефона, или трябва да смените услугата.

Два вида тунели с различни товари

Интерфейсът TAP се държи като Ethernet адаптер. Той пренася кадри, което означава ARP, broadcast и всичко останало, което LAN пренася под IP. Именно това прави мостовото свързване възможно: тунелът разширява broadcast домейн и клиентите се държат все едно са включени в комутатор.

Интерфейсът TUN пренася IP пакети, адресирани до него. Няма канален слой за договаряне, няма ARP и няма broadcast. Маршрутизацията решава какво влиза в тунела, а конфигурацията от страна на сървъра използва подмрежа, а не мост.

Двата края трябва да се съгласят кой от тези варианти правят. Смяната на dev tap с dev tun от едната страна не преобразува услугата; получава се клиент, който очаква маршрутизиран тунел, и сървър, който още подава кадри, и ръкостискането може да успее, докато през тунела не минава нищо използваемо.

Какво всъщност Android дава на приложението

API VpnService на платформата дава на приложението виртуален интерфейс за IP пакети, настроен с адреси, маршрути и MTU. В това API няма Ethernet адаптер и приложението не може да си създаде такъв.

Затова OpenVPN Connect документира поддръжка на маршрутизирани TUN връзки на Android, а не на TAP мостове. Често задавани въпроси за Android е изявлението от страна на клиента за тази граница и то съвпада с API на платформата.

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

Как изглежда, когато все пак опитате

Връзката обикновено се установява. Именно това прави провала объркващ: клиентът съобщава за връзка, сървърният журнал показва партньор, а нито едно приложение не работи.

Трафикът, адресиран до зададения адрес на телефона, не пристига, защото сървърът мостово препраща кадри към MAC адрес, който телефонът никога не е имал. Откриването, зависещо от broadcast, остава празно. Ако LAN разчита на DHCP през моста, телефонът няма да получи наем по този начин, а ръчно зададеният адрес в мостовата подмрежа все още не създава липсващия интерфейс.

Някои клиенти се провалят по-рано, при внасянето на профила, когато видят тип устройство, който не могат да реализират. Всяко от двете поведения означава едно и също и нито едно не се оправя с добавяне на маршрути, смяна на DNS или разширяване на адресния диапазон на тунела.

Какво трябва да промени сървърната страна

Поправката е на този, който управлява VPN услугата, и обикновено е допълнение, а не миграция. Стартирайте втори екземпляр OpenVPN с маршрутизирано устройство, собствена клиентска подмрежа и конфигурация от страна на сървъра, която задава адреси и изпраща маршрутите, от които телефоните се нуждаят. Съществуващият мостов екземпляр продължава да обслужва устройствата, които наистина се нуждаят от Ethernet.

Две подробности правят това работещо на практика. LAN се нуждае от обратен маршрут за новата клиентска подмрежа, сочещ към хоста на VPN, иначе отговорите никога няма да се върнат. И защитната стена на хоста на тунела трябва да препраща между интерфейса на тунела и LAN — това е стъпката, която най-често се пропуска, когато тест от самия хост успее.

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

Решавайте от приложението, не от тунела

Попитайте до какво всъщност трябва да стигне телефонът, после го начертайте. Споделена папка или вътрешен сайт, достъпни по име или адрес, са IP изискване и маршрутизиран тунел ги задоволява, след като DNS разреши името и маршрутът съществува. Инструмент за откриване, който обхожда локалния broadcast домейн, не е IP изискване и никакво количество маршрутизация няма да го запълни.

Тази таблица е и заявката, която да изпратите. Назовете приложението, адреса или името, което използва, и дали зависи от откриване. Операторът може да действа по такова описание, докато по телефон, който не се свързва, не може да действа никой.

Накрая, запазете TAP услугата за устройствата, които се нуждаят от нея, вместо да карате всеки клиент да имитира LAN адаптер. Две услуги с ясни цели се поддържат по-лесно от една, която работи наполовина за всички.