OpenVPN TUN enfront de TAP: tres condicions que decideixen l'elecció

Dos túnels poden transportar la mateixa transferència de fitxers i diferir completament en el que posen al cable. Un mou paquets IP entre dues adreces; l'altre mou trames Ethernet i es pot pontar dins d'un segment. Aquesta diferència decideix quines aplicacions funcionen, quins clients es poden connectar i quant disseny de xarxa accepteu.

A la pràctica ho decideixen tres condicions. Seguiu-les en ordre, perquè la primera normalment tanca la discussió.

Què transporta realment cada interfície

Un dispositiu TUN és una interfície punt a punt de capa 3: el nucli li lliura paquets IP i el túnel els porta a una adreça parella. Un dispositiu TAP és una interfície de capa 2 que transporta trames Ethernet, i això és el que fa possible el pontatge, tal com descriu la documentació del nucli. Cap dels dos canvia com s'encripta la càrrega útil, i cap és un paràmetre de força. L'elecció tracta del que els extrems han d'intercanviar, no de com de bé es protegeix el trànsit.

Una conseqüència se segueix immediatament: els dos extrems han de coincidir. Un client configurat per a un tipus de dispositiu no es pot unir a un servidor configurat per a l'altre, passi el que passi amb la resta.

Primera condició: hi ha res que necessiti capa dos?

El pontatge guanya la seva complexitat quan un protocol necessita de debò el mateix domini de difusió: trànsit que no és IP, descobriment que no pot travessar un encaminador, o una aplicació que insisteix a ser en un sol segment. Tota la resta és un problema d'encaminament, i l'encaminament el resol amb molta menys maquinària. Estendre un segment per una àrea àmplia també n'estén les difusions, així que la prevenció de bucles, la planificació d'adreces i els dominis de fallada passen a formar part del disseny. És molt d'acceptar per a un requisit que una sola ruta hauria cobert.

La prova és concreta: anomeneu l'aplicació que falla en un túnel encaminat i digueu per què. Si la resposta és que necessita difusió, la capa dos és la resposta honesta. Si la resposta és que algú no podia arribar a un servidor, el requisit és una ruta o una regla de tallafoc.

Segona condició: poden els clients fer-ho?

El suport no és uniforme. Els clients d'escriptori solen exposar tots dos tipus de dispositiu, mentre que els mòbils i els incrustats sovint només implementen el mode encaminat, i un perfil que s'importa sense protestes encara pot fallar quan intenta crear la interfície. Comproveu el client i la versió concrets en lloc d'inferir les funcions del nom de la plataforma.

Un error d'opció no suportada no és una invitació a esborrar línies desconegudes fins que la importació funcioni. Vol dir que el perfil i el client no coincideixen sobre què és possible, i la reparació pertoca a l'operador que va emetre el perfil. Treure una opció per fer callar un validador pot produir una connexió que sembla funcionar mentre omet en silenci la propietat per a la qual existia.

Tercera condició: és realment una qüestió d'interfície?

Dues decisions veïnes reben la culpa dels problemes d'interfície. El dispositiu virtual decideix què entra al túnel, mentre que UDP o TCP decideix com es comporta el transport exterior, i cap dels dos cura les transferències que s'encallen. Quan les transferències grans pengen mentre les petites triomfen, la mida del paquet i l'MTU mereixen l'atenció.

Un client que es connecta i després no arriba a un host intern normalment mira l'encaminament, una regla de tallafoc o un camí de tornada que falta.

Per a un servei gestionat, useu la disposició d'interfícies que especifica el perfil de l'operador, perquè el costat del servidor ja està construït al seu voltant. Per a un desplegament propi, trieu a partir del requisit real de l'aplicació i escriviu el motiu al costat de l'elecció.

La pregunta no és quina opció és més forta. Sinó quina necessita realment el trànsit.