Raspberry Pi VPN-Server auf Ethernet umstellen

Den Pi von WLAN auf ein Kabel umzustellen sieht nach einer Fünf-Minuten-Arbeit aus, und das bleibt es nur, wenn man den Wechsel als vier getrennte Einstellungen behandelt statt als eine. Der Endpunktname, den Ihre Clients anwählen, kann exakt gleich bleiben, während sich die Adresse darunter ändert. Was tatsächlich bricht, ist ein Listener, der an die alte Adresse gebunden ist, eine Portweiterleitung, die noch auf den WLAN-Lease zeigt, oder eine Rückroute, die über die Schnittstelle hinausgeht, die Sie für stillgelegt hielten. Diese Anleitung hält bei jedem Schritt einen Wiederherstellungspfad offen, sodass eine gescheiterte Umstellung nur einen Neustart kostet.

Die vier Verantwortlichen notieren, bevor Sie das Kabel ziehen

Vier Einstellungen entscheiden darüber, ob die Umstellung übersteht: die Pi-Adresse, die OpenVPN-Bindeadresse, das Ziel der Router-Weiterleitung und der Weg, den Antworten nehmen. Schreiben Sie alle vier auf, bevor Sie das Kabel berühren, denn sobald der WLAN-Lease verschwindet, können Sie die alten Werte nicht mehr von der Maschine ablesen. Die verkabelte Schnittstelle erbt das WLAN-Profil nicht, und unter Bookworm liegt die Adresse im NetworkManager, während Bullseye sie in dhcpcd.conf. Eine Reservierung, die an die WLAN-MAC-Adresse gebunden war, sagt nichts über eth0. Betrachten Sie die neue Adresse als neue Zuweisung, die ihren eigenen Nachweis braucht.

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

Der Listener ist der zweite Verantwortliche. Wurde der Dienst mit einer bestimmten Bindeadresse gestartet, stirbt der Socket mit der alten Schnittstelle; bindet er alle Adressen, überlebt der Socket und die Router-Regel ist das Einzige, was noch zu korrigieren bleibt.

Das Weiterleitungsziel und der Rückweg sind die Verantwortlichen, die Leute überspringen. Eine Weiterleitung, die noch auf 10.42.7.24 zeigt, schickt ankommende Handshakes an eine Adresse, die der Pi nicht mehr besitzt, sodass Clients ohne jede serverseitige Logzeile in einen Timeout laufen. Der Rückweg zählt, wenn beide Links kurzzeitig aktiv sind, denn der Pi antwortet über die Schnittstelle, die die Routing-Tabelle bevorzugt, und das ist nicht immer die, auf der das Paket ankam. Die Routenabfrage unten zeigt, welche Quelle der Kernel wählt.

Den tatsächlichen Socket lesen, bevor Sie der neuen Adresse trauen

Konfigurationsdateien beschreiben die Absicht, und der Socket beschreibt die Realität. Fragen Sie den laufenden Dienst, woran er gebunden ist, statt der Konfiguration zu vertrauen, die Sie in Erinnerung haben. Das OpenVPN-2.6-Handbuch definiert --local als Bindung an eine Adresse und merkt an, dass das Weglassen jede Schnittstelle bindet.

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

Lesen Sie die Spalte der lokalen Adresse statt der Status-Spalte. Eine Zeile mit 10.42.7.24:1194 bedeutet, dass der Socket an die Adresse gebunden ist, die Sie gleich entfernen, während 0.0.0.0:1194 oder *:1194 bedeutet, dass der Daemon der Schnittstellenänderung von selbst folgt. Ist die Adresse gebunden, bearbeiten Sie das Profil und starten Sie die Unit neu, statt den laufenden Socket von Hand umzuschreiben, und prüfen Sie dann, ob der Dienst seine Zertifikats- und Schlüsseldateien noch erreicht.

Den Umzug in einer Reihenfolge gehen, die Sie erreichbar hält

Die Reihenfolge zählt hier mehr als das Tempo. Bringen Sie den verkabelten Link zum Laufen, während der WLAN-Link noch funktioniert, bestätigen Sie die neue Adresse und den Rückweg und legen Sie dann das WLAN-Profil still. Diese Abfolge hält eine funktionierende Sitzung offen, bis der Ersatz bewiesen ist.

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

