Cum muți un server VPN Raspberry Pi pe Ethernet

Trecerea Pi-ului de pe Wi-Fi pe un cablu pare o treabă de cinci minute, și rămâne așa doar dacă tratezi mutarea ca patru setări separate în loc de una singură. Numele punctului final pe care îl apelează clienții tăi poate rămâne exact același în timp ce adresa de sub el se schimbă. Ce se strică de fapt este un listener fixat pe adresa veche, o redirecționare de port încă îndreptată spre lease-ul wireless, sau o rută de retur care iese prin interfața pe care credeai că ai retras-o. Acest ghid ține deschisă o cale de recuperare la fiecare pas, așa că o tranziție eșuată costă doar o repornire.

Notează cele patru responsabilități înainte de a deconecta ceva

Patru setări decid dacă tranziția supraviețuiește: adresa Pi-ului, adresa de legare OpenVPN, ținta de redirecționare a routerului și calea pe care o iau răspunsurile. Notează toate patru înainte de a atinge cablul, pentru că odată ce lease-ul wireless dispare nu mai poți citi valorile vechi de pe mașină. Interfața cu cablu nu moștenește profilul wireless, iar pe Bookworm adresa trăiește în NetworkManager în timp ce Bullseye o păstrează în dhcpcd.conf. O rezervare care fixa adresa MAC wireless nu spune nimic despre eth0. Tratează adresa nouă ca o alocare nouă care are nevoie de propria dovadă.

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

Listenerul este al doilea responsabil. Dacă serviciul a fost pornit cu o adresă de legare specifică, socketul moare cu interfața veche; dacă leagă toate adresele, socketul supraviețuiește și regula routerului devine singurul lucru rămas de reparat.

Ținta de redirecționare și calea de retur sunt responsabilii pe care oamenii îi sar. O redirecționare care încă indică spre 10.42.7.24 trimite handshake-urile primite către o adresă pe care Pi-ul nu o mai are, așa că clienții expiră fără nicio linie de jurnal pe server. Calea de retur contează când ambele legături sunt scurt timp active, pentru că Pi-ul răspunde prin interfața pe care tabela de rutare o preferă, și nu este întotdeauna cea pe care a sosit pachetul. Interogarea de rută de mai jos arată ce sursă alege nucleul.

Citește socketul real înainte de a te încrede în adresa nouă

Fișierele de configurare descriu intenția și socketul descrie realitatea. Întreabă serviciul aflat în execuție la ce este legat în loc să te încrezi în configurația pe care o ții minte. Manualul OpenVPN 2.6 definește --local ca legare la o singură adresă și notează că omiterea lui leagă toate interfețele.

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

Citește coloana adresei locale în locul coloanei de stare. O linie care arată 10.42.7.24:1194 înseamnă că socketul este fixat pe adresa pe care ești pe punctul de a o elimina, în timp ce 0.0.0.0:1194 sau *:1194 înseamnă că daemonul va urma singur schimbarea de interfață. Dacă adresa este fixată, editează profilul și repornește unitatea în loc să rescrii manual socketul activ, apoi confirmă că serviciul ajunge în continuare la fișierele sale de certificat și cheie.

Parcurge mutarea într-o ordine care te ține accesibil

Ordinea contează aici mai mult decât viteza. Ridică legătura cu cablu în timp ce cea wireless încă funcționează, confirmă adresa nouă și calea de retur, apoi retrage profilul wireless. Această secvență ține deschisă o sesiune funcțională până când înlocuitorul este dovedit.

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

Prima comandă răspunde dacă eth0 a primit adresa pe care o intenționai, iar a doua afișează adresa sursă pe care nucleul ar folosi-o pentru o destinație exterioară, așa că ruleaz-o înainte și după schimbare. Dacă acea sursă este încă adresa wireless, legătura cu cablu nu este încă calea preferată și testul din exterior va eșua dintr-un motiv care nu are nimic de-a face cu OpenVPN. Corectează preferința de rutare înainte de a atinge redirecționarea.

Cu ambele legături active, Pi-ul poate prefera ruta implicită wireless pentru că a fost instalată prima sau pentru că legătura cu cablu are o metrică mai mare. Pe Bookworm setarea acceptată este ipv4.route-metric pe conexiune, iar pe Bullseye echivalentul este o linie metric specifică interfeței în dhcpcd.conf. Retrogradează legătura wireless în loc să o dezactivezi, ca calea de revenire să rămână la o comandă distanță.

Dovedește tunelul din exterior, nu din LAN

O conexiune VPN care funcționează de pe canapea dovedește mai puțin decât pare. Traficul din interiorul LAN-ului către adresa publică trece prin reguli hairpin sau de reflexie pe care routerele le implementează inconsecvent, așa că un test LAN reușit poate coexista cu o cale exterioară ruptă. Folosește un telefon pe date mobile, sau orice gazdă din afara rețelei, pentru testul de acceptare. Păstrează încercarea LAN ca diagnostic opțional separat.

Apoi citește jurnalul în ordinea în care sosesc pachetele. Nimic deloc înseamnă că handshake-ul nu a ajuns niciodată la Pi, deci ținta de redirecționare sau firewallul gazdei este greșit. Un handshake care începe și se blochează indică chei, certificate sau MTU. O sesiune care se completează și cade înseamnă de obicei calea de retur sau o a doua rută implicită, iar linia de jurnal a clientului Initialization Sequence Completed îți spune că tunelul în sine a urcat.

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

Dacă în jurnalul serverului nu apare nimic în timp ce clientul reîncearcă, oprește citirea configurației OpenVPN și întoarce-te la ținta de redirecționare. Captura răspunde la întrebarea sosirii în câteva secunde, iar pachetele primite fără răspuns restrâng problema la rută.

Păstrează o revenire într-un singur pas și retrage profilul wireless

Lasă profilul wireless instalat până când aranjamentul cu cablu a trecut de o repornire. nmcli con show listează numele de profil de care vei avea nevoie, iar un profil șters trebuie reconstruit din memorie în cel mai rău moment. Notează numele interfeței, metoda de adresare și metrica lângă celelalte patru valori. O revenire pe care o poți tasta dintr-o notă valorează mai mult decât una pe care trebuie să o reconstruiești.

Retragerea dependenței wireless este o schimbare de proprietate în loc de o ștergere. Setând connection.autoconnect no se păstrează intacte acreditările și istoricul adreselor în timp ce Pi-ul este împiedicat să se reconecteze la o rețea de la care ai plecat.

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

Înainte de a declara treaba terminată, confirmă patru lucruri: ținta de redirecționare corespunde adresei cu cablu, listenerul a supraviețuit unei reporniri, un client din exterior finalizează un handshake, iar Pi-ul răspunde în continuare pe adresa cu cablu după o repornire. O repornire este cea mai ieftină modalitate de a prinde o alocare care exista doar în nucleul aflat în execuție. Dacă oricare dintre cele patru eșuează, ridică din nou profilul wireless cu sudo nmcli con up și compară valorile notate cu cele active.