Jak przenieść serwer VPN Raspberry Pi na Ethernet

Przestawienie Pi z Wi-Fi na kabel wygląda na pięciominutową robotę i pozostaje nią tylko wtedy, gdy potraktujesz przeprowadzkę jako cztery osobne ustawienia, a nie jedno. Nazwa punktu końcowego, na który łączą się klienci, może pozostać dokładnie taka sama, podczas gdy adres pod nią się zmienia. Naprawdę psuje się listener przypięty do starego adresu, przekierowanie portu wciąż skierowane na dzierżawę Wi-Fi albo trasa powrotna wychodząca przez interfejs, który uważałeś za wycofany. Ten przewodnik utrzymuje otwartą ścieżkę odzyskiwania na każdym etapie, więc nieudane przejście kosztuje tylko restart.

Zapisz czterech odpowiedzialnych, zanim cokolwiek odłączysz

Cztery ustawienia decydują, czy przejście się utrzyma: adres Pi, adres powiązania OpenVPN, cel przekierowania routera i ścieżka, którą podążają odpowiedzi. Zapisz wszystkie cztery, zanim dotkniesz kabla, bo gdy zniknie dzierżawa Wi-Fi, nie odczytasz już starych wartości z maszyny. Interfejs przewodowy nie dziedziczy profilu Wi-Fi, a w Bookwormie adres mieszka w NetworkManagerze, podczas gdy Bullseye trzyma go w dhcpcd.conf. Rezerwacja, która przypinała adres MAC Wi-Fi, nie mówi nic o eth0. Traktuj nowy adres jako nowe przypisanie, które potrzebuje własnego dowodu.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

Listener jest drugim odpowiedzialnym. Jeśli usługa została uruchomiona z konkretnym adresem powiązania, socket umiera wraz ze starym interfejsem; jeśli wiąże wszystkie adresy, socket przeżywa, a reguła routera staje się jedyną rzeczą, którą trzeba naprawić.

Cel przekierowania i trasa powrotna to odpowiedzialni, których ludzie pomijają. Przekierowanie wciąż wskazujące na 10.42.7.24 wysyła przychodzące handshake’i na adres, którego Pi już nie ma, więc klienci kończą się przekroczeniem czasu bez żadnej linii logu po stronie serwera. Trasa powrotna ma znaczenie, gdy oba łącza są przez chwilę aktywne, bo Pi odpowiada przez interfejs, który preferuje tablica routingu, a to nie zawsze ten, na którym pakiet dotarł. Poniższe wyszukiwanie trasy pokazuje, które źródło wybiera jądro.

Odczytaj rzeczywisty socket, zanim zaufasz nowemu adresowi

Pliki konfiguracyjne opisują intencję, a socket opisuje rzeczywistość. Zapytaj działającą usługę, do czego jest przywiązana, zamiast ufać konfiguracji, którą pamiętasz. Podręcznik OpenVPN 2.6 definiuje --local jako powiązanie z jednym adresem i zauważa, że pominięcie go wiąże każdy interfejs.

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

Odczytaj kolumnę adresu lokalnego zamiast kolumny stanu. Wiersz pokazujący 10.42.7.24:1194 oznacza, że socket jest przypięty do adresu, który za chwilę usuniesz, podczas gdy 0.0.0.0:1194 lub *:1194 oznacza, że demon sam pójdzie za zmianą interfejsu. Jeśli adres jest przypięty, edytuj profil i uruchom ponownie jednostkę, zamiast ręcznie przepisywać działający socket, a następnie potwierdź, że usługa nadal dociera do swoich plików certyfikatu i klucza.

Przejdź przeprowadzkę w kolejności, która utrzymuje cię w zasięgu

Kolejność liczy się tu bardziej niż szybkość. Podnieś łącze przewodowe, gdy bezprzewodowe jeszcze działa, potwierdź nowy adres i trasę powrotną, a potem wycofaj profil Wi-Fi. Ta sekwencja utrzymuje działającą sesję otwartą, dopóki zamiennik nie zostanie udowodniony.

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