Der erste Befehl beantwortet, ob eth0 die Adresse erhalten hat, die Sie beabsichtigt haben, und der zweite gibt die Quelladresse aus, die der Kernel für ein Ziel außerhalb verwenden würde; führen Sie ihn also vor und nach der Änderung aus. Ist diese Quelle noch die WLAN-Adresse, ist der verkabelte Link noch nicht der bevorzugte Pfad, und der Test von außen schlägt aus einem Grund fehl, der nichts mit OpenVPN zu tun hat. Korrigieren Sie die Routing-Präferenz, bevor Sie die Weiterleitung anfassen.

Bei beiden aktiven Links bevorzugt der Pi möglicherweise die WLAN-Standardroute, weil sie zuerst eingerichtet wurde oder weil der verkabelte Link eine höhere Metrik trägt. Unter Bookworm ist der unterstützte Schalter ipv4.route-metric auf der Verbindung, und unter Bullseye ist das Gegenstück eine schnittstellenspezifische metric-Zeile in dhcpcd.conf. Stufen Sie den WLAN-Link herab, statt ihn zu deaktivieren, damit der Rollback-Pfad nur einen Befehl entfernt bleibt.

Den Tunnel von außen beweisen, nicht aus dem LAN

Eine VPN-Verbindung, die vom Sofa aus funktioniert, beweist weniger, als es scheint. Verkehr aus dem LAN zur öffentlichen Adresse durchläuft Hairpin- oder Reflexionsregeln, die Router uneinheitlich umsetzen, sodass ein bestandener LAN-Test mit einem kaputten Außenpfad zusammenleben kann. Nutzen Sie für den Abnahmetest ein Handy mit Mobilfunkdaten oder einen beliebigen Host außerhalb des Netzwerks. Behalten Sie den LAN-Versuch als separate optionale Diagnose.

Dann lesen Sie das Log in der Reihenfolge, in der die Pakete ankommen. Gar nichts bedeutet, dass der Handshake den Pi nie erreicht hat, also stimmt das Weiterleitungsziel oder die Host-Firewall nicht. Ein Handshake, der beginnt und stockt, deutet auf Schlüssel, Zertifikate oder MTU. Eine Sitzung, die abschließt und abbricht, bedeutet meist den Rückweg oder eine zweite Standardroute, und die Client-Logzeile Initialization Sequence Completed sagt Ihnen, dass der Tunnel selbst hochgekommen ist.

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

Wenn im Server-Log nichts erscheint, während der Client es erneut versucht, hören Sie auf, OpenVPN-Konfiguration zu lesen, und gehen Sie zum Weiterleitungsziel zurück. Der Mitschnitt beantwortet die Ankunftsfrage in Sekunden, und eingehende Pakete ohne Antwort verengen das Problem auf die Route.

Einen einstufigen Rollback behalten und das WLAN-Profil stilllegen

Lassen Sie das WLAN-Profil installiert, bis die verkabelte Anordnung einen Neustart überstanden hat. nmcli con show listet die Profilnamen auf, die Sie brauchen werden, und ein gelöschtes Profil muss im schlimmsten Moment aus dem Gedächtnis neu gebaut werden. Notieren Sie den Schnittstellennamen, die Adressmethode und die Metrik neben den anderen vier Werten. Ein Rollback, den Sie aus einer Notiz tippen können, ist mehr wert als einer, den Sie rekonstruieren müssen.

Das WLAN-Abhängigkeit stillzulegen ist eine Eigenschaftsänderung statt einer Löschung. Mit connection.autoconnect no bleiben die Zugangsdaten und die Adresshistorie intakt, während der Pi daran gehindert wird, sich wieder mit einem Netzwerk zu verbinden, von dem Sie weggezogen sind.

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

Bevor Sie den Job als erledigt bezeichnen, bestätigen Sie vier Dinge: Das Weiterleitungsziel passt zur verkabelten Adresse, der Listener hat einen Neustart überlebt, ein Client von außen schließt einen Handshake ab, und der Pi antwortet nach einem Neustart noch auf der verkabelten Adresse. Ein Neustart ist der billigste Weg, eine Zuweisung zu erwischen, die nur im laufenden Kernel existierte. Wenn eines der vier scheitert, bringen Sie das WLAN-Profil mit sudo nmcli con up wieder hoch und vergleichen Sie die notierten Werte mit den laufenden.