Paano ilipat ang Raspberry Pi VPN server sa Ethernet

Ang paglilipat ng Pi mula Wi-Fi papuntang kable ay mukhang limang minutong trabaho, at mananatili lamang itong ganoon kung ituturing mo ang paglipat bilang apat na hiwalay na setting sa halip na isa. Ang pangalan ng endpoint na tinatawagan ng iyong mga kliyente ay maaaring manatiling eksaktong pareho habang nagbabago ang address sa ilalim nito. Ang tunay na nasisira ay isang listener na nakakabit sa lumang address, isang port forwarding na nakaturo pa rin sa wireless lease, o isang daan ng pagbalik na lumalabas sa interface na akala mo ay nairetira mo na. Ang gabay na ito ay nagpapanatiling bukas ang daan ng pagbawi sa bawat hakbang, kaya ang isang nabigong paglilipat ay nagkakahalaga lamang ng isang restart.

Itala ang apat na may-ari bago mo i-unplug ang anuman

Apat na setting ang nagpapasya kung mabubuhay ang paglilipat: ang address ng Pi, ang address ng binding OpenVPN, ang target ng redirect ng router at ang daan na tinatahak ng mga sagot. Itala ang lahat ng apat bago mo hawakan ang kable, dahil kapag nawala ang wireless lease ay hindi mo na mababasa ang lumang mga halaga mula sa makina. Ang interface ng kable ay hindi nagmamana ng wireless profile, at sa Bookworm ang address ay nakatira sa NetworkManager habang ang Bullseye ay nagtatago nito sa dhcpcd.conf. Ang reserbasyon na nagpin sa wireless MAC address ay walang sinasabi tungkol sa eth0. Ituring ang bagong address bilang bagong pagtatalaga na nangangailangan ng sarili nitong patunay.

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

Ang listener ang pangalawang may-ari. Kung ang serbisyo ay sinimulan gamit ang isang partikular na address ng binding, namamatay ang socket kasama ng lumang interface; kung binibigkis nito ang lahat ng address, nabubuhay ang socket at ang tuntunin ng router ang natitirang tanging bagay na dapat ayusin.

Ang target ng redirect at ang daan ng pagbalik ang mga may-aring nilalaktawan ng mga tao. Ang forwarding na nakaturo pa rin sa 10.42.7.24 ay nagpapadala ng mga dumarating na handshake sa address na wala na ang Pi, kaya nag-time out ang mga kliyente nang walang kahit isang linya ng log sa panig ng server. Mahalaga ang daan ng pagbalik kapag ang dalawang link ay panandaliang aktibo, dahil sumasagot ang Pi mula sa interface na pinipili ng routing table, at hindi iyon palaging ang interface kung saan dumating ang packet. Ipinapakita ng paghahanap ng ruta sa ibaba kung aling pinagmulan ang pinipili ng kernel.

Basahin ang tunay na socket bago mo pagtiwalaan ang bagong address

Inilalarawan ng mga configuration file ang layunin at ang socket ang inilalarawan ay ang realidad. Tanungin ang tumatakbong serbisyo kung ano ang nakakabit dito sa halip na pagtiwalaan ang configuration na natatandaan mo. Ang manwal ng OpenVPN 2.6 ay tumutukoy sa --local bilang pagkakabit sa isang address at binabanggit na ang pag-iwan dito ay nagbibigkis sa bawat interface.

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

Basahin ang column ng lokal na address sa halip na ang column ng estado. Ang linyang nagpapakita ng 10.42.7.24:1194 ay nangangahulugang ang socket ay nakapin sa address na malapit mo nang tanggalin, samantalang ang 0.0.0.0:1194 o *:1194 ay nangangahulugang susundan ng daemon ang pagbabago ng interface nang mag-isa. Kung nakapin ang address, i-edit ang profile at i-restart ang unit sa halip na manu-manong isulat muli ang live na socket, pagkatapos ay kumpirmahin na naaabot pa rin ng serbisyo ang mga file ng certificate at key nito.

Gawin ang paglipat sa pagkakasunod-sunod na nagpapanatili sa iyong maabot

Mas mahalaga ang pagkakasunod-sunod kaysa bilis dito. Itaas ang kable na link habang gumagana pa ang wireless, kumpirmahin ang bagong address at ang daan ng pagbalik, at pagkatapos lamang iretiro ang wireless profile. Ang pagkakasunod-sunod na iyon ay nagpapanatiling bukas ang gumaganang session hanggang sa mapatunayan ang kapalit.

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

