Мостовий 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.
Запишіть, який пристрій володіє кожним маршрутом за замовчуванням, коли закінчите. Один рядок документації перетворює локальний чи віддалений вихід на свідоме рішення клієнта, і посилання на міст варто тримати поруч.