Sådan flytter du en Raspberry Pi VPN-server til Ethernet
Flyt en Raspberry Pi VPN-server fra Wi-Fi til Ethernet uden at ændre endepunktsnavn, listener-binding, portforwarding eller én-trins rollback-sti.
At skifte Pi'en fra Wi-Fi til et kabel ser ud som en fem-minutters opgave, og det forbliver det kun, hvis du behandler flytningen som fire separate indstillinger i stedet for én. Det endepunktsnavn, dine klienter ringer op til, kan forblive præcis det samme, mens adressen under det ændrer sig. Det, der faktisk brækker, er en listener, der er bundet til den gamle adresse, en portforwarding, der stadig peger på den trådløse lease, eller en returrute, der forlader gennem den grænseflade, du troede du havde pensioneret. Denne gennemgang holder en gendannelsessti åben ved hvert trin, så en mislykket overgang kun koster en genstart.
Notér de fire ansvarlige, før du trækker noget ud
Fire indstillinger afgør, om overgangen overlever: Pi-adressen, OpenVPN-bindeadressen, routerens omdirigeringsmål og den vej, svar tager. Skriv alle fire ned, før du rører kablet, for når den trådløse lease forsvinder, kan du ikke læse de gamle værdier ud af maskinen. Den kablede grænseflade arver ikke det trådløse profil, og på Bookworm ligger adressen i NetworkManager, mens Bullseye beholder den i dhcpcd.conf. En reservation, der bandt den trådløse MAC-adresse, siger intet om eth0. Behandl den nye adresse som en ny tildeling, der har brug for sit 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
Listeneren er den anden ansvarlige. Hvis tjenesten blev startet med en bestemt bindeadresse, dør socket'en med den gamle grænseflade; hvis den binder alle adresser, overlever socket'en, og routerreglen er det eneste, der er tilbage at rette.
Omdirigeringsmålet og returvejen er de ansvarlige, folk springer over. En forwarding, der stadig peger på 10.42.7.24, sender ankommende handshakes til en adresse, som Pi'en ikke længere har, så klienter timer ud uden nogen server-side loglinje overhovedet. Returvejen betyder noget, når begge links kortvarigt er oppe, fordi Pi'en svarer fra den grænseflade, routingtabellen foretrækker, og det er ikke altid den, pakken ankom på. Ruteopslaget nedenfor viser, hvilken kilde kernen vælger.
Læs den faktiske socket, før du stoler på den nye adresse
Konfigurationsfiler beskriver hensigten, og socket'en beskriver virkeligheden. Spørg den kørende tjeneste, hvad den er bundet til, i stedet for at stole på den konfiguration, du husker. OpenVPN 2.6-manualen definerer --local som binding til én adresse og bemærker, at udeladelsen binder hver grænseflade.
sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'
Læs kolonnen med den lokale adresse i stedet for tilstandskolonnen. En linje, der viser 10.42.7.24:1194 betyder, at socket'en er bundet til den adresse, du er ved at fjerne, mens 0.0.0.0:1194 eller *:1194 betyder, at daemonen selv følger grænsefladeændringen. Hvis adressen er bundet, rediger profilen og genstart enheden i stedet for at omskrive den kørende socket i hånden, og bekræft derefter, at tjenesten stadig når sine certifikat- og nøglefiler.
Gå flytningen i en rækkefølge, der holder dig nåbar
Rækkefølgen betyder mere end hastigheden her. Bring det kablede link op, mens det trådløse stadig virker, bekræft den nye adresse og returvejen, og pensionér derefter det trådløse profil. Den sekvens holder en fungerende session åben, indtil 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 kommando svarer på, om eth0 fik den adresse, du havde til hensigt, og den anden udskriver kildeadressen, som kernen ville bruge til en destination uden for netværket, så kør den før og efter ændringen. Hvis den kilde stadig er den trådløse adresse, er det kablede link endnu ikke den foretrukne vej, og testen udefra vil fejle af en grund, der intet har med OpenVPN at gøre. Ret routingpræferencen, før du rører forwarding.
Med begge links oppe foretrækker Pi'en måske den trådløse standardrute, fordi den blev installeret først, eller fordi det kablede link har en højere metrik. På Bookworm er den understøttede knap ipv4.route-metric på forbindelsen, og på Bullseye er ækvivalenten en grænsefladespecifik metric-linje i dhcpcd.conf. Degradér det trådløse link i stedet for at deaktivere det, så rollback-stien forbliver én kommando væk.
Bevis tunnelen udefra, ikke fra LAN'et
En VPN-forbindelse, der virker fra sofaen, beviser mindre, end det ser ud til. Trafik fra inde i LAN'et til den offentlige adresse går gennem hairpin- eller refleksionsregler, som routere implementerer inkonsekvent, så en bestået LAN-test kan eksistere sammen med en brudt udvendig sti. Brug en telefon på mobildata eller en hvilken som helst host uden for netværket til accepttesten. Behold LAN-forsøget som en separat valgfri diagnostik.
Læs derefter loggen i den rækkefølge, pakkerne ankommer. Ingenting overhovedet betyder, at handshaken aldrig nåede Pi'en, så omdirigeringsmålet eller host-firewallen er forkert. En handshake, der starter og går i stå, peger på nøgler, certifikater eller MTU. En session, der gennemføres og dropper, betyder normalt returvejen eller en anden standardrute, og klientens loglinje Initialization Sequence Completed fortæller dig, at tunnelen selv kom op.
sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20
Hvis der ikke vises noget i serverloggen, mens klienten prøver igen, stop med at læse OpenVPN-konfiguration og gå tilbage til omdirigeringsmålet. Optagelsen besvarer ankomstspørgsmålet på sekunder, og indgående pakker uden svar indsnævrer problemet til ruten.
Behold en ét-trins rollback og pensionér det trådløse profil
Lad det trådløse profil være installeret, indtil den kablede opsætning har overstået en genstart. nmcli con show viser de profilnavne, du får brug for, og en slettet profil skal genopbygges fra hukommelsen på det værst tænkelige tidspunkt. Notér grænsefladenavnet, adressemetoden og metrikken ved siden af de fire andre værdier. En rollback, du kan taste fra en note, er mere værd end en, du skal rekonstruere.
At pensionere den trådløse afhængighed er en egenskabsændring i stedet for en sletning. At sætte connection.autoconnect no holder legitimationsoplysningerne og adressehistorikken intakte, mens Pi'en forhindres i at genoprette forbindelsen til et netværk, du flyttede væk fra.
nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no
Før du kalder opgaven færdig, bekræft fire ting: omdirigeringsmålet matcher den kablede adresse, listeneren overlevede en genstart, en klient udefra gennemfører en handshake, og Pi'en svarer stadig på den kablede adresse efter en genstart. En genstart er den billigste måde at fange en tildeling, der kun eksisterede i den kørende kerne. Hvis en af de fire fejler, bring det trådløse profil op igen med sudo nmcli con up og sammenlign de noterede værdier med de kørende.