Як перевести VPN-сервер Raspberry Pi на Ethernet
Переведіть VPN-сервер Raspberry Pi з Wi-Fi на Ethernet, не змінюючи ім’я кінцевої точки, прив’язку слухача, проброс порту та шлях відкату за один крок.
Перевести Pi з Wi-Fi на кабель виглядає як п’ятихвилинна робота, і вона залишається такою лише якщо розглядати переїзд як чотири окремі налаштування, а не одне. Ім’я кінцевої точки, до якої підключаються клієнти, може залишитися точно таким самим, поки адреса під ним змінюється. Ламається насправді слухач, прив’язаний до старої адреси, проброс порту, досі націлений на бездротову оренду, або зворотний маршрут, що виходить через інтерфейс, який ви вважали виведеним з експлуатації. Цей посібник тримає шлях відновлення відкритим на кожному кроці, тож невдале перемикання коштує лише перезавантаження.
Запишіть чотирьох відповідальних, перш ніж щось відключати
Чотири налаштування вирішують, чи переживе перемикання: адреса Pi, адреса прив’язки OpenVPN, ціль перенаправлення на маршрутизаторі та шлях, яким ідуть відповіді. Запишіть усі чотири, перш ніж торкатися кабелю, бо коли бездротова оренда зникне, старі значення ви з машини вже не прочитаєте. Проводовий інтерфейс не успадковує бездротовий профіль, і в 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 і порівняйте записані значення з поточними.