Synology NAS z dwoma portami LAN: dlaczego uzgadnianie VPN zawodzi

Laptop zgłasza błąd uzgadniania TLS, co brzmi jak problem z certyfikatem i zwykle nim nie jest. Na NAS z dwoma portami Ethernet najczęstszą przyczyną jest przekierowanie routera skierowane na adres, na którym pakiet nie nasłuchuje, a komunikat klienta jest w obu przypadkach identyczny. Pakiet nie odpowiada na drugim porcie tylko dlatego, że oba kable są podłączone. Zanim ktokolwiek ponownie wyda certyfikat, udowodnijcie, że pakiet w ogóle dociera do NAS.

Co zgłasza klient i co faktycznie się stało

Błąd uzgadniania z klienta OpenVPN to ogólne określenie. Obejmuje niezgodność certyfikatu, niezgodność transportu, nasłuchującego na innym porcie i przekierowanie, które niczego nie dostarczyło. Dlatego komunikat jest bezużyteczny jako punkt wyjścia, a przydatny tylko jako potwierdzenie. Traktujcie go jako stwierdzenie, że sesja nie została nawiązana, i nic bardziej konkretnego.

Port i powiązany adres to dwa fakty, które decydują, czy pakiet kiedykolwiek dotrze.

Zapiszcie oba, zanim cokolwiek zmienicie, bo wiarygodna poprawka zastosowana na niewłaściwej warstwie jest drogą, na której problem piętnastu minut staje się całym popołudniem. Zanotujcie interfejs, adres na nim, port i transport. Te cztery wartości to cała ścieżka wejściowa, a następny rozdział wyjaśnia, gdzie mieszka każda z nich.

Znajdźcie adres, na którym nasłuchuje pakiet

DSM numeruje porty Ethernet i każdy z nich ma własny adres. Strona VPN Server podaje interfejs używany przez usługę OpenVPN, a panel sieci pokazuje adres skonfigurowany na tym interfejsie. Czytajcie je w tej kolejności, od usługi na zewnątrz, żeby opisywać to, co nasłuchuje, a nie to, co zakładacie, że powinno być używane.

Usługa wiąże jeden adres. To, że oba porty są podłączone i aktywne, nie sprawia, że usługa odpowiada na drugim. Adres statyczny na jednym interfejsie obok adresu DHCP na drugim daje dwie podobne wartości łatwe do pomylenia na pierwszy rzut oka, zwłaszcza gdy różnią się tylko ostatnim oktetem. Skopiujcie adres z panelu, zamiast wpisywać go z pamięci. Potem potwierdźcie na NAS, co jest faktycznie powiązane z portem.

sudo ss -lunp | grep 1194

Jeśli to wyjście podaje adres, którego się nie spodziewaliście, przekierowanie wskazuje niewłaściwy interfejs i wszystko inne tutaj to księgowość. Poprawcie regułę, zanim przeczytacie dalej, inaczej skończycie na debugowaniu certyfikatu z powodu pakietu, który nigdy nie opuścił routera.

Naprawcie przekierowanie, a potem obserwujcie licznik

Edytujcie istniejącą regułę przekierowania, zamiast dodawać drugą dla tego samego portu zewnętrznego. Dwie reguły mogą współistnieć w tabeli routera i zawsze wygrywa tylko jedna, co zamienia sesję debugowania w spór o to, która jest prawdziwa. Skierujcie adres wewnętrzny na wartość odczytaną z NAS, a port wewnętrzny zostawcie zgodny z tym, na czym nasłuchuje usługa.

Jeśli DSM pobiera ten adres przez DHCP, najpierw utwórzcie rezerwację. Zmiana dzierżawy po cichu psuje przekierowanie, które działało wczoraj.

sudo tcpdump -i any -n udp port 1194

Zacznijcie przechwytywanie, zanim klient spróbuje się połączyć, i czytajcie adres źródłowy we wszystkim, co się pojawi. Zupełnie nic oznacza, że coś po drodze to odrzuciło: przekierowanie, zapora DSM albo interfejs, na który było skierowane, a certyfikaty nie mogą być przyczyną, dopóki to się utrzymuje. Coś, co przychodzi z publicznego adresu klienta bez odpowiedzi, oznacza, że NAS odebrał żądanie i zdecydował nie odpowiadać. To różne ustalenia, i tylko drugie odsyła was do ustawień samego pakietu.

Dopiero wtedy spójrzcie na certyfikaty i transport

Gdy pakiety zaczną docierać, eksportujcie profil ponownie po każdej zmianie certyfikatu, bo stary plik nadal nosi urząd, z którym został utworzony. Profil edytowany ręcznie pod inny transport zostawia klienta czekającego na nieistniejącego nasłuchującego, i zgłasza ten sam ogólny błąd co wszystko inne. Porównajcie transport w profilu z transportem, który pakiet ma obsługiwać. Dwa profile dla dwóch transportów to uzasadniony projekt, a jeden profil edytowany dla obu nie jest.

Na koniec przetestujcie spoza własnej sieci, bo połączenie z wnętrza LAN może się udać ścieżką, która nigdy nie dotyka przekierowania.

Trzymajcie wyeksportowany profil, adres interfejsu i regułę przekierowania razem w jednej notatce. Gdy adres się zmienia, ta notatka jest różnicą między naprawą a powtórką. Nic na tej ścieżce nie wymagało ponownej instalacji pakietu, co warto zapamiętać, zanim następny restart zostanie obwiniony.