Pierwsze polecenie odpowiada, czy eth0 otrzymał adres, który zamierzałeś, a drugie wypisuje adres źródłowy, którego jądro użyłoby dla celu zewnętrznego, więc uruchom je przed zmianą i po niej. Jeśli tym źródłem jest wciąż adres Wi-Fi, łącze przewodowe nie jest jeszcze preferowaną ścieżką i test z zewnątrz zawiedzie z powodu, który nie ma nic wspólnego z OpenVPN. Popraw preferencję routingu, zanim dotkniesz przekierowania.

Gdy oba łącza są aktywne, Pi może preferować domyślną trasę Wi-Fi, bo została skonfigurowana pierwsza albo bo łącze przewodowe ma wyższą metrykę. W Bookwormie obsługiwanym pokrętłem jest ipv4.route-metric na połączeniu, a w Bullseye odpowiednikiem jest specyficzna dla interfejsu linia metric w pliku dhcpcd.conf. Zdegraduj łącze Wi-Fi zamiast je wyłączać, żeby ścieżka wycofania pozostała o jedno polecenie.

Udowodnij tunel z zewnątrz, nie z LAN-u

Połączenie VPN działające z kanapy dowodzi mniej, niż się wydaje. Ruch z wnętrza LAN-u do publicznego adresu przechodzi przez reguły hairpin lub odbicia, które routery wdrażają niespójnie, więc udany test LAN może współistnieć z zepsutą ścieżką zewnętrzną. Do testu akceptacyjnego użyj telefonu z danymi komórkowymi albo dowolnego hosta spoza sieci. Próby LAN trzymaj jako osobną opcjonalną diagnostykę.

Potem czytaj log w kolejności, w jakiej przychodzą pakiety. Zupełnie nic oznacza, że handshake nigdy nie dotarł do Pi, więc cel przekierowania albo firewall hosta jest zły. Handshake, który się zaczyna i zacina, wskazuje na klucze, certyfikaty lub MTU. Sesja, która się kończy i spada, zwykle oznacza trasę powrotną lub drugą trasę domyślną, a linia logu klienta Initialization Sequence Completed mówi ci, że sam tunel wstał.

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

Jeśli w logu serwera nic się nie pojawia, gdy klient ponawia próbę, przestań czytać konfigurację OpenVPN i wróć do celu przekierowania. Przechwycenie odpowiada na pytanie o dotarcie w sekundach, a pakiety przychodzące bez odpowiedzi zawężają problem do trasy.

Zachowaj wycofanie w jednym kroku i wycofaj profil Wi-Fi

Zostaw profil Wi-Fi zainstalowany, dopóki układ przewodowy nie przejdzie restartu. nmcli con show wymienia nazwy profili, których będziesz potrzebować, a usunięty profil trzeba odtworzyć z pamięci w najgorszym momencie. Zapisz nazwę interfejsu, metodę adresowania i metrykę obok pozostałych czterech wartości. Wycofanie, które możesz wpisać z notatki, jest warte więcej niż takie, które musisz odtworzyć.

Wycofanie zależności od Wi-Fi to zmiana właściwości, a nie usunięcie. Ustawienie connection.autoconnect no zachowuje dane logowania i historię adresów bez zmian, a jednocześnie blokuje Pi przed ponownym podłączeniem do sieci, z której odszedłeś.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

Zanim uznasz robotę za skończoną, potwierdź cztery rzeczy: cel przekierowania pasuje do adresu przewodowego, listener przetrwał restart, klient z zewnątrz kończy handshake, a Pi nadal odpowiada na adresie przewodowym po restarcie. Restart to najtańszy sposób na złapanie przypisania, które istniało tylko w działającym jądrze. Jeśli którykolwiek z czterech zawiedzie, podnieś ponownie profil Wi-Fi za pomocą sudo nmcli con up i porównaj zapisane wartości z aktywnymi.