Slik flytter du en Raspberry Pi VPN-server til Ethernet

Å bytte Pi-en fra Wi-Fi til en kabel ser ut som en femminuttersjobb, og det forblir det bare hvis du behandler flyttingen som fire separate innstillinger i stedet for én. Endepunktnavnet klientene dine ringer kan forbli nøyaktig det samme mens adressen under det endres. Det som faktisk bryter, er en lytter som er bundet til den gamle adressen, en portvideresending som fortsatt peker på den trådløse leasen, eller en returvei som forlater gjennom grensesnittet du trodde du hadde pensjonert. Denne gjennomgangen holder en gjenopprettingsvei åpen ved hvert steg, slik at en mislykket overgang bare koster en omstart.

Skriv ned de fire ansvarlige før du kobler fra noe

Fire innstillinger avgjør om overgangen overlever: Pi-adressen, OpenVPN-bindeadressen, omdirigeringsmålet til ruteren og veien svarene tar. Skriv ned alle fire før du rører kabelen, for når den trådløse leasen forsvinner, kan du ikke lese de gamle verdiene av maskinen. Det kablede grensesnittet arver ikke den trådløse profilen, og på Bookworm bor adressen i NetworkManager mens Bullseye beholder den i dhcpcd.conf. En reservasjon som bandt den trådløse MAC-adressen, sier ingenting om eth0. Behandle den nye adressen som en ny tildeling som trenger 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

Lytteren er den andre ansvarlige. Hvis tjenesten ble startet med en bestemt bindeadresse, dør socketen med det gamle grensesnittet; hvis den binder alle adresser, overlever socketen, og ruterregelen blir det eneste som gjenstår å rette.

Omdirigeringsmålet og returveien er de ansvarlige folk hopper over. En videresending som fortsatt peker på 10.42.7.24, sender ankommende håndtrykk til en adresse Pi-en ikke lenger har, så klienter timer ut uten noen serverlogglinje i det hele tatt. Returveien betyr noe når begge lenkene er oppe en kort stund, fordi Pi-en svarer fra grensesnittet rutetabellen foretrekker, og det er ikke alltid det pakken ankom på. Ruteoppslaget nedenfor viser hvilken kilde kjernen velger.

Les den faktiske socketen før du stoler på den nye adressen

Konfigurasjonsfiler beskriver intensjonen, og socketen beskriver virkeligheten. Spør den kjørende tjenesten hva den er bundet til i stedet for å stole på konfigurasjonen du husker. OpenVPN 2.6-håndboken definerer --local som binding til én adresse og bemerker at utelatelsen binder hvert grensesnitt.

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

Les kolonnen for den lokale adressen i stedet for tilstandskolonnen. En linje som viser 10.42.7.24:1194 betyr at socketen er bundet til adressen du er i ferd med å fjerne, mens 0.0.0.0:1194 eller *:1194 betyr at daemonen følger grensesnittendringen selv. Hvis adressen er bundet, rediger profilen og start enheten på nytt i stedet for å skrive om den levende socketen for hånd, og bekreft deretter at tjenesten fortsatt når sertifikat- og nøkkelfilene sine.

Gå flyttingen i en rekkefølge som holder deg nåbar

Rekkefølgen betyr mer enn hastigheten her. Ta opp den kablede lenken mens den trådløse fortsatt virker, bekreft den nye adressen og returveien, og pensjoner deretter den trådløse profilen. Den sekvensen holder en fungerende økt åpen til erstatningen er bevist.

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

Den første kommandoen svarer på om eth0 fikk adressen du hadde tenkt, og den andre skriver ut kildeadressen kjernen ville brukt for en destinasjon utenfor nettverket, så kjør den før og etter endringen. Hvis den kilden fortsatt er den trådløse adressen, er den kablede lenken ennå ikke den foretrukne veien, og testen utenfra vil mislykkes av en grunn som ikke har noe med OpenVPN å gjøre. Rett rutingpreferansen før du rører videresendingen.

Med begge lenkene oppe kan Pi-en foretrekke den trådløse standardruten fordi den ble installert først, eller fordi den kablede lenken har en høyere metrikk. På Bookworm er den støttede knotten ipv4.route-metric på tilkoblingen, og på Bullseye er ekvivalenten en grensesnittspesifikk metric-linje i dhcpcd.conf. Degrader den trådløse lenken i stedet for å deaktivere den, slik at tilbakestillingsveien forblir én kommando unna.

Bevis tunnelen utenfra, ikke fra LAN-et

En VPN-tilkobling som virker fra sofaen, beviser mindre enn det ser ut som. Trafikk fra inne i LAN-et til den offentlige adressen går gjennom hairpin- eller refleksjonsregler som rutere implementerer inkonsekvent, så en bestått LAN-test kan eksistere sammen med en brutt vei utenfra. Bruk en telefon på mobildata, eller en hvilken som helst vert utenfor nettverket, til aksepttesten. Behold LAN-forsøket som en separat valgfri diagnostikk.

Les deretter loggen i den rekkefølgen pakkene ankommer. Ingenting i det hele tatt betyr at håndtrykket aldri nådde Pi-en, så omdirigeringsmålet eller vertsbrannmuren er feil. Et håndtrykk som starter og stopper, peker på nøkler, sertifikater eller MTU. En økt som fullføres og droppes, betyr vanligvis returveien eller en andre standardrute, og klientens logglinje Initialization Sequence Completed forteller deg at tunnelen selv kom opp.

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

Hvis ingenting vises i serverloggen mens klienten prøver på nytt, slutt å lese OpenVPN-konfigurasjon og gå tilbake til omdirigeringsmålet. Opptaket besvarer ankomstspørsmålet på sekunder, og innkommende pakker uten svar snevrer problemet inn til ruten.

Behold en ett-trinns tilbakestilling og pensjoner den trådløse profilen

La den trådløse profilen være installert til den kablede ordningen har overlevd en omstart. nmcli con show viser profilnavnene du vil trenge, og en slettet profil må bygges opp fra hukommelsen i det verst tenkelige øyeblikket. Skriv ned grensesnittnavnet, adressemetoden og metrikken ved siden av de fire andre verdiene. En tilbakestilling du kan skrive fra et notat, er mer verdt enn en du må rekonstruere.

Å pensjonere den trådløse avhengigheten er en egenskapsendring i stedet for en sletting. Å sette connection.autoconnect no beholder påloggingsinformasjonen og adressehistorikken intakt mens Pi-en hindres i å koble seg til et nettverk du flyttet bort fra.

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

Før du kaller jobben ferdig, bekreft fire ting: omdirigeringsmålet samsvarer med den kablede adressen, lytteren overlevde en omstart, en klient utenfra fullfører et håndtrykk, og Pi-en svarer fortsatt på den kablede adressen etter en omstart. En omstart er den billigste måten å fange en tildeling som bare fantes i den kjørende kjernen. Hvis noen av de fire mislykkes, ta den trådløse profilen opp igjen med sudo nmcli con up og sammenlign de nedskrevne verdiene med de levende.