OpenVPN TUN против TAP: три условия, которые решают

Два туннеля могут передавать одну и ту же передачу файла и при этом полностью различаться тем, что они кладут в провод. Один перемещает IP-пакеты между двумя адресами; другой перемещает кадры Ethernet, и его можно включить в мост с сегментом. Именно это различие определяет, какие приложения работают, какие клиенты могут подключиться и сколько проектирования сети вы на себя берёте.

На практике это решают три условия. Пройдите их по порядку, потому что первое обычно заканчивает обсуждение.

Что на самом деле передаёт каждый интерфейс

Устройство TUN — это двухточечный интерфейс уровня 3: ядро передаёт ему IP-пакеты, а туннель несёт их к адресу партнёра. Устройство TAP — это интерфейс уровня 2, который передаёт кадры Ethernet, и именно это вообще делает возможным мост, как описывает документация ядра. Ни один из них не меняет способ шифрования полезной нагрузки, и ни один не является настройкой стойкости. Выбор касается того, чем должны обмениваться концы, а не того, насколько хорошо защищён трафик.

Одно следствие наступает сразу: оба конца должны быть согласованы. Клиент, настроенный на один тип устройства, не может подключиться к серверу, настроенному на другой, что бы ещё ни совпадало.

Условие первое: нужно ли чему-то второму уровню?

Мост оправдывает свою сложность, когда протоколу действительно нужен один и тот же домен широковещания: не-IP трафик, обнаружение, которое не может пройти через маршрутизатор, или приложение, которое настаивает на одном сегменте. Всё остальное — задача маршрутизации, и маршрутизация решает её куда меньшими средствами. Растягивание сегмента на большую территорию растягивает и его широковещание, поэтому защита от петель, планирование адресов и домены отказа становятся частью проекта. Это много, чтобы принять ради требования, которое удовлетворил бы один маршрут.

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

Условие второе: могут ли клиенты?

Поддержка неоднородна. Настольные клиенты обычно предоставляют оба типа устройств, тогда как мобильные и встраиваемые клиенты часто реализуют только маршрутизируемый режим, а профиль, импортированный без замечаний, всё равно может отказать при попытке создать интерфейс. Проверяйте конкретный клиент и версию, а не выводите возможности из названия платформы.

Ошибка о неподдерживаемом параметре — не приглашение удалять незнакомые строки до тех пор, пока импорт не пройдёт. Она означает, что профиль и клиент расходятся в том, что возможно, и исправление принадлежит оператору, выпустившему профиль. Удаление параметра, чтобы заглушить валидатор, может дать соединение, которое выглядит работающим, но тихо опускает свойство, ради которого он существовал.

Условие третье: это действительно вопрос интерфейса?

В проблемах интерфейса обвиняют два соседних выбора. Виртуальное устройство решает, что попадает в туннель, а UDP или TCP решает, как ведёт себя внешний транспорт, и ни один из них не лечит передачу, которая застревает. Когда большие передачи зависают, а малые проходят, внимания заслуживают размер пакета и MTU.

Клиент, который подключается, а затем не может достучаться до одного внутреннего узла, обычно смотрит на маршрутизацию, правило брандмауэра или отсутствующий обратный путь.

Для управляемого сервиса используйте ту схему интерфейсов, которую задаёт профиль оператора, потому что серверная сторона уже построена вокруг неё. Для частного развёртывания выбирайте исходя из реального требования приложения и запишите причину рядом с выбором.

Вопрос не в том, какой вариант сильнее. А в том, какой действительно нужен трафику.