OpenVPN TUN față de TAP: trei condiții care decid

Două tuneluri pot transporta același transfer de fișier și totuși pot fi complet diferite în ce pun pe fir. Unul mută pachete IP între două adrese; celălalt mută cadre Ethernet și poate fi puntea într-un segment. Această diferență decide ce aplicații funcționează, ce clienți se pot conecta și cât de multă proiectare de rețea vă asumați.

În practică, trei condiții rezolvă acest lucru. Parcurgeți-le în ordine, pentru că prima încheie de obicei discuția.

Ce transportă de fapt fiecare interfață

Un dispozitiv TUN este o interfață punct-la-punct de nivel 3: kernelul îi dă pachete IP, iar tunelul le duce la o adresă egală. Un dispozitiv TAP este o interfață de nivel 2 care transportă cadre Ethernet, și exact aceasta face posibilă puntea, după cum descrie documentația nucleului. Niciunul nu schimbă modul în care este criptată încărcătura utilă și niciunul nu este o setare de putere. Alegerea privește ce trebuie să schimbe capetele, nu cât de bine este protejat traficul.

O consecință urmează imediat: ambele capete trebuie să fie de acord. Un client configurat pentru un tip de dispozitiv nu se poate alătura unui server configurat pentru celălalt, orice altceva ar coincide.

Prima condiție: are ceva nevoie de nivelul doi?

Puntea își merită complexitatea atunci când un protocol are cu adevărat nevoie de același domeniu de difuzare: trafic non-IP, descoperire care nu poate traversa un router sau o aplicație care insistă să fie într-un singur segment. Orice altceva este o problemă de rutare, iar rutarea o rezolvă cu mult mai puțină mașinărie. Extinderea unui segment pe o zonă întinsă extinde și difuzările lui, așa că prevenirea buclelor, planificarea adreselor și domeniile de eșec devin toate parte din proiectare. Este mult de acceptat pentru o cerință pe care o singură rută ar fi satisfăcut-o.

Testul este concret: numiți aplicația care eșuează pe un tunel rutat și spuneți de ce. Dacă răspunsul este că are nevoie de difuzare, nivelul doi este răspunsul cinstit. Dacă răspunsul este că cineva nu a putut ajunge la un server, cerința este o rută sau o regulă de firewall.

A doua condiție: pot clienții?

Suportul nu este uniform. Clienții de desktop expun de obicei ambele tipuri de dispozitiv, în timp ce clienții mobili și încorporați implementează adesea doar modul rutat, iar un profil importat fără reclamații poate totuși eșua când încearcă să creeze interfața. Verificați clientul și versiunea concrete în loc să deduceți funcțiile din numele platformei.

O eroare de opțiune nesuportată nu este o invitație de a șterge linii necunoscute până când importul reușește. Înseamnă că profilul și clientul nu sunt de acord cu privire la ce este posibil, iar reparația aparține operatorului care a emis profilul. Eliminarea unei opțiuni pentru a liniști un validator poate produce o conexiune care pare să funcționeze, dar omite în tăcere proprietatea pentru care exista.

A treia condiție: este într-adevăr o chestiune de interfață?

Două alegeri apropiate sunt învinovățite pentru problemele de interfață. Dispozitivul virtual decide ce intră în tunel, în timp ce UDP sau TCP decide cum se comportă transportul exterior, și niciunul nu vindecă transferurile care se blochează. Când transferurile mari se blochează, iar cele mici reușesc, dimensiunea pachetului și MTU merită atenția.

Un client care se conectează și apoi nu poate ajunge la un host intern se uită de obicei la rutare, la o regulă de firewall sau la o cale de întoarcere lipsă.

Pentru un serviciu gestionat, folosiți aranjamentul de interfețe specificat de profilul operatorului, pentru că partea de server este deja construită în jurul lui. Pentru o implementare privată, alegeți din cerința reală a aplicației și scrieți motivul lângă alegere.

Întrebarea nu este care opțiune este mai puternică. Este care este cea de care traficul are cu adevărat nevoie.