OpenVPN TUN vs. TAP: tři podmínky, které rozhodují

Dva tunely mohou přenášet stejný přenos souboru a přitom se zcela lišit v tom, co kladou na drát. Jeden přenáší IP pakety mezi dvěma adresami; druhý přenáší ethernetové rámce a lze ho přemostí do segmentu. Tento rozdíl rozhoduje, které aplikace fungují, kteří klienti se mohou připojit a kolik návrhu sítě na sebe berete.

V praxi to rozhodují tři podmínky. Projděte je popořadě, protože první obvykle diskusi ukončí.

Co každé rozhraní skutečně nese

Zařízení TUN je rozhraní typu bod-bod na vrstvě 3: jádro mu předává IP pakety a tunel je nese k adrese protějšku. Zařízení TAP je rozhraní vrstvy 2, které nese ethernetové rámce, a právě to mostění vůbec umožňuje, jak popisuje dokumentace jádra. Ani jedno nemění, jak se šifruje užitečné zatížení, a ani jedno není nastavení síly. Volba se týká toho, co si koncové body musí vyměnit, ne toho, jak dobře je provoz chráněn.

Jeden důsledek plyne okamžitě: obě strany se musí shodnout. Klient nakonfigurovaný pro jeden typ zařízení se nemůže připojit k serveru nakonfigurovanému pro druhý, ať se shoduje cokoli dalšího.

Podmínka první: potřebuje něco vrstvu dvě?

Mostění si svou složitost zaslouží, když protokol skutečně potřebuje stejnou broadcastovou doménu: ne-IP provoz, objevování, které nepřejde router, nebo aplikace, která trvá na tom být v jednom segmentu. Všechno ostatní je problém směrování a směrování ho řeší s mnohem méně stroji. Roztažení segmentu přes širokou oblast roztahuje i jeho broadcasty, takže prevence smyček, plánování adres a domény selhání se stanou součástí návrhu. To je hodně, co přijmout kvůli požadavku, který by splnila jediná trasa.

Test je konkrétní: pojmenujte aplikaci, která přes směrovaný tunel selhává, a řekněte proč. Pokud je odpověď, že potřebuje broadcast, je vrstva dvě poctivá odpověď. Pokud je odpověď, že se někdo nedostal na jeden server, je požadavkem trasa nebo pravidlo firewallu.

Podmínka druhá: zvládnou to klienti?

Podpora není jednotná. Desktopoví klienti obvykle nabízejí oba typy zařízení, zatímco mobilní a vestavění klienti často implementují jen směrovaný režim, a profil, který se importuje bez stížnosti, přesto může selhat, když se pokusí rozhraní vytvořit. Kontrolujte konkrétního klienta a verzi, místo abyste funkce odvozovali z názvu platformy.

Chyba o nepodporované volbě není pozvánkou mazat neznámé řádky, dokud import neprojde. Znamená, že profil a klient se neshodnou v tom, co je možné, a oprava patří operátorovi, který profil vydal. Odstranění volby, aby se umlčel validátor, může vytvořit spojení, které vypadá, že funguje, a přitom tiše vynechá vlastnost, kvůli které existovalo.

Podmínka třetí: je to opravdu otázka rozhraní?

Dvě sousední volby dostávají vinu za problémy s rozhraním. Virtuální zařízení rozhoduje, co vstoupí do tunelu, zatímco UDP nebo TCP rozhoduje, jak se chová vnější transport, a ani jedno neléčí přenosy, které se zaseknou. Když velké přenosy visí a malé procházejí, pozornost si zaslouží velikost paketu a MTU.

Klient, který se připojí a pak nedosáhne na jeden interní host, obvykle hledá směrování, pravidlo firewallu nebo chybějící zpáteční cestu.

U spravované služby použijte uspořádání rozhraní, které předepisuje profil operátora, protože serverová strana je na něm už postavená. U vlastního nasazení vybírejte podle skutečného požadavku aplikace a napište důvod vedle volby.

Otázka není, která volba je silnější. Ale kterou provoz skutečně potřebuje.