OpenVPN TUN naspram TAP: tri uslova koja odlučuju izbor

Dva tunela mogu prenositi isti prijenos datoteke i potpuno se razlikovati u onome što stavljaju na žicu. Jedan prenosi IP pakete između dvije adrese; drugi prenosi Ethernet okvire i može se premosniti u segment. Ta razlika odlučuje koje aplikacije rade, koji se klijenti mogu povezati i koliko projektovanja mreže preuzimate.

U praksi to rješavaju tri uslova. Prođite ih po redu, jer prvi obično završava raspravu.

Šta svaki interfejs zaista prenosi

TUN uređaj je tačka-na-tačku interfejs sloja 3: kernel mu predaje IP pakete, a tunel ih nosi do adrese partnera. TAP uređaj je interfejs sloja 2 koji prenosi Ethernet okvire, i upravo to uopšte omogućava premošćavanje, kako opisuje dokumentacija kernela. Nijedan ne mijenja kako se šifruje korisni teret i nijedan nije postavka snage. Izbor se odnosi na to šta krajnje tačke moraju razmijeniti, a ne na to koliko je saobraćaj dobro zaštićen.

Jedna posljedica slijedi odmah: obje strane moraju se složiti. Klijent konfigurisan za jednu vrstu uređaja ne može se pridružiti serveru konfigurisanom za drugu, šta god drugo odgovaralo.

Uslov prvi: treba li bilo šta sloj dva?

Premošćavanje zaslužuje svoju složenost kada protokol zaista treba isti broadcast domen: ne-IP saobraćaj, otkrivanje koje ne može preći ruter, ili aplikacija koja insistira na tome da bude u jednom segmentu. Sve ostalo je problem rutiranja, a rutiranje ga rješava s mnogo manje mehanizama. Proširenje segmenta na široko područje proširuje i njegove broadcast-e, pa prevencija petlji, planiranje adresa i domeni otkaza postaju dio dizajna. To je mnogo toga prihvatiti za zahtjev koji bi jedna ruta zadovoljila.

Test je konkretan: imenujte aplikaciju koja ne radi preko rutiranog tunela i recite zašto. Ako je odgovor da joj treba broadcast, sloj dva je pošten odgovor. Ako je odgovor da neko nije mogao doći do jednog servera, zahtjev je ruta ili pravilo firewall-a.

Uslov drugi: mogu li to klijenti?

Podrška nije ujednačena. Desktop klijenti obično nude obje vrste uređaja, dok mobilni i ugrađeni klijenti često implementiraju samo rutirani režim, a profil koji se uvozi bez prigovora ipak može pasti kad pokuša stvoriti interfejs. Provjerite konkretnog klijenta i verziju umjesto da skup funkcija zaključujete iz naziva platforme.

Greška o nepodržanoj opciji nije poziv da brišete nepoznate redove dok uvoz ne uspije. Ona znači da se profil i klijent ne slažu oko toga šta je moguće, a popravka pripada operatoru koji je izdao profil. Uklanjanje opcije da bi se validator ušutkao može dati vezu koja izgleda da radi, a tiho izostavlja svojstvo zbog kojeg je postojala.

Uslov treći: je li ovo zaista pitanje interfejsa?

Dva susjedna izbora dobijaju krivicu za probleme s interfejsom. Virtuelni uređaj odlučuje šta ulazi u tunel, dok UDP ili TCP odlučuje kako se vanjski transport ponaša, i nijedno ne liječi prijenose koji zapinju. Kad veliki prijenosi vise a mali uspijevaju, pažnju zaslužuju veličina paketa i MTU.

Klijent koji se poveže i zatim ne može doći do jednog internog hosta obično gleda rutiranje, pravilo firewall-a ili nedostajući povratni put.

Za upravljani servis koristite raspored interfejsa koji propisuje operatorov profil, jer je serverska strana već izgrađena oko njega. Za vlastito postavljanje birajte prema stvarnom zahtjevu aplikacije i zapišite razlog uz izbor.

Pitanje nije koja je opcija jača. Nego koja od njih saobraćaju zaista treba.