Czy Twój klient OpenVPN powinien używać nobind czy stałego portu?

Dwa profile różniące się jedną linią zachowują się inaczej w chwili, gdy na tym samym hoście startuje drugi klient. Jeden ma nobind i bierze dowolny port lokalny, który przydzieli jądro; drugi rezerwuje 1194, a druga instancja ginie z adresem już używanym. Ta linia decyduje, kto wybiera port źródłowy, co z kolei decyduje, czy profil może współistnieć z czymkolwiek innym na maszynie. Trzy pytania to rozstrzygają, a pierwsze odpowiada większości profili, zanim dojdziesz do pozostałych dwóch.

Co nobind faktycznie pomija

Domyślnie klient wiąże lokalny socket przed połączeniem, a port lokalny to 1194, chyba że profil mówi inaczej. nobind usuwa tę rezerwację, więc stos przydziela nieużywany port w momencie połączenia. To wyjątek, nie domyślne ustawienie, i klient bez tej linii trzyma 1194, i właśnie dlatego nieprzypięta druga instancja koliduje. Większość dostarczanych profili klienta zawiera tę dyrektywę z tego powodu, a to, że przykładowy plik coś robi, nie znaczy, że mechanizm robi to domyślnie.

Nie zmienia się druga strona. Serwer nadal nasłuchuje tam, gdzie profil mówi, że nasłuchuje, a port docelowy w konfiguracji nadal jest portem docelowym. Dynamiczny port źródłowy zmienia adres zwrotny własnego gniazda i nic w gnieździe serwera.

Nie ukrywa też niczego. Twój adres publiczny to, na co tłumaczy go ścieżka, pakiet nadal przechodzi przez sieć lokalną, a kto nią zarządza, nadal widzi przepływ. nobind nie jest funkcją prywatności ani obejściem zapory.

Trzy warunki, które to rozstrzygają

Jedno pytanie rozstrzyga pozostałe dwa, więc odpowiedz na nie, zanim cokolwiek zmienisz. Jeśli partner łączy się na zewnątrz, pozostałe pytania tylko doprecyzowują już podjętą decyzję. Jeśli przyjmuje połączenia przychodzące, żadne dostrojenie portu lokalnego nie uczyni go osiągalnym.

Czy ten partner inicjuje połączenie? Jeśli łączy się na zewnątrz, dynamiczny port źródłowy jest nieszkodliwy i zwykle lepszy, bo odpowiedź wraca tym samym przepływem. Jeśli czeka na połączenia przychodzące, dynamiczny port czyni go nieosiągalnym, chyba że coś z przodu opublikuje port. Ta jedna odpowiedź oddziela każdy profil klienta od każdego profilu serwera.

Czy ścieżka filtruje po porcie źródłowym? Ścisła reguła napisana dla jednego znanego portu wymusza jawny port lokalny, a profil powinien odnotować, której regule odpowiada. Większość sieci filtruje tylko po celu, więc ten warunek jest rzadszy niż pierwszy. Gdzie obowiązuje, tam przeważa nad preferencją dynamicznego portu.

Czy kilka instancji dzieli hosta? Jeden stały port nie może obsłużyć dwóch z nich, a zrestartowana instancja może znaleźć 1194 wciąż w stanie zamykania. Dynamiczne porty usuwają ten konflikt, nie zmieniając niczego innego. Jeśli nie potrafisz na to odpowiedzieć z pewnością, przyjmij tak i pozwól jądru wybrać.

Gdzie przypięty port jest właściwą odpowiedzią

Niektóre sieci filtrują zarówno po porcie źródłowym, jak i po celu, więc operator mógł napisać regułę, która wpuszcza tylko ruch z jednego znanego portu. Przypięcie portu lokalnego jest wtedy poprawne, a profil powinien zawierać komentarz nazywający spełnianą regułę. Przypinanie dla symetrii z portem serwera nie jest powodem, bo te dwie liczby nie mają ze sobą nic wspólnego. Jeśli przypięcie istnieje tylko dlatego, że miał je szablon, usuń je.

W przeciwnym razie przypięty port kupuje kłopoty: dwa klienty na jednej maszynie nie mogą oba trzymać 1194, a drugi zawodzi z błędem wskazującym port, a nie profil. Kontener, który szybko się restartuje, trafia na tę samą ścianę. Naprawą jest dyrektywa, którą dostarczane profile już zawierały.

Serwer i klient nie są symetryczne

podręcznik OpenVPN 2.6 stawia nobind obok lport, co jest argumentem w jednej linii: jedna opcja mówi, że wybiera jądro, druga, że wybierasz ty. Dynamiczny port lokalny działa tylko dla partnera, który łączy się na zewnątrz, bo strona odpowiadająca nie może znać portu z góry. Dlatego kopiowanie profilu klienta na serwer tworzy nasłuchiwacz, do którego nikt nie dotrze.

Na hoście z wieloma interfejsami sieciowymi adres jest decyzją odrębną od portu. Wiązanie konkretnego adresu lokalnego i wiązanie konkretnego portu to dwa różne ustawienia, a serwer z dwoma łączami wyjściowymi zwykle przypina oba. Klient, który przypina oba, przyjął tę samą sztywność bez żadnej korzyści.

Podsumowanie dotyczy ról, a nie bezpieczeństwa: kto łączy się na zewnątrz, może być elastyczny co do własnego źródła, a kto odpowiada, nie może. Żaden wybór nie zmienia tego, czego druga strona dowiaduje się o twojej tożsamości. To także dlatego dyrektywa pojawia się w przykładach klientów i prawie nigdy w przykładach serwerów.

Sprawdź port wybrany przez jądro

Po połączeniu czytaj gniazdo, a nie konfigurację, bo konfiguracja mówi o zamiarze, a gniazdo o tym, co się stało. Fakty warte zapisania to port lokalny, zdalny punkt końcowy i to, czy coś jeszcze nasłuchuje. Na hoście Linux wszystkie trzy są o jedno polecenie.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Klient z nobind pokazuje wysoki port lokalny i skonfigurowany port zdalny, co jest oczekiwanym kształtem. Serwer pokazuje gniazdo nasłuchujące na swoim skonfigurowanym porcie, a jeśli tego gniazda brakuje, profil albo nie jest nasłuchiwaczem, albo nie zdołał się związać. Gdy przepływ istnieje, ale pakiety nie wracają, porównaj wybrany port źródłowy z dowolnym filtrem portów na ścieżce, zanim zmienisz profil. Zmień jedną rzecz, połącz się ponownie i przeczytaj gniazdo jeszcze raz.