OpenVPN TUN kontra TAP: trzy warunki, które decydują

Dwa tunele mogą przenosić ten sam transfer pliku, a mimo to całkowicie różnić się tym, co trafia do przewodu. Jeden przemieszcza pakiety IP między dwoma adresami; drugi przemieszcza ramki Ethernet i można go zmostkować do segmentu. Ta różnica decyduje o tym, które aplikacje działają, które klienty mogą się połączyć i ile projektowania sieci bierzesz na siebie.

W praktyce rozstrzygają to trzy warunki. Przejdź je po kolei, bo pierwszy zwykle kończy dyskusję.

Co naprawdę przenosi każdy interfejs

Urządzenie TUN to interfejs punkt-punkt warstwy 3: jądro przekazuje mu pakiety IP, a tunel przenosi je do adresu partnera. Urządzenie TAP to interfejs warstwy 2, który przenosi ramki Ethernet, i właśnie to w ogóle umożliwia mostkowanie, jak opisuje dokumentacja jądra. Żadne z nich nie zmienia sposobu szyfrowania ładunku i żadne nie jest ustawieniem siły. Wybór dotyczy tego, co muszą wymienić końce, a nie tego, jak dobrze chroniony jest ruch.

Jeden skutek następuje natychmiast: oba końce muszą się zgodzić. Klient skonfigurowany dla jednego typu urządzenia nie może dołączyć do serwera skonfigurowanego dla drugiego, cokolwiek innego by się zgadzało.

Warunek pierwszy: czy coś potrzebuje warstwy drugiej?

Mostkowanie zasługuje na swoją złożoność, gdy protokół naprawdę potrzebuje tej samej domeny rozgłaszania: ruchu innego niż IP, wykrywania, które nie przejdzie przez router, albo aplikacji, która upiera się przy jednym segmencie. Wszystko inne jest problemem trasowania, a trasowanie rozwiązuje go znacznie mniejszą maszynerią. Rozciągnięcie segmentu na duży obszar rozciąga także jego rozgłoszenia, więc zapobieganie pętlom, planowanie adresów i domeny awarii stają się częścią projektu. To dużo do przyjęcia za wymaganie, które spełniłaby jedna trasa.

Test jest konkretny: wskaż aplikację, która zawodzi na trasowanym tunelu, i powiedz dlaczego. Jeśli odpowiedź brzmi, że potrzebuje rozgłaszania, warstwa druga jest uczciwą odpowiedzią. Jeśli odpowiedź brzmi, że ktoś nie dotarł do jednego serwera, wymaganiem jest trasa albo reguła zapory.

Warunek drugi: czy klienci to potrafią?

Wsparcie nie jest jednolite. Klienty desktopowe zwykle udostępniają oba typy urządzeń, natomiast klienty mobilne i wbudowane często implementują tylko tryb trasowany, a profil zaimportowany bez skarg wciąż może zawieść, gdy próbuje utworzyć interfejs. Sprawdź konkretnego klienta i wersję, zamiast wnioskować o funkcjach z nazwy platformy.

Błąd nieobsługiwanej opcji nie jest zaproszeniem do usuwania nieznanych linii, dopóki import się nie powiedzie. Oznacza, że profil i klient nie zgadzają się co do tego, co jest możliwe, a naprawa należy do operatora, który wydał profil. Usunięcie opcji, by uciszyć walidator, może dać połączenie, które wygląda na działające, a po cichu pomija właściwość, dla której istniało.

Warunek trzeci: czy to naprawdę pytanie o interfejs?

O problemy z interfejsem obwinia się dwa sąsiednie wybory. Urządzenie wirtualne decyduje, co wchodzi do tunelu, a UDP lub TCP decyduje, jak zachowuje się transport zewnętrzny, i żadne z nich nie leczy transferów, które się zatrzymują. Gdy duże transfery wiszą, a małe się udają, uwagi wymagają raczej rozmiar pakietu i MTU.

Klient, który się łączy, a potem nie może dotrzeć do jednego hosta wewnętrznego, zwykle patrzy na trasowanie, regułę zapory albo brakującą trasę powrotną.

W usłudze zarządzanej użyj układu interfejsów podanego w profilu operatora, bo strona serwera jest już wokół niego zbudowana. We wdrożeniu prywatnym wybierz na podstawie rzeczywistego wymagania aplikacji i zapisz powód obok wyboru.

Pytanie nie brzmi, która opcja jest silniejsza. Brzmi, której ruch naprawdę potrzebuje.