Een Raspberry Pi VPN-server naar Ethernet verhuizen

De Pi van Wi-Fi naar een kabel omzetten lijkt een klus van vijf minuten, en dat blijft zo alleen als je de verhuizing als vier afzonderlijke instellingen behandelt in plaats van één. De endpointnaam die je clients kiezen kan precies hetzelfde blijven terwijl het adres eronder verandert. Wat echt breekt is een listener die aan het oude adres vastzit, een portforwarding die nog naar de draadloze lease wijst, of een retourroute die via de interface vertrekt waarvan je dacht dat je die had afgedankt. Deze uitleg houdt bij elke stap een herstelpad open, zodat een mislukte overgang alleen een herstart kost.

Leg de vier verantwoordelijken vast voordat je iets lostrekt

Vier instellingen bepalen of de overgang het overleeft: het Pi-adres, het OpenVPN-bindadres, het omleidingsdoel van de router en het pad dat antwoorden nemen. Schrijf alle vier op voordat je de kabel aanraakt, want zodra de draadloze lease verdwijnt kun je de oude waarden niet meer van de machine aflezen. De bekabelde interface erft het draadloze profiel niet, en op Bookworm staat het adres in NetworkManager terwijl Bullseye het in dhcpcd.conf houdt. Een reservering die het draadloze MAC-adres vastzette, zegt niets over eth0. Behandel het nieuwe adres als een nieuwe toewijzing die zijn eigen bewijs nodig heeft.

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

De listener is de tweede verantwoordelijke. Als de dienst met een specifiek bindadres is gestart, sterft de socket met de oude interface; als hij alle adressen bindt, overleeft de socket en is de routerregel het enige dat nog te repareren valt.

Het omleidingsdoel en het retourpad zijn de verantwoordelijken die mensen overslaan. Een forward die nog naar 10.42.7.24 wijst, stuurt aankomende handshakes naar een adres dat de Pi niet meer heeft, dus clients lopen in een time-out zonder enige logregel aan de serverkant. Het retourpad doet ertoe wanneer beide links even tegelijk actief zijn, omdat de Pi antwoordt vanaf de interface die de routingtabel verkiest, en dat is niet altijd degene waarop het pakket aankwam. De route-opzoeking hieronder laat zien welke bron de kernel kiest.

Lees de werkelijke socket voordat je het nieuwe adres vertrouwt

Configuratiebestanden beschrijven de bedoeling en de socket beschrijft de werkelijkheid. Vraag de draaiende dienst waaraan hij is gebonden in plaats van de configuratie te vertrouwen die je je herinnert. De OpenVPN 2.6-handleiding definieert --local als binding aan één adres en merkt op dat weglating elke interface bindt.

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

Lees de kolom met het lokale adres in plaats van de statuskolom. Een regel met 10.42.7.24:1194 betekent dat de socket aan het adres vastzit dat je op het punt staat te verwijderen, terwijl 0.0.0.0:1194 of *:1194 betekent dat de daemon de interfacewissel vanzelf volgt. Als het adres vastzit, bewerk dan het profiel en herstart de unit in plaats van de live socket met de hand te herschrijven, en bevestig daarna dat de dienst zijn certificaat- en sleutelbestanden nog bereikt.

Doorloop de verhuizing in een volgorde die je bereikbaar houdt

De volgorde is hier belangrijker dan de snelheid. Breng de bekabelde link omhoog terwijl de draadloze nog werkt, bevestig het nieuwe adres en het retourpad, en dank het draadloze profiel daarna af. Die volgorde houdt een werkende sessie open tot de vervanging bewezen is.

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

De eerste opdracht beantwoordt of eth0 het adres heeft gekregen dat je bedoelde, en de tweede drukt het bronadres af dat de kernel voor een bestemming buiten het netwerk zou gebruiken, dus voer hem voor en na de wijziging uit. Als die bron nog het draadloze adres is, is de bekabelde link nog niet het voorkeurspad en zal de test van buitenaf mislukken om een reden die niets met OpenVPN te maken heeft. Repareer de routingvoorkeur voordat je de forward aanraakt.

Met beide links actief verkiest de Pi misschien de draadloze standaardroute omdat die eerst is ingesteld of omdat de bekabelde link een hogere metriek heeft. Op Bookworm is de ondersteunde knop ipv4.route-metric op de verbinding, en op Bullseye is het equivalent een interfacespecifieke metric-regel in dhcpcd.conf. Degradeer de draadloze link in plaats van hem uit te schakelen, zodat het terugrolpad één opdracht verwijderd blijft.

Bewijs de tunnel van buitenaf, niet vanaf het LAN

Een VPN-verbinding die vanaf de bank werkt, bewijst minder dan het lijkt. Verkeer van binnen het LAN naar het openbare adres gaat door hairpin- of reflectieregels die routers inconsistent implementeren, dus een geslaagde LAN-test kan samengaan met een kapot pad van buitenaf. Gebruik een telefoon op mobiele data, of een willekeurige host buiten het netwerk, voor de acceptatietest. Houd de LAN-poging als aparte optionele diagnose.

Lees daarna de log in de volgorde waarin de pakketten aankomen. Helemaal niets betekent dat de handshake de Pi nooit heeft bereikt, dus het omleidingsdoel of de host-firewall klopt niet. Een handshake die begint en blijft hangen wijst op sleutels, certificaten of MTU. Een sessie die voltooit en wegvalt betekent meestal het retourpad of een tweede standaardroute, en de logregel van de client Initialization Sequence Completed vertelt je dat de tunnel zelf omhoogkwam.

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

Als er niets in de serverlog verschijnt terwijl de client het opnieuw probeert, stop dan met het lezen van de OpenVPN-configuratie en ga terug naar het omleidingsdoel. De capture beantwoordt de aankomstvraag in seconden, en inkomende pakketten zonder antwoord vernauwen het probleem tot de route.

Houd een terugrol in één stap en dank het draadloze profiel af

Laat het draadloze profiel geïnstalleerd tot de bekabelde opstelling een herstart heeft doorstaan. nmcli con show toont de profielnamen die je nodig zult hebben, en een verwijderd profiel moet op het slechtste moment uit je hoofd worden herbouwd. Noteer de interfacenaam, de adresmethode en de metriek naast de andere vier waarden. Een terugrol die je uit een notitie kunt typen is meer waard dan een die je moet reconstrueren.

De draadloze afhankelijkheid afdanken is een eigenschapswijziging in plaats van een verwijdering. Door connection.autoconnect no in te stellen blijven de inloggegevens en de adreshistorie intact terwijl de Pi ervan wordt weerhouden opnieuw verbinding te maken met een netwerk waar je weg bent verhuisd.

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

Voordat je de klus als klaar beschouwt, bevestig vier dingen: het omleidingsdoel komt overeen met het bekabelde adres, de listener heeft een herstart overleefd, een client van buitenaf voltooit een handshake, en de Pi antwoordt na een herstart nog steeds op het bekabelde adres. Een herstart is de goedkoopste manier om een toewijzing te betrappen die alleen in de draaiende kernel bestond. Als een van de vier faalt, breng het draadloze profiel dan terug met sudo nmcli con up en vergelijk de genoteerde waarden met de actieve.