OpenVPN TUN і TAP: тры ўмовы, што вырашаюць выбар

Два тунелі могуць перадаваць адзін і той жа файл і цалкам адрознівацца ў тым, што яны кладуць у лінію. Адзін перамяшчае пакеты IP паміж двума адрасамі; другі перамяшчае кадры Ethernet і можа быць змаставаны ў сегмент. Гэта розніца вызначае, якія праграмы працуюць, якія кліенты могуць падключыцца і колькі праектавання сеткі вы на сябе бярэце.

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

Што насамрэч пераносіць кожны інтэрфейс

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

Адзін вынік вынікае адразу: абодва бакі мусяць дамовіцца. Кліент, наладжаны на адзін тып прылады, не можа далучыцца да сервера, наладжанага на іншы, што б іншае ні супадала.

Умова першая: ці нешта мае патрэбу ў другім узроўні?

Маставанне апраўдвае сваю складанасць, калі пратакол сапраўды мае патрэбу ў адным і тым жа шырокавяшчальным дамене: не-IP трафік, выяўленне, якое не можа перайсці маршрутызатар, або праграма, якая настойвае на тым, каб быць у адным сегменце. Усё астатняе — задача маршрутызацыі, і маршрутызацыя вырашае яе значна меншымі сродкамі. Пашырэнне сегмента на вялікую тэрыторыю пашырае і яго шырокавяшчанне, таму прадухіленне петляў, планаванне адрасоў і дамены адмоваў становяцца часткай праекта. Гэта шмат, каб пагадзіцца на патрэбу, якую задаволіў бы адзін маршрут.

Праверка канкрэтная: назавіце праграму, якая не працуе праз маршрутызаваны тунель, і скажыце чаму. Калі адказ — ёй патрэбна шырокавяшчанне, то другі ўзровень і ёсць сумленны адказ. Калі адказ — нехта не мог дасягнуць аднаго сервера, то патрэба — гэта маршрут або правіла фаервала.

Умова другая: ці могуць гэта кліенты?

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

Памылка пра неподтрымліваемую опцыю — не запрашэнне выдаляць незнаёмыя радкі, пакуль імпарт не пройдзе. Яна азначае, што профіль і кліент не згодныя ў тым, што магчыма, і выпраўленне — справа аператара, які выдаў профіль. Выдаленне опцыі, каб заглушыць валидатар, можа даць злучэнне, якое выглядае працоўным, але ціха апускае ўласцівасць, для якой яно існавала.

Умова трэцяя: ці гэта сапраўды пытанне інтэрфейса?

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

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

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

Пытанне не ў тым, якая опцыя мацнейшая. Яно ў тым, якая з іх сапраўды патрэбна трафіку.