Klient OpenVPN zawiesza się, gdy jego serwer działa na tym samym hoście

Miałem maszynę laboratoryjną, która przyjmowała tunel ze zdalnej lokalizacji, a także łączyła się z siecią dostawcy. Profil wychodzący działał od tygodni. Po dodaniu serwera przychodzącego profil wychodzący połączył się, a następnie w ciągu kilku sekund przestał przepuszczać ruch albo odmówił uruchomienia z błędem, że adres jest już w użyciu. Pliki konfiguracyjne się nie zmieniły; host po prostu zyskał drugi proces OpenVPN z własnym zdaniem na temat portów i tras.

Awaria nie jest przypadkowa i nie jest problemem z uwierzytelnianiem. Dwa demony na jednej maszynie konkurują o to samo gniazdo lokalne i tę samą tablicę routingu, a ten, który uruchomi się lub połączy ponownie ostatni, zwykle wygrywa. Wiedza, która z tych dwóch kolizji u ciebie występuje, decyduje, gdzie najpierw spojrzeć.

Czytaj objaw od tyłu

Zacznij od tego, kiedy tunel umiera. Błąd bindowania przy starcie wskazuje na stronę nasłuchującą: coś już zajmuje ten port, a OpenVPN odmawia uruchomienia, zamiast go współdzielić. Tunel, który wstaje, a potem cichnie, wskazuje na routing, ponieważ trasa zainstalowana przez drugą instancję może ściągnąć pakiety połączenia zewnętrznego z ich ścieżki.

Oba przypadki dają tę samą skargę użytkownika, dlatego pętle ponownych prób i skrypty watchdog niczego nie naprawiają. Ponownie łączą klienta w ten sam konflikt. Pierwsze użyteczne pytanie brzmi, czy proces nadal działa, gdy ruch się zatrzymuje.

Jedno gniazdo i jedno urządzenie na instancję

Serwer nasłuchujący wiąże swój port; klient wychodzący także potrzebuje portu lokalnego dla swojego enkapsulowanego ruchu. Gdy oba żyją na tym samym hoście, domyślne zachowanie klienta może kolidować z portem serwera. Port lokalny klienta można przypiąć, a bindowanie można pominąć tam, gdzie partner nie potrzebuje stałego portu źródłowego:

lport 1195
nobind
dev tun1

Te liczby są przykładami, nie wymogiem. Ważne jest to, że klient przestaje konkurować o port serwera, a każda instancja dostaje osobne urządzenie tunelowe. Dwa demony współdzielące tun0 nadpisują nawzajem swój stan urządzenia, nawet gdy ich porty się różnią, więc jedno urządzenie na tunel nie jest opcjonalne.

nobind należy do strony klienta. Serwer nadal musi wiązać i nasłuchiwać, więc nie kopiuj tej linii do konfiguracji serwera i nie wyłączaj bindowania na kliencie, którego partner filtruje po stałym porcie źródłowym.

Wybierz jednego właściciela trasy domyślnej

Tylko jedno połączenie może zainstalować trasę domyślną. Jeśli oba profile przekierowują cały ruch, drugie połączenie po cichu zastępuje pierwsze, a pierwsze wygląda na zepsute. Albo utrzymuj tunel wychodzący rozdzielony i wypychaj tylko prefiksy dostawcy, albo daj mu osobną tablicę routingu.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Adresy i numer tablicy powyżej są elementami zastępczymi. Zaraz po dodaniu reguły potwierdź, że adres samego serwera VPN nadal jest rozwiązywany przez normalną tablicę; tablica, która przechwytuje transport zewnętrzny, psuje tunel, który miała chronić, a następująca po tym pętla ponownego łączenia wygląda jak niewiarygodny dostawca.

W przypadku konfiguracji, która musi przetrwać ponowne połączenia i restarty, przestrzeń nazw sieci jest solidniejszą granicą. Drugi klient działa we własnej przestrzeni nazw z własnymi interfejsami i trasami, a udostępniane są tylko usługi, które muszą ją przekroczyć. Host zachowuje jedną trasę domyślną, a ponowne połączenie przestrzeni nazw nie może jej nadpisać.

Weryfikuj tablicą, nie linią statusu

Klient zgłaszający połączenie dowodzi tylko swojego kanału sterującego. Przechwyć stan routingu przed i po każdym połączeniu, a następnie zapytaj jądro, którego urządzenia użyłby rzeczywisty cel:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Jeśli wybrane urządzenie dla adresu dostawcy zmienia się, gdy startuje drugi tunel, masz kolizję tras. Jeśli oba procesy pojawiają się na tym samym porcie lokalnym, masz kolizję gniazd. Naprawa pierwszego bez drugiego tylko przenosi awarię na następne ponowne połączenie.

Zapisz porty, urządzenia, tablice i właściciela trasy w runbooku hosta. W przeciwnym razie następna osoba, która doda trzeci tunel, ponownie odkryje tę samą kolizję, a jedynym widocznym dowodem będzie połączenie działające do czasu, aż ktoś inny zrestartuje swojego demona.