Tunel kupuje topologię, a nie szyfrowanie czy opóźnienie

Założenie jest takie, że tunel to prywatny, szybki przewód: budujesz go, a ruch w środku jest szyfrowany, ścieżka jest krótsza, a łącze zachowuje się jak kabel między dwiema lokalizacjami. Każda część tego założenia to odrębna właściwość, a tunel dostarcza tylko to pierwsze, o co go poproszono, czyli logiczną ścieżkę. Wszystko inne trzeba wybrać i skonfigurować celowo. Mieszanie właściwości sprawia, że projekt kończy się zaszyfrowanym łączem, którego nikt nie potrafi zdiagnozować, i obietnicą opóźnienia, której nikt nie potrafi dotrzymać.

Mit: jeden tunel, trzy gwarancje

Tunel niezawodnie robi jedną rzecz. Sprawia, że dwa punkty końcowe, które nie są bezpośrednio połączone, zachowują się jak sąsiadujące w jakimś celu, podczas gdy sieć pośrodku przenosi pakiety zewnętrzne. To zmiana topologii i sama w sobie jest naprawdę przydatna.

Szyfrowanie, przenoszenie protokołów i izolacja przekazywania to osobne decyzje nakładane na to. Tunel GRE nie ma żadnej z tych trzech w sensie kryptograficznym, a tunel IP-in-IP jest poprawnym projektem całkowicie bez poufności. Żadne z nich nie jest błędem; to tunele robiące dokładnie to, co robią tunele. Etykieta na schemacie nie mówi, które właściwości są obecne.

Gdy rozdzielisz właściwości, pytania stają się odpowiadalne: czy ten tunel przenosi sąsiedztwo routingu, czy przenosi ramki, czy ukrywa adresy wewnętrzne, czy obiecuje coś w sprawie opóźnienia? To cztery różne odpowiedzi i cztery różne konsekwencje konfiguracji.

Co tunel naprawdę dodaje do mapy

Punkty końcowe dostają ścieżkę, której wcześniej nie miały. To, czy ta ścieżka zachowuje się jak routowany skok, czy jak segment Ethernet, zależy wyłącznie od enkapsulacji, a różnica zmienia to, co obie lokalizacje mogą z nią zrobić. Routowany tunel daje następny skok i prefiks; rozszerzenie Ethernet daje zachowanie rozgłoszeniowe i znacznie większą domenę awarii.

Tunel IP nie czyni zdalnej lokalizacji automatycznie częścią tej samej podsieci i nie uruchamia przez nią protokołu routingu, chyba że implementacja obsługuje to sąsiedztwo. Multicast to kolejne osobne pytanie z własną odpowiedzią.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Te polecenia odpowiadają na różne części pytania. Pierwsze mówi, jaki typ interfejsu istnieje, drugie mówi, którą ścieżkę wybrałoby jądro, a dwa ostatnie pokazują rzeczywiste zachowanie warstwy niższej, a nie obietnicę etykiety.

Transport to odrębna decyzja od osiągalności

Tunel może przenosić protokół, którego warstwa niższa nie przekazuje. IPv6 przez ścieżkę IPv4 to klasyczny przypadek i działa, ponieważ punkty końcowe rozumieją obie rodziny, a routery między nimi muszą tylko dostarczyć pakiety zewnętrzne. Warstwa niższa potrzebuje działającej ścieżki do punktu końcowego tunelu i niczego więcej.

Punkty końcowe potrzebują jednak pełnego wsparcia: przekazywania, adresów i aplikacji, która faktycznie używa wewnętrznej rodziny. Przydzielenie tunelowi prefiksu IPv6 nie czyni usługi działającej tylko z IPv4 osiągalną przez IPv6 i nie czyni warstwy niższej dual-stack.

Przenoszenie ramek to większe zobowiązanie niż przenoszenie protokołów. Rozszerzenie domeny rozgłoszeniowej przez tunel przenosi ze sobą zachowanie spanning tree, ARP i propagację awarii, co jest decyzją projektową, a nie przełącznikiem funkcji.

Izolacja nie jest poufnością

VPN dostawcy trzymają trasy i ruch klientów w osobnych kontekstach przekazywania, a to rozdzielenie jest realne i wartościowe. To nie jest szyfrowanie. Specyfikacja BGP/MPLS VPN wyraźnie mówi, że jej prywatność pochodzi z modelu przekazywania, a nie z kryptografii, i dokładnie ta różnica ginie w slajdzie, który mówi tylko VPN.

Jeśli potrzebujesz poufności, potrzebujesz mechanizmu kryptograficznego z uwierzytelnianiem i zarządzaniem kluczami, i musisz wiedzieć, gdzie się kończy. Tunel zapewniający rozdzielenie i tunel zapewniający szyfrowanie mogą być tym samym tunelem, ale tylko wtedy, gdy ktoś skonfigurował oba.

Praktyczną konsekwencją jest to, że „to jest w VPN” odpowiada na pytanie o kontekst routingu i nie mówi nic o tym, kto może czytać bajty na ścieżce. Dwa zespoły mogą mieć oba rację i mimo to opisywać różne rzeczy. Gdy pojawia się pytanie o bezpieczeństwo, pytaj gdzie kończy się kryptografia i co uwierzytelnia partnerów, a nie czy tunel istnieje.

Opóźnienie i QoS podążają za warstwą niższą

Logiczna krawędź nie jest krótszą ścieżką fizyczną. Pakiety zewnętrzne nadal przechodzą przez te same łącza, kolejki i dostawców, a enkapsulacja dodaje narzut na pakiet oraz przetwarzanie na obu końcach. Tunel może być szybki, bo warstwa niższa jest dobra, nigdy dlatego, że jest tunelem.

Traktowanie jakości usługi jest gorsze, bo zależy od domen administracyjnych, których możesz nie kontrolować. Wewnętrzne oznaczenia trzeba celowo mapować na zewnętrzne, a każdy dostawca na ścieżce musi oferować traktowanie, którego oczekujesz. Szyfrowanie nie tworzy priorytetu; ukrywa pole, którego pośrednie urządzenie mogło użyć do klasyfikacji przepływu.

Zmierz warstwę niższą, zanim coś obiecasz. Raport pokazujący stabilne opóźnienie i brak strat na ścieżce zewnętrznej jest dowodem; diagram z tunelem na nim nie jest.

Wybierz tunel dla potrzebnej relacji sieciowej, a następnie osobno określ szyfrowanie, politykę dostępu, rozmiar pakietu i wydajność. Cztery decyzje, cztery dowody i żadna pojedyncza etykieta, która zastępowałaby którąkolwiek z nich.