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, потерявший маршрут по умолчанию, недостижим из сети, которую вы использовали бы для его ремонта.

Похожие статьи