Ang unang utos ay sumasagot kung eth0 ay nakatanggap ng address na nilayon mo, at ang pangalawa ay naglilimbag ng source address na gagamitin ng kernel para sa panlabas na destinasyon, kaya patakbuhin ito bago at pagkatapos ng pagbabago. Kung ang pinagmulang iyon ay wireless address pa rin, ang kable na link ay hindi pa ang gustong daan at ang pagsubok mula sa labas ay mabibigo dahil sa dahilang walang kinalaman sa OpenVPN. Ayusin ang kagustuhan sa routing bago mo hawakan ang forwarding.

Kapag aktibo ang dalawang link, maaaring mas gusto ng Pi ang wireless na default na ruta dahil ito ang unang na-install o dahil mas mataas ang metric ng kable na link. Sa Bookworm ang sinusuportahang setting ay ipv4.route-metric sa koneksyon, at sa Bullseye ang katumbas ay isang linyang metric na partikular sa interface sa dhcpcd.conf. Ibaba ang priyoridad ng wireless na link sa halip na patayin ito, para manatiling isang utos ang layo ng daan ng pag-urong.

Patunayan ang tunnel mula sa labas, hindi mula sa LAN

Ang VPN koneksyon na gumagana mula sa sopa ay nagpapatunay ng mas kaunti kaysa sa tila. Ang trapiko mula sa loob ng LAN patungo sa pampublikong address ay dumadaan sa mga tuntunin ng hairpin o reflection na ipinapatupad ng mga router nang hindi pantay-pantay, kaya ang isang pumapasang LAN test ay maaaring mabuhay kasama ng sirang panlabas na daan. Gumamit ng telepono na may cellular data, o anumang host sa labas ng network, para sa acceptance test. Panatilihin ang LAN na pagtatangka bilang hiwalay na opsyonal na diagnostic.

Pagkatapos ay basahin ang log sa pagkakasunod-sunod ng pagdating ng mga packet. Wala talaga ay nangangahulugang hindi kailanman naabot ng handshake ang Pi, kaya mali ang target ng redirect o ang firewall ng host. Ang handshake na nagsisimula at natigil ay tumutukoy sa mga key, certificate o MTU. Ang session na natapos at bumagsak ay karaniwang nangangahulugang ang daan ng pagbalik o pangalawang default na ruta, at ang linya ng log ng kliyente Initialization Sequence Completed ay nagsasabi sa iyo na ang tunnel mismo ay umangat.

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

Kung walang lumalabas sa log ng server habang sinusubukan muli ng kliyente, itigil ang pagbabasa ng OpenVPN configuration at bumalik sa target ng redirect. Sinasagot ng capture ang tanong ng pagdating sa loob ng ilang segundo, at ang mga papasok na packet na walang sagot ay nagpapakitid ng problema sa ruta.

Panatilihin ang one-step na pag-urong at iretiro ang wireless profile

Iwanang naka-install ang wireless profile hanggang makalampas ang kable na kaayusan sa isang restart. nmcli con show ang naglilista ng mga pangalan ng profile na kakailanganin mo, at ang isang tinanggal na profile ay kailangang itayong muli mula sa memorya sa pinakamasamang sandali. Itala ang pangalan ng interface, ang paraan ng address at ang metric sa tabi ng iba pang apat na halaga. Ang pag-urong na maaari mong i-type mula sa isang nota ay mas mahalaga kaysa sa kailangan mong itayong muli.

Ang pagretiro sa wireless dependency ay pagbabago ng katangian at hindi pagbura. Sa pagtatakda ng connection.autoconnect no nananatiling buo ang mga kredensyal at kasaysayan ng address habang pinipigilan ang Pi na muling kumonekta sa network na iniwan mo.

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

Bago mo ideklarang tapos ang trabaho, kumpirmahin ang apat na bagay: tumutugma ang target ng redirect sa kable na address, nakaligtas ang listener sa isang restart, natatapos ng kliyente mula sa labas ang handshake, at sumasagot pa rin ang Pi sa kable na address pagkatapos ng restart. Ang restart ang pinakamurang paraan upang mahuli ang isang pagtatalagang umiiral lamang sa tumatakbong kernel. Kung mabibigo ang alinman sa apat, itaas muli ang wireless profile gamit ang sudo nmcli con up at ihambing ang mga naitalang halaga sa mga aktibo.