OpenVPN TUN срещу TAP: три условия, които решават избора

Два тунела могат да пренасят едно и също прехвърляне на файл и да се различават напълно по това, което слагат на линията. Единият движи IP пакети между два адреса; другият движи Ethernet кадри и може да бъде мостнат в сегмент. Тази разлика решава кои приложения работят, кои клиенти могат да се свържат и колко проектиране на мрежа поемате.

На практика това се решава от три условия. Минавате през тях по ред, защото първото обикновено приключва спора.

Какво всъщност носи всеки интерфейс

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

Едно последствие следва веднага: двете страни трябва да са съгласни. Клиент, конфигуриран за един тип устройство, не може да се присъедини към сървър, конфигуриран за другия, каквото и друго да съвпада.

Условие първо: има ли нещо, което се нуждае от второ ниво?

Мостът заслужава сложността си, когато протокол наистина се нуждае от един и същ broadcast домейн: не-IP трафик, откриване, което не може да премине рутер, или приложение, което настоява да бъде в един сегмент. Всичко останало е задача за маршрутизиране, а маршрутизирането я решава с много по-малко механизми. Разширяването на сегмент през широка област разширява и неговите broadcast-и, така че предотвратяването на цикли, планирането на адреси и домейните на отказ стават част от проекта. Това е много, за да приемете заради изискване, което един маршрут би покрил.

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

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

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

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

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

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

Клиент, който се свързва и после не достига един вътрешен хост, обикновено гледа маршрутизиране, правило на защитна стена или липсващ обратен път.

За управлявана услуга използвайте подредбата на интерфейсите, която профилът на оператора задава, защото сървърната страна вече е изградена около нея. За собствено внедряване избирайте според реалното изискване на приложението и запишете причината до избора.

Въпросът не е коя опция е по-силна. А коя от тях трафикът наистина има нужда.