Клієнти хотспота на Pi не доходять до домашньої LAN через TUN VPN

Локальні клієнти Wi-Fi та Ethernet підключаються до хотспота Pi, отримують адресу з його діапазону DHCP і завантажують інтернет-сторінки без скарг. Потім ті самі клієнти отримують тайм-аут, коли відкривають файлову теку або веб-інтерфейс у домашній LAN, тоді як сам Pi досягає цієї LAN через тунель. У бездротовому шарі нічого не зламано. Бракує маршрутизованого договору: префікс хотспота треба перенести в інтерфейс TUN, і щось на домашньому боці має знати, як надсилати відповіді туди назад. Обидві половини мають існувати, перш ніж один пакет зможе завершити шлях туди й назад.

Три підключення з трьома різними завданнями

Міст Ethernet у Linux пересилає кадри за MAC-адресою призначення. OpenVPN у режимі TUN несе IP-пакети й зовсім не має шару MAC, тому додавання локального мосту ніколи не реєструє тунель як порт. документація ядра щодо TUN/TAP пояснює цей поділ: пристрій TAP виглядає як інтерфейс Ethernet, пристрій TUN — ні. Проєкт, який з'єднує два локальні порти, а потім маршрутизує, є маршрутизатором, хоч би що казали назви інтерфейсів.

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

Тримайте модем і поза мостом клієнтів. Підключення PPP — не пристрій Ethernet з іншою етикеткою, а документована логіка маршруту за замовчуванням у pppd працює після переговорів IPCP і відкликає свій маршрут, коли це з'єднання падає. Копіювання шаблону DHCP і перейменування кожного usb0 у ppp0 нічого не доводить про шлюз, метрику чи життєвий цикл.

Виберіть префікси, перш ніж редагувати будь-яку конфігурацію

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Перший пул — адреса underlay, яку оператор дав модему; вона має залишатися поза будь-яким планом, зверненим до клієнтів. Другий — підмережа тунелю, вибрана сервером, часто його власна приватна /24-мережа. Третій — міст хотспота, а четвертий — домашній префікс, якого ви хочете досягти. У цьому проході хотспот отримує 172.28.90.0/24 з мостом на 172.28.90.1, а домашня сервісна LAN зберігає 192.168.77.0/24, що обходить стандартні 192.168.1.0/24 і 10.0.0.0/24, які постачаються споживчими маршрутизаторами, та діапазон оператора 100.64.0.0/10.

У діапазоні DHCP хотспота оголошуйте шлюзом лише адресу мосту і нічого більше. Ніколи не давайте клієнтам хотспота домашню адресу як шлюз; вони не мають шляху на канальному рівні до цього сегмента.

Маршрутизуйте кожен напрямок на тому боці, який ним володіє

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

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Якщо ip route get досі повідомляє інтерфейс underlay, зупиніться там; ніщо далі на шляху не виправить хибний пошук.

Домашні пристрої не мають маршруту до 172.28.90.0/24, тому їхні відповіді йдуть через шлюз за замовчуванням і гинуть на маршрутизаторі. Є два підтримувані виправлення. Або додайте статичний маршрут на домашньому маршрутизаторі, який спрямовує префікс хотспота на LAN-адресу VPN-сервера, або, коли сервер сам є шлюзом, зареєструйте префікс клієнта у власній таблиці маршрутизації сервера. У багатоклієнтному режимі OpenVPN каталог, специфічний для клієнта, несе цей зв'язок: файл, названий за спільним ім'ям сертифіката клієнта, що містить iroute 172.28.90.0 255.255.255.0 плюс відповідний рядок route, який встановлює його в ядрі сервера. Вгаданий маршрут ядра на сервері — не те саме твердження, що повідомити серверу, який клієнт володіє префіксом.

Не переносьте службу DHCP домашньої мережі на VPN-сервер, щоб це працювало. Заміна шлюзу за замовчуванням для цілого дому — значно більша зміна, ніж додавання одного приватного зворотного маршруту, і вона втягує DNS, резервування адрес і кожен пристрій, що ігнорує нову оренду, у відмову.

Відкрийте пересилання, не вгадуючи брандмауер

Увімкнене пересилання не означає, що пакету дозволено пройти. Трафік від мосту до тунелю все ще натрапляє на правила фільтрації, і політика пересилання за замовчуванням drop відкидає трафік хотспота, поки власний трафік Pi продовжує працювати, що дає саме той розщеплений симптом вище.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Шукайте правило прийняття від br0 до tun0 і відповідний напрямок відповіді, а також правило postrouting, яке може переписати джерело. Якщо політика ланцюга — drop і жодне правило не підходить, додайте вузькі прийняття й повторіть тест, замість того щоб перевертати політику в accept.

Трансляція — це вибір політики, а не вимога. Source NAT у бік домашньої LAN змушує кожного клієнта хотспота виглядати як тунельна адреса Pi, що втрачає прив'язку за клієнтами в домашніх журналах і ламає служби, які очікують початкове джерело. Маршрутизація без NAT зберігає адреси клієнтів видимими, але залежить від зворотного маршруту вище. Виберіть одне й поводьтеся з DNS та IPv6 так само, бо робочий шлях IPv4 поруч зі зламаним шляхом IPv6 усе ще читається в браузері як наполовину зламаний.

Перевірте шлях туди й назад, а потім навмисно зламайте його

Тестуйте з клієнта хотспота, ніколи з Pi, бо власний трафік Pi обходить і прямий, і зворотний шлях. Спостерігайте обидва інтерфейси, поки один клієнт намагається досягти домашньої служби.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

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

Потім навмисно зламайте шлях. Опустіть модемне з'єднання й підніміть його знову та повторно виконайте перевірки маршруту й захоплення; маршрут, який переживає тунель, але зникає під час перепідключення, належить профілю з'єднання, а не одноразовій команді. Переконайтеся, що транспорт тунелю досі виходить через underlay, а не через себе, класична петля, коли проштовхнутий маршрут за замовчуванням приймається без маршруту до хоста-партнера.

Приймайте проєкт лише тоді, коли клієнт хотспота може розв'язати домашнє ім'я, відкрити службу TCP і втримати сеанс живим через одне перепідключення модема. Якщо застосунку справді потрібне виявлення на рівні Ethernet у домашньому сегменті, виберіть підтримуваний проєкт Layer 2, замість того щоб описувати локальний міст як зведений у міст і чекати появи широкомовлення.