Как да преместите 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 и сравнете записаните стойности с активните.