Dlaczego wiele połączeń aplikacji dzieli jedną sesję OpenVPN

Wyobraźcie sobie przeglądarkę ładującą stronę HTTPS, gdy klient SSH dociera do innego serwera, a resolver odpowiada na zapytanie — wszystko przez jedną sesję OpenVPN. Na interfejsie fizycznym widzicie jedną rozmowę; wewnątrz tunelu widzicie trzy. Oba obrazy są poprawne, a wiedza, dlaczego tak jest, to różnica między użytecznym a mylącym przechwyceniem. Prześledźcie jeden wewnętrzny strumień od gniazda do przewodu, a warstwowość przestaje być abstrakcyjna.

Jedna zewnętrzna rozmowa, wiele wewnętrznych strumieni

Każda aplikacja otwiera własne gniazdo, a jądro daje mu piątkę: adres źródłowy, port źródłowy, adres docelowy, port docelowy i protokół. Te piątki istnieją, zanim pojawi się jakikolwiek tunel. Potem trasowanie decyduje, że wszystkie wychodzą przez urządzenie tunelu, więc pakiet przekazany do OpenVPN nadal niesie w sobie oryginalne nagłówki. OpenVPN szyfruje ten wewnętrzny pakiet i pakuje wynik w jedną zewnętrzną rozmowę UDP lub TCP z drugą stroną. Zewnętrzna rozmowa jest więc jedna, a strumieni w niej tyle, ile aplikacji się otworzyło.

Nic się nie zapada. Wewnętrzne piątki przetrwają od końca do końca i właśnie dlatego druga strona nadal rozróżnia trzy strumienie.

Port, który pozostaje stały

Stała pozostaje zewnętrzna piątka: wasz adres, port lokalny przypisany przez klienta, adres drugiej strony i skonfigurowany port usługi. To tę piątkę musi przepuścić firewall lub NAT na drodze, i to ją pokaże przechwycenie na łączu w górę. To także ta, która zmienia się po ponownym połączeniu lub zmianie sieci, bo klient może przypisać inny port lokalny. Jeden tunel nie oznacza jednego stałego portu źródłowego na zawsze.

Wewnętrzne porty są tym, na czym zależy punktom końcowym. Strumień HTTPS zachowuje port docelowy 443 wewnątrz tunelu, nawet jeśli transport zewnętrzny siedzi na porcie skonfigurowanym przez operatora. Punkty końcowe aplikacji nigdy nie dowiadują się o zewnętrznym.

Co dekapsulacja zmienia na drugim końcu

U drugiej strony warstwa zewnętrzna jest zdejmowana i pozostaje pakiet wewnętrzny. Od tego miejsca przekazywanie i polityka dostępu dotyczą wewnętrznego celu i protokołu. Serwer WWW nadal otrzymuje połączenie HTTPS, demon SSH nadal otrzymuje SSH, a resolver nadal otrzymuje zapytanie.

Dlatego reguła zezwalająca na transport zewnętrzny nie jest tą samą regułą co zezwolenie na usługę wewnętrzną. Pierwsza opisuje drogę; druga opisuje upoważnienie.

Zewnętrzny TCP oznacza jeden strumień, nie jedno połączenie

Gdy transport zewnętrzny to UDP, los każdego wewnętrznego strumienia jest niezależny: utracony datagram wpływa na jedno przesyłanie aż do jego własnej retransmisji. Gdy transport zewnętrzny to TCP, wszystkie wewnętrzne strumienie dzielą jeden niezawodny strumień bajtów.

Ten współdzielony strumień to część, którą ludzie przeoczają. Odzyskiwanie następuje raz, dla wszystkiego, więc jeden utracony segment opóźnia ruch każdej multipleksowanej wewnątrz aplikacji. Nadal jest wiele połączeń na punktach końcowych i jedno połączenie na przewodzie, a to na przewodzie żyje efekt zablokowania czoła kolejki. Liczba nasłuchujących portów nic o tym nie mówi, dlatego liczenie portów to zły sposób myślenia o wydajności tunelu.

Opiszcie własną konfigurację dokładnie

Nazwijcie wybrany ruch wewnętrzny i konkretny transport zewnętrzny, który go niesie, zamiast mówić, że maszyna wysyła wszystko jednym portem. Usługi lokalne, drugi tunel i inna rodzina adresów tworzą strumienie, które nigdy nie wchodzą do tej rozmowy. Przechwycenie na łączu w górę pokazuje zewnętrzną piątkę; przechwycenie wewnątrz tunelu pokazuje wewnętrzne.

Weźcie oba i połóżcie znaczniki czasu obok siebie. Jeśli musicie udowodnić, która aplikacja wytworzyła który wewnętrzny strumień, tabela gniazd na hoście jest lepszym narzędziem, bo wiąże porty bezpośrednio z procesami. Potem zapiszcie zaobserwowaną zewnętrzną piątkę i moment obserwacji, bo następne przechwycenie po ponownym połączeniu może całkiem legalnie pokazać inne liczby.