OpenVPN TUN проти TAP: три умови, що вирішують

Два тунелі можуть передавати те саме передавання файлу і все ж повністю відрізнятися тим, що кладуть у дріт. Один переміщує IP-пакети між двома адресами; інший переміщує кадри Ethernet, і його можна включити в міст із сегментом. Саме ця різниця визначає, які застосунки працюють, які клієнти можуть підключитися і скільки проєктування мережі ви берете на себе.

На практиці це вирішують три умови. Пройдіть їх по порядку, бо перша зазвичай завершує обговорення.

Що насправді передає кожен інтерфейс

Пристрій TUN — це двокрапковий інтерфейс рівня 3: ядро передає йому IP-пакети, а тунель несе їх до адреси партнера. Пристрій TAP — це інтерфейс рівня 2, який передає кадри Ethernet, і саме це взагалі уможливлює міст, як описує документація ядра. Жоден із них не змінює спосіб шифрування корисного навантаження, і жоден не є налаштуванням стійкості. Вибір стосується того, чим мають обмінюватися кінці, а не того, наскільки добре захищений трафік.

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

Умова перша: чи чомусь потрібен другий рівень?

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

Перевірка конкретна: назвіть застосунок, який не працює на маршрутизованому тунелі, і поясніть чому. Якщо відповідь — йому потрібне широкомовлення, то другий рівень і є чесна відповідь. Якщо відповідь — хтось не зміг дістатися до одного сервера, то вимога — це маршрут або правило брандмауера.

Умова друга: чи можуть клієнти?

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

Помилка про непідтримуваний параметр — не запрошення видаляти незнайомі рядки, доки імпорт не пройде. Вона означає, що профіль і клієнт розходяться в тому, що можливо, і виправлення належить оператору, який видав профіль. Видалення параметра, щоб заспокоїти валідатор, може дати з'єднання, яке виглядає робочим, але тихо пропускає властивість, заради якої він існував.

Умова третя: це справді питання інтерфейсу?

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

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

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

Питання не в тому, який варіант сильніший. А в тому, який справді потрібен трафіку.