Port źródłowy klienta a gniazdo nasłuchujące serwera w przepływie VPN
Porównaj dwa numery portów w jednym tunelu: stały nasłuch serwera i krótkotrwałe źródło klienta oraz jak między nimi mieści się tłumaczenie routera.
W tej samej rozmowie pojawiają się dwa numery i żaden z nich nie jest błędny. Dziennik serwera pokazuje nasłuch, który oferuje usługę, laptop pokazuje gniazdo, które wysłało datagram, a router pomiędzy może przepisać drugi numer na wyjściu. Porównywanie końców rozmowy jest użyteczniejsze niż porównywanie cyfr. Poniższe zestawienie trzyma osobno nasłuch, gniazdo klienta i przetłumaczone źródło, ponieważ odpowiadają na różne pytania.
Dwa numery opisujące przeciwne końce
Skonfigurowany port serwera to cel, do którego dzwoni klient. Jest ustalony przez politykę, występuje w profilu i musi być otwarty po stronie serwera. Port źródłowy klienta jest wybierany lokalnie, zwykle z zakresu efemerycznego, i istnieje po to, by odpowiedź miała gdzie wylądować. Może się zmieniać przy każdym ponownym połączeniu i nic w projekcie nie zależy od jego stabilności.
Router pomiędzy może przepisać to źródło na własne mapowanie 'NAT'. Dlatego numer widziany na serwerze często nie ma żadnego związku z tym, który wybrał laptop.
Gdzie numer źródłowy zmienia się na wyjściu
Weź wymyślony przykład IPv4: klient za routerem, który tłumaczy, serwer z jednym nasłuchem 'UDP' i jeden datagram przechodzący przez oba. Tabela nazywa każdy koniec i to, co się z nim dzieje, zamiast odtwarzać pakiet w trzech punktach obserwacji.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
Cel jest stały w każdym wierszu, a zmienia się tylko tożsamość źródła. Wymagania UDP NAT odróżniają adres i port wewnętrzny od mapowania zewnętrznego, co jest dokładnie różnicą między drugim a trzecim wierszem. Router może zachować port źródłowy klienta albo wybrać inny; zachowanie nie jest czymś, co aplikacja powinna zakładać.
Odczytaj trzy końce z samych hostów
Poniższe listy pochodzą z trzech różnych maszyn i razem pokazują całą rozmowę. Uruchom pierwszą na serwerze, drugą na kliencie, a trzecią tam, gdzie istnieje mapowanie. Jedna linia dziennika nigdy nie pokazuje wszystkich trzech.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Pierwsza lista dowodzi, że serwer jest związany z portem usługi, i pokazuje, który proces go posiada. Druga pokazuje lokalne gniazdo klienta i cel, do którego zadzwonił. Trzecia pokazuje mapowanie utworzone przez router, i to jedyne miejsce, w którym pojawia się przetłumaczone źródło. Przeczytaj je w tej kolejności, a dwa numery przestaną wyglądać sprzecznie.
Co zmienia ponowne połączenie, a czego nie
Niektóre routery zachowują port źródłowy klienta, gdy jest wolny, a inne przydzielają za każdym razem inny. Oba zachowania są normalne, a aplikacja wymagająca pierwszego zepsuje się na drugim. Zmiana mapowania po ponownym połączeniu lub przełączeniu sieci nie jest awarią serwera: klient otwiera nowe gniazdo, router przydziela to, co ma, a serwer widzi nowe źródło na tym samym nasłuchu. Awarją byłoby oczekiwanie, że serwer przyjmie ruch adresowany do dowolnego portu klienta.
Klienci OpenVPN ze społeczności uzyskują to zachowanie dzięki nobind, co pozwala systemowi operacyjnemu wybrać port lokalny; port zdalny nadal pochodzi z profilu. Jawne wiązanie jest świadomą decyzją, a nie wymogiem protokołu. Serwer nadal oferuje jeden koniec, podczas gdy klienci wybierają własne tożsamości lokalne.
Oznacz warstwy osobno w zapisie
Wewnątrz tunelu toczy się druga rozmowa z własnymi portami. Żądanie HTTPS przenoszone przez tunel ma cel TCP 443, podczas gdy zewnętrzne połączenie szyfrowane używa UDP 1194, więc zmiana zewnętrznego portu źródłowego niczego nie zmienia w usłudze wewnętrznej.
Nawet na warstwie zewnętrznej protokół ma znaczenie. UDP 1194 i TCP 1194 to różne końce, a nasłuch 'TCP' nigdy nie odbierze datagramu UDP tylko dlatego, że numer się zgadza. Dokumentując wdrożenie, oznacz nasłuch serwera, gniazdo klienta i przetłumaczone źródło jako trzy różne rzeczy i dodaj do każdego transport.
Potem pozwól, by polityka podążała za rolami. Serwer otwiera zamierzony transport na swoim nasłuchu i nadal uwierzytelnia drugą stronę; zapora klienta przepuszcza odpowiedzi na jego własną wymianę wychodzącą bez publikowania usługi przychodzącej. Filtr bezstanowy potrzebuje wyraźnie zapisanego kierunku powrotu i to jest praktyczny powód, dla którego rozróżnienie ma znaczenie poza schludnymi diagramami.