hostapd і OpenVPN на одному Pi: чий це маршрут за замовчуванням?

hostapd і клієнт OpenVPN можуть ділити один Pi, якщо міст зберігає свій маршрут за замовчуванням, а тунель зберігає шлях до свого сервера. Команди й відкат.

Телефони підключаються до точки доступу, отримують адресу й потім взагалі нічого не досягають, щойно піднімається тунель. hostapd у цьому стані зазвичай здоровий, як і OpenVPN; ламається маршрут за замовчуванням, який або ніколи не існував на мості, або був замінений тунелем без збереження шляху до самого VPN-сервера. Цей посібник повертає маршрут на місце й доводить результат з клієнта, а не з Pi. Кожен крок можна відкотити, і ніщо тут не змінює конфігурацію тунелю, доки ви не знаєте, який трафік хочете всередині нього.

Опишіть інтерфейси, перш ніж щось редагувати

Звична схема розміщує бездротове радіо та дротовий порт усередині br0, запускає hostapd проти мосту й роздає оренди з dnsmasq, а клієнт OpenVPN створює tun0. Тоді три окремі вимоги виглядають як одна: клієнтам точки доступу потрібен Pi як їхній шлюз, Pi потрібен маршрут до інтернету, щоб дістатися свого сервера, а мосту потрібна адреса шлюзу, яку ці клієнти можуть використовувати.

Прочитайте поточний стан, перш ніж його змінити, бо ці чотири команди відокремлюють проблему інтерфейсу від проблеми маршрутизації.

ip -br addr
ip route show
ip link show master br0
bridge link show

Якщо br0 має адресу, але не має маршруту за замовчуванням, клієнти досягають Pi і нічого за ним. Якщо маршрут за замовчуванням указує на tun0, поки тунель опущений, Pi взагалі не має робочого шляху, і симптом клієнта виглядає точно так само. Обидва випадки з телефона виглядають однаково, тому таблицю маршрутів треба читати безпосередньо.

Дайте мосту маршрут за замовчуванням, який належить йому

Raspberry Pi OS часто залишає міст без маршруту за замовчуванням, якщо міст виник після запису файлу інтерфейсу. Блок належить до /etc/dhcpcd.conf, і він має називати вищий маршрутизатор, а не Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

У цьому прикладі 192.168.50.1 — наявний маршрутизатор, а 192.168.50.2 — адреса мосту Pi у тій самій підмережі, тож підставте свій план замість копіювання чисел. Члени мосту також не повинні запитувати маршрутизатори, інакше Pi залишиться з конкуруючими маршрутами за замовчуванням, переможець яких залежить від метрики й часу, а не від наміру.

Після systemctl restart dhcpcd ip route show default має показати br0 один раз і без дубліката з дротового порту. Підтвердьте пошук, а не таблицю, бо застарілий запис може стояти поруч із переможним: ip -4 route get 203.0.113.10 має назвати br0. Ця адреса з діапазону документації TEST-NET-3, тому вона не може зіткнутися з реальним сервером, поки ви це читаєте.

Не дайте тунелю викрасти шлях до власного сервера

Клієнт OpenVPN, який приймає redirect-gateway, забирає маршрут за замовчуванням і спрямовує його в тунель. Це правильно, коли кожен клієнт точки доступу має використовувати VPN, і неправильно, коли мають лише деякі призначення. У будь-якому разі власне з'єднання Pi із сервером не повинно йти всередині тунелю, який він ще будує. OpenVPN додає маршрут до хоста через початковий шлюз, коли перенаправляє маршрут за замовчуванням, і саме ця поведінка тримає транспорт живим; якщо цього маршруту немає, тунель руйнується, щойно встановлюється.

Швидке порівняння цього транспортного шляху до й після підключення варте тих десяти секунд. ip -4 route get 203.0.113.10 має назвати пристрій нижнього рівня в обох станах, змінюється лише метрика. Якщо після підйому тунелю він називає tun0, маршрут до хоста так і не був встановлений, і наступне перепідключення не вдасться.

Коли через тунель мають проходити лише вибрані префікси, використовуйте route-nopull і додайте потрібні маршрути вручну або надішліть з сервера вужчий набір. Міст у такій схемі зберігає маршрут за замовчуванням, а DNS стає наступним рішенням: переспрямування dnsmasq на домашній резолвер має сенс лише для імен, які справді там живуть.

Вирішіть питання переспрямування та NAT

Повний тунель потребує ввімкненого переспрямування на Pi й шлюзу на дальньому боці, готового маршрутизувати підмережу точки доступу. Перевірте переспрямування перед усім іншим, бо нуль робить будь-яку зміну маршруту неважливою.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Правило NAT — це короткий шлях, який працює, коли сервер не прийме префікс точки доступу, ціною того, що кожен клієнт виглядатиме як тунельна адреса Pi в журналах дальнього боку. Маршрутизація префікса без NAT зберігає адреси видимими і залежить від зворотного маршруту для 192.168.50.0/24 на домашньому боці.

Запишіть вибір поруч із правилами брандмауера, бо невидиме в проєкті правило NAT через шість місяців стає непоясненним. Тримайте IPv6 у тому самому рішенні; робочий шлях IPv4 поруч зі зламаним шляхом IPv6 усе ще читається як наполовину зламаний у браузері.

Перевірте з клієнта, потім чисто відкотіть

Перевіряйте в цьому порядку з телефона або ноутбука в точці доступу: оренда з dnsmasq, ping до адреси мосту, потім призначення на дальньому боці тунелю. Кожен крок ізолює один рівень замість того, щоб дати одну некорисну помилку.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Потім підтвердьте, що Pi досі має власний вихід: ip route get 203.0.113.10 має назвати пристрій нижнього рівня, а ping -c 3 -I br0 203.0.113.10 має відповісти, якщо сервер дозволяє ICMP. Якщо перші два кроки клієнта проходять, а третій не вдається, помилка в переспрямуванні або NAT. Якщо не вдається другий крок, міст або DHCP ще не завершені.

Відкат — це одне редагування файлу й дві команди: видаліть блок, перезапустіть dhcpcd і замініть маршрут за замовчуванням явно на ip route replace default via 192.168.50.1 dev br0. Зробіть це до закриття вікна обслуговування, а не після, бо Pi, який втратив маршрут за замовчуванням, недосяжний із мережі, яку ви використали б для його ремонту.

Схожі статті