Přepnutí Pi z Wi-Fi na kabel vypadá jako pětiminutová práce a zůstane jí jen tehdy, když přesun pojmete jako čtyři samostatná nastavení místo jednoho. Název koncového bodu, na který se klienti připojují, může zůstat přesně stejný, zatímco adresa pod ním se mění. Co se doopravdy rozbije, je listener připoutaný ke staré adrese, přesměrování portu stále namířené na bezdrátový lease, nebo zpáteční trasa, která vychází přes rozhraní, jež jste považovali za vyřazené. Tento návod drží cestu obnovy otevřenou v každém kroku, takže neúspěšné přepnutí stojí jen restart.

Zapište si čtyři odpovědné dříve, než cokoli odpojíte

Čtyři nastavení rozhodují, zda přechod přežije: adresa Pi, adresa navázání OpenVPN, cíl přesměrování routeru a cesta, kterou se vydávají odpovědi. Zapište všechny čtyři, než se dotknete kabelu, protože jakmile bezdrátový lease zmizí, už staré hodnoty z počítače nepřečtete. Kabelové rozhraní nedědí bezdrátový profil a na Bookwormu adresa žije v NetworkManageru, zatímco Bullseye ji drží v dhcpcd.conf. Rezervace, která připínala bezdrátovou MAC adresu, neříká nic o eth0. Berte novou adresu jako nové přiřazení, které potřebuje vlastní důkaz.

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

Listener je druhý odpovědný. Pokud byla služba spuštěna s konkrétní adresou navázání, socket umírá se starým rozhraním; pokud navazuje všechny adresy, socket přežije a pravidlo routeru se stane jedinou věcí, kterou zbývá opravit.

Cíl přesměrování a zpáteční trasa jsou odpovědní, které lidé přeskakují. Přesměrování, které stále ukazuje na 10.42.7.24, posílá přicházející handshaky na adresu, kterou Pi už nemá, takže klienti vyprší bez jediného řádku logu na serveru. Zpáteční trasa hraje roli, když jsou obě spojení krátce aktivní, protože Pi odpovídá přes rozhraní, které preferuje směrovací tabulka, a to není vždy to, na kterém paket dorazil. Vyhledání trasy níže ukazuje, jaký zdroj jádro zvolí.

Přečtěte skutečný socket, než nové adrese uvěříte

Konfigurační soubory popisují záměr a socket popisuje realitu. Zeptejte se běžící služby, k čemu je navázaná, místo abyste věřili konfiguraci, kterou si pamatujete. Příručka OpenVPN 2.6 definuje --local jako navázání na jednu adresu a poznamenává, že vynechání navazuje každé rozhraní.

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

Čtěte sloupec místní adresy místo sloupce stavu. Řádek zobrazující 10.42.7.24:1194 znamená, že socket je připoután k adrese, kterou se chystáte odstranit, zatímco 0.0.0.0:1194 nebo *:1194 znamená, že démon změnu rozhraní sleduje sám. Pokud je adresa připoutaná, upravte profil a restartujte jednotku místo ručního přepisu živého socketu, a potom ověřte, že služba stále dosáhne na své soubory certifikátu a klíče.

Projděte přesun v pořadí, které vás udrží dostupné

Pořadí je tu důležitější než rychlost. Zvedněte kabelové spojení, dokud bezdrátové ještě funguje, potvrďte novou adresu a zpáteční trasu a poté vyřaďte bezdrátový profil. Tato posloupnost drží funkční relaci otevřenou, dokud není náhrada prokázaná.

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

První příkaz odpovídá na to, zda eth0 dostal adresu, kterou jste zamýšleli, a druhý vypisuje zdrojovou adresu, kterou by jádro použilo pro cíl mimo síť, takže ho spusťte před změnou a po ní. Pokud je tím zdrojem stále bezdrátová adresa, kabelové spojení zatím není preferovanou cestou a test zvenčí selže z důvodu, který s OpenVPN nemá nic společného. Opravte preferenci směrování, než se dotknete přesměrování.

Když jsou obě spojení aktivní, Pi může preferovat výchozí bezdrátovou trasu, protože byla nainstalována první nebo protože kabelové spojení má vyšší metriku. Na Bookwormu je podporovaným knoflíkem ipv4.route-metric na připojení, a na Bullseye je ekvivalentem řádek metric specifický pro rozhraní v dhcpcd.conf. Degradujte bezdrátové spojení místo jeho vypnutí, aby cesta návratu zůstala jeden příkaz daleko.

Dokažte tunel zvenčí, ne z LAN

Připojení VPN, které funguje z gauče, dokazuje méně, než se zdá. Provoz zevnitř LAN na veřejnou adresu prochází pravidly hairpin nebo odrazu, která routery zavádějí nekonzistentně, takže úspěšný test v LAN může koexistovat s rozbitou cestou zvenčí. Pro akceptační test použijte telefon na mobilních datech nebo jakéhokoli hostitele mimo síť. Pokus v LAN si nechte jako samostatnou volitelnou diagnostiku.

Potom čtěte log v pořadí, v jakém pakety přicházejí. Naprosto nic znamená, že handshake se k Pi nikdy nedostal, takže cíl přesměrování nebo firewall hostitele je špatně. Handshake, který začne a zasekne se, ukazuje na klíče, certifikáty nebo MTU. Relace, která se dokončí a spadne, obvykle znamená zpáteční trasu nebo druhou výchozí trasu, a řádek logu klienta Initialization Sequence Completed vám říká, že tunel sám vstal.

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

Pokud se v logu serveru nic neobjeví, zatímco klient to zkouší znovu, přestaňte číst konfiguraci OpenVPN a vraťte se k cíli přesměrování. Zachycení odpoví na otázku doručení během sekund a příchozí pakety bez odpovědi zúží problém na trasu.

Zachovejte návrat v jednom kroku a vyřaďte bezdrátový profil

Nechte bezdrátový profil nainstalovaný, dokud kabelové uspořádání nepřejde restartem. nmcli con show vypisuje názvy profilů, které budete potřebovat, a smazaný profil je nutné v nejhorší chvíli zrekonstruovat z paměti. Zapište název rozhraní, metodu adresování a metriku vedle ostatních čtyř hodnot. Návrat, který můžete napsat z poznámky, má větší cenu než ten, který musíte rekonstruovat.

Vyřazení bezdrátové závislosti je změna vlastnosti, ne smazání. Nastavením connection.autoconnect no zůstanou přihlašovací údaje a historie adres nedotčené a Pi se přestane znovu připojovat k síti, ze které jste odešli.

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

Než práci prohlásíte za hotovou, potvrďte čtyři věci: cíl přesměrování odpovídá kabelové adrese, listener přežil restart, klient zvenčí dokončí handshake a Pi po restartu stále odpovídá na kabelové adrese. Restart je nejlevnější způsob, jak zachytit přiřazení, které existovalo jen v běžícím jádru. Pokud některá ze čtyř selže, zvedněte bezdrátový profil zpět pomocí sudo nmcli con up a porovnejte zaznamenané hodnoty s aktivními.

Související články