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

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

Во практиката тоа го решаваат три услови. Поминете ги по ред, бидејќи првиот обично ја завршува дискусијата.

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

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

Една последица следи веднаш: двата краја мора да се согласат. Клиент конфигуриран за еден тип уред не може да се приклучи на сервер конфигуриран за другиот, што и друго да се совпаѓа.

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

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

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

Втор услов: дали клиентите можат тоа?

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

Грешка за неподдржана опција не е покана да бришете непознати редови додека увозот не успее. Таа значи дека профилот и клиентот не се согласуваат за тоа што е можно, а поправката му припаѓа на операторот што го издал профилот. Отстранувањето опција за да се смири валидаторот може да создаде врска што изгледа дека работи, а тивко ја испушта особината за која постоела.

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

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

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

За управувана услуга користете го распоредот на интерфејси што го пропишува профилот на операторот, бидејќи серверската страна веќе е изградена околу него. За приватно распоредување изберете според вистинското барање на апликацијата и запишете ја причината до изборот.

Прашањето не е која опција е посилна. Прашањето е која на сообраќајот навистина му треба.