Dotaz: tun, alebo tap

[jany2]

Zacinam sa zoznamovat s openvpn a chcem si nainstalovat ovpn (linux i686). Zatial by som to chcel testovat na desktope a ak to bude fungovat korektne, tak to chcem nasadit na server x86_64.
Su 2 moznosti pre vyber rozhrania a to TUN (routing) a TAP (bridging). Ktoru je lepsie pouzit pre mna:
Server bude postaveny na linuxe (ako som spominal) a na server sa budu pripajat klienti (10-15) nechcem aby komunikovali medzi sebou, len cisto zo serverom a jednou aplikaciou na jednom porte (nic viac).
Co je lepsie TUN, alebo TAP. Nieco som pozeral tu z toho mi vychadza lepsie TAP, ale neviem az tak dobre po anglicky, ale z toho co som pochopil, tak asi TAP.

Odpovědi

[NN]

No, ale prece zadny 'bridging' delat nebudes. Takze bych navrhoval preci jen TUN, ktery pro tebe bude i konfiguracne snazsi na pochopeni.

[Andrej]

Co je lepsie TUN, alebo TAP.

V podstatě ani jedno. Obojí je bída s nouzí ve srovnání se IPSec. Doporučuji vybodnout se na OpenVPN a podobné hračky a nastavit si IPSec. K tomu účelu používám strongswan. (Některé distribuce mají libreswan, openswan a kdovícoještě, ale cokoliv z toho by mělo hravě strčit OpenVPN do kapsy.)

[mhepp]

Můžeš prosím rozvést více své tvrzení?

Ptám se ze zájmu o věc, nechci se hádat. Díky...

[Andrej]

Jakkoliv je OpenVPN uznávané a dokonce už i oficiálně standardizované řešení (co se protokolu týká), nikdy se nezbaví té ošklivé konfigurace s démonem v userspace. Takže každý paket, kterým se OpenVPN zabývá, musí přes ono virtuální rozhraní z kernelu do userspace, tam se šifruje a dešifruje (a otázka je, jak efektivně, protože program v userspace prostě nemá žádnou možnost rozhodovat, na kterém procesoru zrovna běží a jestli bude jeho manipulace s pakety výhodná z hlediska cache) a nakonec následuje další kopie z userspace zpátky do kernelu.

Naproti tomu IPSec je prostě součástí síťového stacku přímo v kernelu. Tím pádem zdaleka nemusí tolikrát kopírovat data sem a tam a může pracovat mnohem efektivněji z hlediska cache. (Například může všechny vrstvy síťových protokolů, včetně IPSec, zpracovat tentýž procesor, který přijal původní interrupt od síťovky, čímž se zásadně ušetří čas i energie, nedochází k několika context-switchům kvůli (skoro) každému paketu a nepřepisují se úplně zbytečně cache.)

OpenVPN je jakási složitá tlustá vrstva, která si napřed nad L3 sítí naváže klasickou L4 komunikaci a uvnitř toho komunikačního kanálu pak provozuje v podstatě něco jako virtuální L2 bridge (no, s trochou nadsázky, podle toho, jakou konfiguraci člověk zvolí). Až si jeden říká, what can possibly go wrong. V kontrastu s tímhle se IPSec prostě od začátku do konce tváří jako úplně normální L3 vrstva, která „jenom“ mění způsob interpretace některých paketů z/do některých rozsahů adres. Nehraje si tedy na virtuální rozhraní. Dovede selektivně a transparentně (bez nutnosti vědět o nějakém speciálním zařízení a o jeho adresách) zabezpečit například komunikaci s různými „spřátelenými“ sítěmi. Není potřeba explicitně zakazovat nešifrovanou komunikaci pro případ, kdy náhodou OpenVPN neběží nebo virtuální rozhraní zkrátka z nějakého důvodu není k dispozici, a vůbec tak celkově ubude spousta podivných krajních případů.

S kompatibilitou napříč různými systémy je na tom IPSec zhruba stejně jako OpenVPN.

Myslím si, že pokud někdo navrhuje nějaké VPN řešení od píky, neměl byc se nechat zmást tím VPN v názvu OpenVPN a prostě by tam měl dát místo toho IPSec, pokud nemá nějaký zásadní technický důvod k použití OpenVPN. Takový důvod si ale u nově navrhované sítě, která nemusí zajišťovat kompatibilitu s nějakou existující konfigurací klientů, neumím představit.

[Migi]

Ne, že bych nesouhlasil, pouze podklad do diskuse. :)

https://openvpn.net/archive/openvpn-users/2004-11/msg00548.html

[R]

Plati jednoduche pravidlo: pokial nemas nejaky specialny dovod, tak pouzi TUN.

[Migi]

Kdyz pouzijes tap, muzes vsechna spojeni pevne svazat s jednim interfacem, s kterym budes moci posleze pracovat pri vytvareni pravidel ve firewallu. S tun budes neustale vytvaret nove docasne interfacy, coz ti bude komplikovat tvorbu bezpecnostnich pravidel.

Nevyhoda tap je zase treba to, ze android ho minimalne s openvpn neumi.

[jany2]

Tak teraz babo rad :)

[jany2]

Kedze vo VPN nie som az tak doma, stale neviem co pouzit tun/tap. Pre lepsie pochopenie dam sem obrazok o co mi konkretne ide.
Na realnej IP adrese 192.168.1.2 je server. Na nom chcem postavit OVPN napr. so sietou 10.0.0.0. Takze po nainstalovani ovpn a zakladnej konfiguracii confu sa vytvori virtualna sietovka (tun/tap) a bude mat IP 10.0.0.1 (predpokladam, ze vsetky certifikaty a kluce su uz na spravnom mieste (ako na servery, tak u klientov)).

Predpokladajme, ze klient/i sa pripojili uspesne a ziskali IP adresy 10.0.0.x. Ako je potrebne nakonfigurovat firewall, aby nemohli nic, len aby mali pristup na 10.0.0.1 a port 40000 (nic viac, nic menej). Teoreticky by mohlo stacit pravidlo, ktore vsetko zahadzuje a povoluje len port 40000.

[NN]

Pokracovani -> ZDE

[Max]

TAP - běží na L2 (je to jako další síťovka v pc), trošku náročnější na datový tok, protuneluje všechno bez rozdílu

TUN - běží na L3 vrstvě, méně náročnější na datový tok, nejde bridgovat, může se tunelovat jen něco. Má podporu v Androidu a iOS.

Sesumírováno je to dobře třeba zde : Bridging vs. routing

Pro propojení lokalit/poboček se nepoužívá OpenVPN, ale IPSEC tunely.
Pro připojení klientů do hlavní lokality se používá buď OpenVPN, nebo L2TP over IPSEC.
Konfigurace L2TP a IPSECu je o něco náročnější, jak konfigurace OpenVPN, ale není to problém.
Dále ještě relativně nedávno nebyla dostupná implementace více L2TP klientů, co jsou za natem (jednou veřejnou IP). Myslím, že toto už do Strongswanu doputovalo, ale nejsem si tím jist. Tato skutečnost někoho trápit nemusí, někoho ano.

My jsme třeba v práci přešli na OpenVPN v režimu TUN + máme funkční i L2TP (nativní podpora je v iOS, Android i Windows).
Zdar Max