Så flyttar du en Raspberry Pi VPN-server till Ethernet

Att byta Pi:n från Wi-Fi till en kabel ser ut som ett femminutersjobb, och det förblir det bara om du behandlar flytten som fyra separata inställningar i stället för en. Slutpunktsnamnet som dina klienter ringer kan förbli exakt detsamma medan adressen under det ändras. Det som faktiskt går sönder är en lyssnare som är bunden till den gamla adressen, en portvidarebefordran som fortfarande pekar på den trådlösa leasen, eller en returväg som lämnar genom det gränssnitt du trodde du hade pensionerat. Den här genomgången håller en återställningsväg öppen vid varje steg, så en misslyckad övergång bara kostar en omstart.

Anteckna de fyra ansvariga innan du kopplar ur något

Fyra inställningar avgör om övergången överlever: Pi-adressen, OpenVPN-bindadressen, routerns omdirigeringsmål och den väg svaren tar. Skriv ner alla fyra innan du rör kabeln, för när den trådlösa leasen försvinner kan du inte läsa av de gamla värdena från maskinen. Det trådbundna gränssnittet ärver inte den trådlösa profilen, och på Bookworm bor adressen i NetworkManager medan Bullseye behåller den i dhcpcd.conf. En reservation som band den trådlösa MAC-adressen säger ingenting om eth0. Behandla den nya adressen som en ny tilldelning som behöver sitt eget bevis.

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

Lyssnaren är den andra ansvariga. Om tjänsten startades med en specifik bindadress dör socketen med det gamla gränssnittet; om den binder alla adresser överlever socketen och routerregeln blir det enda som återstår att fixa.

Omdirigeringsmålet och returvägen är de ansvariga som folk hoppar över. En vidarebefordran som fortfarande pekar på 10.42.7.24 skickar ankommande handskakningar till en adress som Pi:n inte längre har, så klienter time-outar utan någon serverloggrad alls. Returvägen spelar roll när båda länkarna är uppe en kort stund, eftersom Pi:n svarar från det gränssnitt som routingtabellen föredrar, och det är inte alltid det paketet anlände på. Ruttuppslagningen nedan visar vilken källa kärnan väljer.

Läs den faktiska socketen innan du litar på den nya adressen

Konfigurationsfiler beskriver avsikten och socketen beskriver verkligheten. Fråga den körande tjänsten vad den är bunden till i stället för att lita på konfigurationen du minns. OpenVPN 2.6-handboken definierar --local som bindning till en adress och noterar att utelämnandet binder varje gränssnitt.

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

Läs kolumnen för den lokala adressen i stället för statuskolumnen. En rad som visar 10.42.7.24:1194 betyder att socketen är bunden till adressen du är på väg att ta bort, medan 0.0.0.0:1194 eller *:1194 betyder att daemonen följer gränssnittsändringen själv. Om adressen är bunden, redigera profilen och starta om enheten i stället för att skriva om den levande socketen för hand, och bekräfta sedan att tjänsten fortfarande når sina certifikat- och nyckelfiler.

Gå flytten i en ordning som håller dig nåbar

Ordningen spelar större roll än hastigheten här. Ta upp den trådbundna länken medan den trådlösa fortfarande fungerar, bekräfta den nya adressen och returvägen och pensionera sedan den trådlösa profilen. Den sekvensen håller en fungerande session öppen tills ersättningen är bevisad.

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

Det första kommandot svarar på om eth0 fick adressen du avsåg, och det andra skriver ut källadressen som kärnan skulle använda för ett mål utanför nätet, så kör det före och efter ändringen. Om den källan fortfarande är den trådlösa adressen är den trådbundna länken ännu inte den föredragna vägen och testet utifrån misslyckas av en anledning som inte har med OpenVPN att göra. Rätta routingpreferensen innan du rör vidarebefordran.

Med båda länkarna uppe kan Pi:n föredra den trådlösa standardrutten eftersom den installerades först eller eftersom den trådbundna länken har en högre metrik. På Bookworm är den stödda ratten ipv4.route-metric på anslutningen, och på Bullseye är motsvarigheten en gränssnittsspecifik metric-rad i dhcpcd.conf. Degradera den trådlösa länken i stället för att inaktivera den, så återställningsvägen förblir ett kommando bort.

Bevisa tunneln utifrån, inte från LAN:et

En VPN-anslutning som fungerar från soffan bevisar mindre än det verkar. Trafik inifrån LAN:et till den publika adressen passerar hairpin- eller reflektionsregler som routrar implementerar inkonsekvent, så ett godkänt LAN-test kan samexistera med en trasig väg utifrån. Använd en telefon på mobildata, eller vilken värd som helst utanför nätverket, för acceptanstestet. Behåll LAN-försöket som en separat valfri diagnostik.

Läs sedan loggen i den ordning paketen anländer. Ingenting alls betyder att handskakningen aldrig nådde Pi:n, så omdirigeringsmålet eller värdbrandväggen är fel. En handskakning som börjar och stannar pekar på nycklar, certifikat eller MTU. En session som slutförs och tappas betyder oftast returvägen eller en andra standardrutt, och klientens loggrad Initialization Sequence Completed berättar att tunneln själv kom upp.

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

Om ingenting syns i serverloggen medan klienten försöker igen, sluta läsa OpenVPN-konfiguration och gå tillbaka till omdirigeringsmålet. Avbildningen besvarar ankomstfrågan på sekunder, och inkommande paket utan svar snävar in problemet till rutten.

Behåll en återställning i ett steg och pensionera den trådlösa profilen

Låt den trådlösa profilen vara installerad tills den trådbundna lösningen har klarat en omstart. nmcli con show listar profilnamnen du kommer att behöva, och en raderad profil måste byggas upp från minnet i värsta tänkbara ögonblick. Anteckna gränssnittsnamnet, adressmetoden och metriken bredvid de andra fyra värdena. En återställning du kan skriva från en anteckning är värd mer än en du måste rekonstruera.

Att pensionera det trådlösa beroendet är en egenskapsändring i stället för en radering. Att sätta connection.autoconnect no behåller inloggningsuppgifterna och adresshistoriken intakta samtidigt som Pi:n hindras från att ansluta igen till ett nätverk du flyttat ifrån.

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

Innan du kallar jobbet klart, bekräfta fyra saker: omdirigeringsmålet matchar den trådbundna adressen, lyssnaren överlevde en omstart, en klient utifrån slutför en handskakning, och Pi:n svarar fortfarande på den trådbundna adressen efter en omstart. En omstart är det billigaste sättet att fånga en tilldelning som bara fanns i den körande kärnan. Om någon av de fyra misslyckas, ta upp den trådlösa profilen igen med sudo nmcli con up och jämför de antecknade värdena med de levande.