OpenVPN handshake na Synology zawodzi? Sprawdź przekierowanie LAN

Laptop zgłasza, że handshake TLS nie powiódł się, więc pokusa jest taka, by odbudować certyfikaty. Najpierw zadaj nudniejsze pytanie: na którym porcie Ethernet Synology naprawdę nasłuchuje? NAS z dwoma portami LAN ma dwa adresy, a pakiet VPN Server w DSM wiąże swój nasłuch OpenVPN z jednym z nich. Gdy router przekierowuje 1194 na drugi adres, żaden pakiet nigdy nie dociera do usługi, a klient nie ma o czym negocjować.

Tekst błędu wprowadza w błąd, bo opisuje ostatnią rzecz, którą klient wypróbował, a nie pierwszą, która poszła źle. Dwie minuty porównania strony pakietu z regułą routera rozstrzygają sprawę.

Znajdź adres, do którego przypisany jest nasłuch

DSM nazywa swoje porty LAN 1 i LAN 2, a każdy ma osobny adres i podsieć. Otwórz VPN Server, przeczytaj interfejs wskazany na karcie OpenVPN, następnie otwórz Panel sterowania i zapisz adres IPv4, który DSM ma na tym samym interfejsie. To te dwie wartości, a nie nazwa hosta NAS-a, ma wskazać przekierowanie.

Drugi podłączony kabel nie tworzy drugiego nasłuchu. Oba łącza mogą wydawać się podłączone, podczas gdy tylko jeden adres przyjmuje ruch, a gdy oba interfejsy są w tej samej podsieci, dwa adresy różnią się jedną cyfrą, której nikt nie czyta ponownie przed zapisaniem reguły.

Spójrz na samo gniazdo przez SSH, bo to jedyne miejsce, które pokazuje, do czego demon naprawdę się przypiął, a nie to, co zamierza strona ustawień.

sudo netstat -anp | grep 1194

Edytuj istniejące przekierowanie zamiast dodawać kolejne

Dwie reguły dla jednego portu zewnętrznego zostawiają routerowi swobodę wyboru, a to, którą wybierze, może się zmienić po aktualizacji oprogramowania lub restarcie. Otwórz regułę, która już istnieje, zmień jej adres wewnętrzny, zapisz, następnie otwórz ją ponownie i odczytaj wartość. Nazwanie reguły od usługi pomaga, bo lista pięciu identycznych przekierowań to sposób, w jaki zła reguła przeżywa.

external 1194/udp  ->  192.0.2.20:1194/udp

Utrzymuj port wewnętrzny równy portowi nasłuchu i utrzymuj spójność protokołu. UDP 1194 to domyślny nasłuch, podczas gdy profil TCP potrzebuje własnego nasłuchu po stronie pakietu i pasującego przekierowania na routerze. Przekierowanie TCP do usługi, która nasłuchuje tylko na UDP, daje ciszę, a nie błąd.

Jeśli adres NAS-a pochodzi z DHCP, zarezerwuj go, zanim reguła zostanie zapisana. Wygaśnięcie dzierżawy przydziela adres ponownie, przekierowanie nadal wskazuje starą wartość, a handshake zaczyna zawodzić w dniu, w którym nikt nie dotknął NAS-a. Statyczna konfiguracja po stronie NAS-a rozwiązuje ten sam problem, pod warunkiem że adres leży poza zakresem DHCP routera.

Udowodnij, czy pakiety w ogóle docierają

Najpierw uruchom przechwytywanie na NAS-ie, potem połącz się z klienta i odczytaj adres źródłowy w danych wyjściowych. Przechwytywanie uruchomione po awarii niczego nie pokazuje i niczego nie dowodzi.

sudo tcpdump -i any -n udp port 1194

Cisza oznacza, że ruch zginął przed usługą: zły adres wewnętrzny, zamknięty port na zaporze DSM albo interfejs administracyjnie wyłączony. Pakiety w danych wyjściowych oznaczają, że przekierowanie działa, a pozostała usterka leży powyżej warstwy sieciowej, czyli na znacznie mniejszym obszarze poszukiwań.

Przechwytywanie podaje też interfejs, na którym przyszedł pakiet, i ten jeden szczegół oddziela regułę wycelowaną w zły port od reguły wycelowanej w port, który nie jest aktywny. Obserwuj własny licznik routera podczas tej samej próby, jeśli go pokazuje. Licznik, który się nie rusza, gdy przechwytywanie pozostaje puste, wskazuje router, natomiast licznik, który rusza się przy pustym przechwytywaniu, wskazuje drogę między dwoma urządzeniami.

Kiedy pakiety docierają, przestań obwiniać przekierowanie

Profil jest następnym podejrzanym, a zwykłą przyczyną jest wiek. Wyeksportowany plik .ovpn zawiera urząd i materiał z chwili eksportu, więc pakiet, którego certyfikat później wymieniono, odrzuci klienta wciąż noszącego starą kopię.

Transport to kolejna niezgodność, którą warto sprawdzić wprost, bo profil i pakiet są edytowane w różnych miejscach. Zmiana profilu z UDP na TCP bez przełączenia pakietu zostawia klienta czekającego na nasłuch, który nie istnieje, a klient zgłasza ten sam ogólny tekst handshake, który zgłasza przy wszystkim innym. Przeczytaj wiersz proto w pliku, następnie spójrz na protokół wybrany na stronie serwera i dopiero wtedy uznaj, że się zgadzają. Czytanie reguł zapory DSM to trzecia kontrola: reguła, która dopuszcza port z lokalnej podsieci, ale nie z internetu, łatwo zostaje po testach, a daje połączenie, które działa z kuchni i zawodzi wszędzie indziej.

Przetestuj drogę, którą użytkownik zdalny naprawdę przebywa

Klient w tej samej sieci LAN może dotrzeć do NAS-a bez dotykania przekierowania, więc niczego to nie dowodzi w kwestii dostępu zdalnego. Użyj telefonu z wyłączonym Wi-Fi albo poproś kogoś spoza sieci i obserwuj licznik routera podczas tej próby. Jeśli próba zdalna zawodzi, a lokalna się udaje, przekierowanie lub zapora nadal są w grze.

Zapisz stan, który działa, dopóki działa: port zewnętrzny, adres wewnętrzny, protokół, interfejs pakietu oraz nazwę profilu i datę eksportu. Gdy handshake znów zawiedzie, różnica między tą notatką a bieżącą konfiguracją jest usterką, a nikt nie musi od nowa odkrywać, którego z dwóch portów używa usługa.