Dlaczego odpowiedź UDP OpenVPN wychodzi z niewłaściwego adresu

Klient OpenVPN łączy się z jednym adresem, serwer odpowiada z innego, a tunel nigdy nie wstaje. Dziennik serwera pokazuje przychodzący pakiet, a zrzut pokazuje wychodzącą odpowiedź, więc winą obarcza się klienta. Na hoście z kilkoma interfejsami albo kilkoma adresami na jednym interfejsie obie strony po prostu nie zgadzają się co do tego, który adres jest używany. Odpowiedź jest poprawna na poziomie IP, jednak wiele klientów odrzuca datagram, którego źródłem nie jest adres, z którym się łączyły.

Co widzi klient, gdy źródło się zmienia

Gniazdo UDP niezwiązane z konkretnym adresem lokalnym nie ma stałego źródła, więc jądro wybiera je w momencie wysyłania. Ten wybór pochodzi z wyszukania trasy do adresu klienta, a źródłem staje się adres interfejsu wybranego przez wyszukanie. Na maszynie z jednym interfejsem wybór jest niewidoczny; na hoście z adresem zarządzania, adresem publicznym i adresem dodatkowym na tej samej karcie sieciowej zależy on od metryk i polityki routingu. Routing oparty na politykach czyni niezgodność bardziej prawdopodobną, a nie mniej, bo reguła może wybrać łącze nadrzędne, do którego klient nigdy nie dotarł. Wystarczy trasa domyślna nauczona od jednego dostawcy i reguła źródła wskazująca na innego.

Klienci, którzy filtrują odpowiedzi, oraz śledzenie połączeń oczekujące dokładnej czwórki i źródła, odrzucą odpowiedź bez użytecznego komunikatu. Wtedy tunel wygasa, jakby nic nie dotarło, i dlatego jest to mylnie brane za problem zapory po stronie klienta. Zrzut wykonany tylko na serwerze potwierdza błąd zamiast go wyjaśnić, ponieważ odpowiedź naprawdę wychodzi. Porównaj źródło odpowiedzi z adresem, z którym połączył się klient, zanim zmienisz cokolwiek innego.

Co faktycznie robi opcja multihome

Dyrektywę zapisuje się jako multihome w pliku konfiguracyjnym i jako --multihome w wierszu poleceń, i sprawia ona, że serwer UDP odpowiada z adresu, do którego dotarł pakiet klienta. Jądro przekazuje pierwotny adres docelowy jako dane pomocnicze przy odbiorze, a OpenVPN używa tej wartości jako źródła odpowiedzi. Dzięki temu serwer nasłuchujący na adresie wieloznacznym, local 0.0.0.0 dla IPv4 lub jego odpowiednik IPv6, zachowuje się tak, jakby każdy klient dotarł do osobnego nasłuchu. Klienci, którzy weszli przez adres publiczny, otrzymują odpowiedzi z adresu publicznego, a klienci na adresie wewnętrznym z tego adresu. Nic innego na ścieżce pakietu się nie rusza: trasa, reguły filtra i konfiguracja tunelu pozostają dokładnie takie, jakie były.

Właśnie ta ostatnia właściwość czyni opcję bezpieczną do dodania na serwerze, który poza tym działa, i jest także powodem, dla którego nie potrafi naprawić filtra dopuszczającego tylko jeden adres. Pakiet nadal musi zostać przyjęty na drodze, którą idzie, więc korekta źródła zmienia pochodzenie odpowiedzi i nic więcej. Dotyczy to także wyłącznie UDP: nasłuch TCP nie ma tego problemu w tej samej postaci, bo połączenie identyfikuje czwórka, a nie adres źródłowy odpowiedzi.

Kiedy stały adres lokalny jest niewłaściwym ustawieniem domyślnym

Zanim sięgniesz po opcję, sprawdź, czy serwer wiąże jeden konkretny adres lokalny, bo związany nasłuch zawsze odpowiada z tego adresu. Jest to poprawne dla wdrożenia z jednym interfejsem i błędne, gdy tylko klienci legalnie używają więcej niż jednego adresu. Jeśli powiązanie było zamierzone, zdecyduj, czy serwer w ogóle powinien przyjmować ruch na dodatkowych adresach. Usunięcie powiązania zwiększa ekspozycję, więc dozwolone interfejsy i sieci źródłowe muszą egzekwować usługa i filtr, a nie sam adres powiązania.

Dokumentacja OpenVPN ogranicza opcję do serwerów UDP, odnotowuje dodatkowe przetwarzanie na ścieżce pakietu i zapisuje, które platformy ją obsługują. Potwierdź to na zainstalowanym wydaniu, zanim zaczniesz na tym planować. Tam, gdzie nie jest obsługiwana, alternatywą jest powiązanie konkretnego adresu lub naprawa trasy powrotnej, a oba są węższymi zmianami, niż się na pierwszy rzut oka wydaje. Nasłuch na adresie wieloznacznym ma też skutki poza odpowiedziami: serwer na wszystkich adresach jest osiągalny z każdej sieci, do której host jest podłączony, a to może nie być ekspozycja, którą ktoś miał na myśli.

Udowodnij źródło odpowiedzi z zewnątrz

Testuj z zewnątrz serwera i zapisz dokładny adres oraz transport, których użył klient, zanim cokolwiek przechwycisz. Trzy kontrole poniżej odpowiadają na trzy różne pytania, a kolejność ma znaczenie.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Zrzut pokazuje adres źródłowy w odpowiedzi i na tym fakcie opiera się cały artykuł. Lista gniazd pokazuje, do czego serwer naprawdę się przywiązał, bo nasłuch wieloznaczny i konkretny wyglądają w pliku konfiguracyjnym identycznie, a w sieci zachowują się różnie. Wyszukanie trasy pokazuje źródło, które jądro wybrałoby dla tego przepływu, i to wyjaśnia zrzut, zanim cokolwiek zmienisz. Powtórz wszystkie trzy osobno dla IPv4 i IPv6, bo to osobne nasłuchy i osobne wyszukania, a wpis wieloznaczny dla jednej rodziny nic nie mówi o drugiej.

Routing, wykrywanie i filtrowanie pozostają osobne

Zachowanie źródła odpowiedzi nie instaluje trasy wychodzącej, nie aktualizuje dynamicznego DNS i nie sprawia, że jedna rodzina adresów akceptuje drugą. Na serwerze z kilkoma łączami nadrzędnymi trasę powrotną dla każdego źródła trzeba uzgodnić świadomie, inaczej odpowiedzi wychodzą interfejsem, którego filtr klienta nigdy nie dopuścił. Podobnie nowy adres po zmianie prefiksu musi dotrzeć do klientów przez wykrywanie i obsługiwany przepływ ponownego połączenia, a nie przez stary rekord.

Pozostaw kontrole tożsamości serwera i weryfikację certyfikatów dokładnie takie, jakie są, bo zmieniony adres nie uzasadnia przyjęcia niezweryfikowanego partnera. Jeśli odpowiedź wychodzi teraz z zamierzonego źródła, a tunel nadal zawodzi, uznaj problem źródła za rozwiązany i idź dalej. Następny zaobserwowany błąd należy do routingu, filtrowania lub uwierzytelniania, a kolejna zmiana nasłuchu do niego nie dotrze. Zapisz źródło odpowiedzi w zgłoszeniu obok adresu, z którym połączył się klient, aby następna osoba mogła sprawdzić ten sam fakt jednym poleceniem.