Мостовой VPN-хотспот: какой маршрут по умолчанию использует телефон?
Маршрут по умолчанию на Pi — не шлюз телефона. Разделите два решения, держите uplink вне моста и проверьте lease до туннеля.
Телефон в вашем мостовом хотспоте получает адрес и шлюз откуда-то, и это не маршрут по умолчанию на Pi. Изменение маршрута по умолчанию на Pi меняет, куда Pi отправляет свой собственный трафик. Телефон продолжает использовать шлюз, о котором ему сообщили, и когда этот шлюз находится в удалённой LAN, его кадры просто проходят через мост. Два потребителя, два решения. Их разделение объясняет большинство сообщений о хотспоте без интернета, когда сам Pi в порядке.
Два устройства, два разных решения о шлюзе
У Pi есть собственный стек IP и собственный маршрут по умолчанию. У телефона есть собственный стек IP и собственный маршрут по умолчанию.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
Эта таблица — вся модель. Шлюз телефона — это адрес в удалённой LAN, и его кадры передаются на уровне 2 к этому маршрутизатору. Маршрут по умолчанию на Pi касается его собственного внешнего транспорта, который должен достичь VPN-пира через дорожный uplink.
Мост пересылает кадры, он не маршрутизирует пакеты
Мост Linux пересылает кадры Ethernet по MAC назначения, и это всё, что он делает между своими портами. Кадр телефона, адресованный MAC удалённого маршрутизатора, переключается на порт TAP и проходит туннель, не касаясь таблицы маршрутизации Pi. Поэтому сломанный маршрут по умолчанию на Pi может оставить телефон работающим, и поэтому правильный не может починить телефон, которому дали неверный шлюз.
TAP несёт кадры Ethernet и может быть портом моста. TUN несёт пакеты IP и не может. Если ваш проект заменил одно другим, мост не является мостом, и остальное здесь не применяется.
Решите, кто раздаёт lease телефона
Параметр DHCP 3 — это параметр маршрутизатора, и он сообщает клиенту, какой шлюз использовать для его подсети. Когда DHCP-сервер удалённой LAN — единственный раздатчик, телефон получает удалённый шлюз, и проект согласован. Когда что-то другое на стороне поездки отвечает первым, телефон получает локальный шлюз, его интернет-трафик уходит через дорожный uplink, а трафик в удалённую LAN вообще не имеет пути.
Запустите один раздатчик для этого широковещательного домена и запишите, что он раздаёт.
Pi — отдельный случай, даже когда он получает адрес из того же lease. Сознательно решите, нужно ли устанавливать маршруты, которые предлагает lease, потому что импортированный удалённый маршрут по умолчанию может затянуть собственный VPN-транспорт Pi в туннель, который он пытается сохранить живым. В systemd-networkd это решение — UseRoutes= в разделе DHCP; в dhclient это параметр routers в списке запросов.
Держите uplink вне мостовой LAN
Интерфейс, несущий внешнее VPN-подключение Pi, не должен становиться портом моста. Если он им станет, шифрованный транспорт переключается в расширенную LAN, и туннель начинает нести свои собственные внешние пакеты, что отказывает так, что это выглядит как потеря пакетов, а не как петля. Держите также явными поддержку AP и моста. Беспроводной интерфейс в режиме station обычно не может быть портом моста, потому что в заголовке 802.11 нет места для второго MAC-адреса, который нужен мосту.
Определите расширенный широковещательный домен, один план адресов и ту фильтрацию кадров, которая вам действительно нужна. Разрешение слушателю VPN на Pi не даёт каждому мостовому клиенту доступ к службам управления Pi. Это отдельные правила, и обращение с ними как с одним — это то, как хотспот тихо становится открытой дверью.
Проверяйте четыре вещи по отдельности, когда ломается
Когда телефон не достигает удалённой LAN, четыре наблюдения разделяют причины. Выполните их в этом порядке и остановитесь на первом неудачном.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpНачните с lease: есть ли у телефона адрес и шлюз в удалённой подсети? Затем посмотрите на мост и подтвердите, что порт AP и порт TAP оба пересылают. Затем прочитайте таблицу соседей, потому что неразрешённая запись для удалённого маршрутизатора означает, что кадры уходят, а никто не отвечает. В конце наблюдайте кадры на мосте, пока телефон пингует, — это скажет, находится ли неисправность вообще ниже IP.
Запишите, какое устройство владеет каждым маршрутом по умолчанию, когда закончите. Одна строка документации превращает локальный или удалённый выход в осознанное решение клиента, и ссылку на мост стоит держать рядом.