Како да преместите VPN сервер Raspberry Pi на Ethernet
Преместете VPN сервер Raspberry Pi од Wi-Fi на Ethernet без да го смените името на крајната точка, врзувањето на слушачот, проследувањето на порта или патеката за враќање во еден чекор.
Префрлањето на Pi од Wi-Fi на кабел изгледа како работа од пет минути и останува така само ако преместувањето го третирате како четири одделни поставки наместо една. Името на крајната точка што вашите клиенти ја повикуваат може да остане сосема исто додека адресата под него се менува. Она што навистина се крши е слушач закачен за старата адреса, проследување на порта и понатаму насочено кон безжичниот lease, или повратна рута што излегува низ интерфејсот што мислевте дека сте го пензионирале. Ова упатство држи патека за опоравување отворена на секој чекор, така што неуспешно префрлање чини само рестарт.
Запишете ги четирите одговорни пред да исклучите било што
Четири поставки одлучуваат дали префрлањето ќе преживее: адресата на Pi, адресата на врзување OpenVPN, целта за пренасочување на рутерот и патеката што ја преземаат одговорите. Запишете ги сите четири пред да го допрете кабелот, зашто кога безжичниот lease ќе исчезне, старите вредности повеќе не можете да ги прочитате од машината. Кабелскиот интерфејс не го наследува безжичниот профил, а на Bookworm адресата живее во NetworkManager додека Bullseye ја држи во dhcpcd.conf. Резервација што ја закачила безжичната MAC адреса не кажува ништо за eth0. Третирајте ја новата адреса како нова додела на која ѝ треба сопствен доказ.
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
Слушачот е вториот одговорен. Ако услугата е стартувана со конкретна адреса на врзување, сокетот умира со стариот интерфејс; ако ги врзува сите адреси, сокетот преживува и правилото на рутерот станува единственото што останува да се поправи.
Целта за пренасочување и повратната рута се одговорните што луѓето ги прескокнуваат. Проследување што и понатаму покажува на 10.42.7.24 испраќа дојдовни ракувања на адреса што Pi повеќе ја нема, па клиентите истекуваат без ниту една линија во дневникот на серверот. Повратната рута е важна кога двете врски се накратко активни, зашто Pi одговара низ интерфејсот што табелата за рутирање го преферира, а тоа не е секогаш оној на кој стигнал пакетот. Пребарувањето на рута подолу покажува кој извор го избира јадрото.
Прочитајте го вистинскиот сокет пред да ѝ верувате на новата адреса
Конфигурациските датотеки опишуваат намера, а сокетот ја опишува реалноста. Прашајте ја услугата што работи кон што е врзана наместо да ѝ верувате на конфигурацијата што ја паметите. Прирачникот OpenVPN 2.6 дефинира --local како врзување за една адреса и забележува дека неговото изостанување ги врзува сите интерфејси.
sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'
Читајте ја колоната на локалната адреса наместо колоната на состојбата. Ред што покажува 10.42.7.24:1194 значи дека сокетот е закачен за адресата што штотуку ќе ја отстраните, додека 0.0.0.0:1194 или *:1194 значи дека демонот сам ќе ја следи промената на интерфејсот. Ако адресата е закачена, уредете го профилот и рестартирајте ја единицата наместо рачно да го препишувате живиот сокет, а потоа потврдете дека услугата и понатаму ги достигнува своите датотеки за сертификат и клуч.
Поминете го преместувањето во ред што ве држи достапни
Редот е тука поважен од брзината. Подигнете ја кабелската врска додека безжичната и понатаму работи, потврдете ја новата адреса и повратната рута, и дури потоа пензионирајте го безжичниот профил. Таа низа држи работна сесија отворена додека замената не биде докажана.
ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"
Првата команда одговара дали eth0 ја доби адресата што ја намисливте, а втората ја печати изворната адреса што јадрото би ја користело за надворешна дестинација, па стартувајте ја пред и по промената. Ако тој извор е и понатаму безжичната адреса, кабелската врска и понатаму не е преферираната патека и тестот однадвор ќе падне поради причина што нема никаква врска со OpenVPN. Поправете ја преференцијата за рутирање пред да го допрете проследувањето.
Кога двете врски се активни, Pi може да преферира безжичната стандардна рута зашто е прва инсталирана или зашто кабелската врска носи повисока метрика. На Bookworm поддржаната поставка е ipv4.route-metric на конекцијата, а на Bullseye еквивалентот е интерфејсна линија metric во dhcpcd.conf. Деградирајте ја безжичната врска наместо да ја исклучите, за патеката за враќање да остане една команда далеку.
Докажете го тунелот однадвор, не од LAN
VPN конекција што работи од каучот докажува помалку отколку што изгледа. Сообраќајот од внатрешноста на LAN кон јавната адреса поминува низ правила за hairpin или одраз што рутерите ги спроведуваат недоследно, па успешен LAN тест може да коегзистира со расипана надворешна патека. Користете телефон на мобилни податоци, или кој било хост надвор од мрежата, за приемниот тест. Задржете го LAN обидот како одделна опционална дијагностика.
Потоа читајте го дневникот по редот по кој пристигнуваат пакетите. Ништо воопшто значи дека ракувањето никогаш не стигнало до Pi, па целта за пренасочување или заштитниот ѕид на хостот е погрешен. Ракување што започнува и заглавува укажува на клучеви, сертификати или MTU. Сесија што се комплетира и паѓа обично значи повратната рута или втора стандардна рута, а линијата во дневникот на клиентот Initialization Sequence Completed ви кажува дека самиот тунел се подигнал.
sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20
Ако ништо не се појави во дневникот на серверот додека клиентот обидува повторно, престанете да ја читате конфигурацијата на OpenVPN и вратете се на целта за пренасочување. Снимката одговара на прашањето за пристигнувањето во секунди, а дојдовните пакети без одговор го стеснуваат проблемот на рутата.
Задржете враќање во еден чекор и пензионирајте го безжичниот профил
Оставете го безжичниот профил инсталиран додека кабелската поставеност не преживее рестарт. nmcli con show ги наведува имињата на профилите што ќе ви требаат, а избришан профил мора да се реконструира од меморија во најлошиот момент. Запишете го името на интерфејсот, методот на адресирање и метриката до другите четири вредности. Враќање што можете да го откуцате од белешка вреди повеќе од она што морате да го реконструирате.
Пензионирањето на безжичната зависност е промена на својство, а не бришење. Со поставување connection.autoconnect no акредитивите и историјата на адреси остануваат недопрени додека на Pi му се оневозможува повторно да се поврзе со мрежа од која сте заминале.
nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no
Пред да ја прогласите работата за завршена, потврдете четири работи: целта за пренасочување одговара на кабелската адреса, слушачот преживеа рестарт, клиент однадвор комплетира ракување, и Pi и понатаму одговара на кабелската адреса по рестарт. Рестартот е најевтиниот начин да фатите додела што постоела само во работечкото јадро. Ако било која од четирите не успее, подигнете го безжичниот профил повторно со sudo nmcli con up и споредете ги запишаните вредности со активните.