OpenVPN TUN против TAP: три услова која одлучују

Два тунела могу преносити исти пренос датотеке и ипак се потпуно разликовати у ономе што стављају на жицу. Један премешта IP пакете између две адресе; други премешта Ethernet оквире и може се премостити у сегмент. Та разлика одлучује које апликације раде, који клијенти могу да се повежу и колико пројектовања мреже преузимате.

У пракси то решавају три услова. Прођите их редом, јер први обично завршава расправу.

Шта сваки интерфејс заиста преноси

Уређај TUN је тачка-на-тачку интерфејс слоја 3: језгро му предаје IP пакете, а тунел их носи до адресе партнера. Уређај TAP је интерфејс слоја 2 који преноси Ethernet оквире, и управо то уопште омогућава премошћавање, како описује документација језгра. Ниједан не мења начин шифровања корисног терета и ниједан није подешавање јачине. Избор се тиче тога шта крајеви морају да размене, а не тога колико је саобраћај добро заштићен.

Једна последица следи одмах: оба краја морају да се сложе. Клијент конфигурисан за једну врсту уређаја не може да се придружи серверу конфигурисаном за другу, шта год друго да се поклопи.

Први услов: да ли је било чему потребан слој два?

Премошћавање заслужује своју сложеност када протоколу заиста треба исти домен емитовања: саобраћај који није IP, откривање које не може да прође кроз рутер или апликација која инсистира на једном сегменту. Све остало је проблем усмеравања, а усмеравање га решава са много мање механизама. Проширење сегмента на велико подручје проширује и његова емитовања, па спречавање петљи, планирање адреса и домени отказа постају део пројекта. То је много за прихватање за захтев који би задовољила једна рута.

Тест је конкретан: наведите апликацију која не успева на усмереном тунелу и кажите зашто. Ако је одговор да јој треба емитовање, слој два је искрен одговор. Ако је одговор да неко није могао да стигне до једног сервера, захтев је рута или правило заштитног зида.

Други услов: могу ли клијенти то?

Подршка није једнолика. Стони клијенти обично нуде обе врсте уређаја, док мобилни и уграђени клијенти често примењују само усмерени режим, а профил увезен без приговора ипак може да не успе када покуша да створи интерфејс. Проверите конкретног клијента и верзију уместо да закључујете функције из назива платформе.

Грешка о неподржаном параметру није позив да бришете непознате редове док увоз не успе. Значи да се профил и клијент не слажу око тога шта је могуће, а поправка припада оператеру који је издао профил. Уклањање параметра да би се утишао валидатор може да створи везу која изгледа да ради, а тихо изоставља својство због којег је постојала.

Трећи услов: је ли ово заиста питање интерфејса?

За проблеме са интерфејсом криве се две суседне опције. Виртуелни уређај одлучује шта улази у тунел, док UDP или TCP одлучује како се понаша спољни транспорт, и ниједан не лечи преносе који застану. Када велики преноси висе, а мали успевају, пажњу заслужују величина пакета и MTU.

Клијент који се повеже и затим не може да стигне до једног интерног домаћина обично гледа усмеравање, правило заштитног зида или пут повратка који недостаје.

За управљану услугу користите распоред интерфејса који прописује профил оператера, јер је серверска страна већ изграђена око њега. За приватно распоређивање изаберите према стварном захтеву апликације и запишите разлог поред избора.

Питање није која је опција јача. Питање је која саобраћају заиста треба.