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. Две службы с ясными целями поддерживать легче, чем одну, которая наполовину работает для всех.