Jeden Pi, dwie instancje OpenVPN: co czyta każda jednostka
Dwa demony OpenVPN na jednym Pi czytają różne pliki konfiguracji i wychodzą przez różne hooki. Zmapuj każdą instancję, a potem przetestuj osobno ścieżkę ładunku.
Policz procesy OpenVPN, zanim dotkniesz profilu. Pi, który przyjmuje użytkowników roamingowych i jednocześnie łączy się z usługą nadrzędną, uruchamia dwa demony, a każdy z nich czyta plik konfiguracji wybrany przez wpisaną nazwę instancji. Szablony pakietu dają następnie każdemu demonowi własny katalog roboczy, własny plik stanu działania i własne urządzenie tunelu. Jeśli podzielisz to źle, spędzisz wieczór na zmianie poprawnego ustawienia w pliku, którego działający proces nigdy nie otwiera.
Każda nazwa instancji wybiera własny plik
W plikach jednostek dostarczanych z OpenVPN 2.6 argumenty uruchomienia zawierają symbol zastępczy instancji wypełniany tekstem po znaku @. Szablon serwera działa z katalogu konfiguracji serwera i rozwiązuje swój argument względem znajdującego się tam %i.conf, a szablon klienta robi to samo z katalogu klienta. Tak więc [email protected] czyta admits.conf w katalogu serwera, a [email protected] czyta uplink.conf w katalogu klienta, i żadna z tych nazw nie ma znaczenia w drugim katalogu.
Sprawdź mapowanie na maszynie, zamiast zakładać, że pakiet zachował wartości domyślne. Drop-in dystrybucji może całkowicie zastąpić katalog roboczy albo argument konfiguracji.
systemctl cat [email protected]
systemctl cat [email protected]Przeczytaj linię WorkingDirectory i argument konfiguracji w tym wyjściu, bo tylko włączona jednostka decyduje, który plik się ładuje. Drop-in, który dodaje --config do ExecStart, wygrywa z szablonem nawet wtedy, gdy ścieżka szablonu wygląda poprawnie. Pytaj o ścieżki fragmentów i drop-inów, gdy chcesz wiedzieć, czy działa lokalne nadpisanie. Jeśli obie role rozwiązują się do jednego pliku, masz jeden proces próbujący być serwerem i klientem naraz, a późniejsza opcja w tym pliku wygrywa po cichu.
Lokalny transport i przekazywany ładunek trafiają w różne hooki
Zaszyfrowane połączenie serwera z każdym użytkownikiem roamingowym jest generowane na samym Pi, więc jego zewnętrzne odpowiedzi wychodzą przez lokalny hook wyjściowy. Połączenie klienta z jego partnerem nadrzędnym też jest lokalnie generowanym wyjściem, choć dociera do zdalnej sieci. Przekazywany ładunek to trzecia kategoria, a jądro dopasowuje go dopiero po wybraniu urządzenia wyjściowego dla pakietu.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Reguła dopasowująca interfejs wyjściowy wewnątrz łańcucha forward może zezwolić na pakiet, który routing już przypisał temu interfejsowi, albo go odrzucić, ale nigdy nie wybiera interfejsu. Gdy jeden host kończy jeden tunel i rozpoczyna drugi, polityka wysyłająca ładunek użytkowników do tunelu nadrzędnego i polityka chroniąca własne zaszyfrowane odpowiedzi Pi to dwie osobne decyzje. Trafiają przypadkiem na tę samą fizyczną kartę NIC, dlatego bywają mylone.
Ta różnica wyjaśnia częstą połowiczną awarię. Użytkownicy się łączą, uzgadnianie kluczy kończy się, a ich ruch i tak wychodzi w złą stronę, bo uzgadnianie było lokalne, a ładunek przekazywany i sprawdzono tylko jedno z dwojga.
Zaimportowana trasa może połknąć odpowiedzi do twoich użytkowników
Ustawienie bezpieczeństwa profilu klienta decyduje, co strona nadrzędna może wepchnąć do tablicy routingu Pi, a szerokie przekierowanie to opcja, która zamienia działający host o podwójnej roli w zepsuty. Jeśli wepchnięta trasa obejmuje publiczne adresy użytkowników roamingowych, generowane przez serwer odpowiedzi do nich mogą pójść nową trasą do tunelu nadrzędnego zamiast wyjść przez warstwę bazową. Ludzie często potwierdzają, że tunel do dostawcy nadal działa, i na tym poprzestają, bo ten ruch to własny transport tunelu i płynie dalej, gdy wszystko inne zachowuje się źle.
Polityka oparta na źródle albo znaczniku mark pozwala utrzymać oba strumienie osobno. Opcja mark Linuksa w OpenVPN oznacza własne zaszyfrowane pakiety demona znacznikiem zapory, który reguła routingu może potem wysłać do osobnej tablicy. Adresy źródłowe działają równie dobrze, gdy zewnętrzne odpowiedzi serwera zawsze wychodzą z jednego adresu warstwy bazowej. Oba podejścia wymagają poprawnych tras w wybranej tablicy i wyjątku dla punktu końcowego dostawcy, inaczej sam tunel przestaje się podnosić.
Zanim napiszesz jakąkolwiek regułę, zapytaj jądro, którą drogę odpowiedź naprawdę by obrała. Poniższe adresy to placeholdery adresu warstwy bazowej Pi i publicznego adresu jednego użytkownika roamingowego.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Zweryfikuj podział, a potem zatrzymuj jedną rolę naraz
Przetestuj trzy strumienie osobno, bo działające uzgadnianie kluczy niczego nie dowodzi w kwestii pozostałych dwóch. Przyjmij nowe połączenie przychodzące, wyślij jedną dozwoloną aplikację przez wyjście nadrzędne i potwierdź, że oba procesy nadal docierają do swoich partnerów.
Potem zatrzymaj rolę klienta i zobacz, co zachowuje rola serwera. To najtańszy sposób znalezienia reguły trasy lub znacznika mark, która była przeznaczona dla jednej instancji, a została zastosowana do obu.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerChcesz zobaczyć, że nasłuch nadal jest związany, urządzenie tunelu nadal istnieje, a dziennik jest wolny od nowych błędów, gdy rola klienta jest zatrzymana. Jeśli zatrzymanie klienta odcina też odpowiedzi serwera do istniejących użytkowników, obie role dzielą coś, co powinno być ograniczone do jednej z nich. Zapisuj, której instancji, którego pliku konfiguracji i którego właściciela strumienia dotyczyła każda zmiana, bo inaczej następna osoba debugująca ten host powtórzy to samo odkrycie od zera.