Гостьовий Wi-Fi продовжує використовувати основний маршрут: дайте йому власний вихід

Ви створили гостьову мережу, додали для неї маршрут, а гості все одно виходять через ваше звичайне інтернет-з'єднання. Тунель піднято, основна LAN працює, гостьові пристрої повідомляють адресу з призначеного вами діапазону, тому ніщо не виглядає зламаним. Зазвичай бракує не маршруту, а селектора: маршрутизатор вибирає шлях до того, як враховує, через який інтерфейс надійшов пакет, і якщо щось явно не збігається з гостьовим трафіком, цей трафік успадковує значення за замовчуванням. Рішення — сегмент, правило політики та зворотний шлях, саме в такому порядку.

Симптом: гості все одно виходять через WAN

Ознака — адреса виходу. Гостьовий пристрій, що потрапляє в інтернет через тунель, повідомить адресу провайдера тунелю, а пристрій, який успадкував значення за замовчуванням, повідомить ваше звичайне з'єднання. Порівняйте поруч гостьовий пристрій і пристрій основної LAN, бо цікавим є випадок, коли вони відрізняються від налаштованого вами та збігаються одне з одним.

Друга ознака — відсутність будь-якого трафіку на інтерфейсі тунелю, поки гості переглядають сайти. Якщо лічильники не рухаються, політика так і не була застосована, і налаштування самого тунелю не допоможе.

Крок 1: справжній сегмент, а не лише назва

Назва SSID не створює ізоляції. Перевірте, що гостьова мережа закінчується на власному інтерфейсі, VLAN або мосту, і що діапазон адрес відрізняється від довіреної LAN. На багатьох споживчих точках доступу гостьовий SSID об'єднується мостом у той самий сегмент, що й усе інше, що робить решту роботи неможливою, доки це не виправлено.

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

Не об'єднуйте гостей з основною LAN мостом, щоб спростити налаштування VPN. Це замінює потрібну вам ізоляцію на короткий шлях маршрутизації, і це звичайна причина, чому гостьова мережа зрештою отримує доступ до принтера й NAS.

Крок 2: виберіть тунель за джерелом

Таблиці маршрутизації вибираються за призначенням, тому правило «надішли 0.0.0.0/0 у тунель» діє для всіх. Політична маршрутизація додає другий вимір: виберіть таблицю за адресою джерела. На маршрутизаторі під Linux це додаткове правило плюс окрема таблиця, і порядок важливий, бо перемагає перше відповідне правило:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

Крок 3: зворотний шлях і трансляція

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

Перевіряйте ізоляцію, а не лише перегляд

Перегляд доводить, що вихід змінився. Він не доводить, що сегмент ізольований, а ізоляція — причина існування гостьової мережі. З гостьового пристрою спробуйте досягти інтерфейсу адміністрування маршрутизатора, хоста довіреної LAN і служби, яку слід відхилити; усі три мають зазнати невдачі, і невдача має бути рішенням політики, а не тайм-аутом, який ніхто не може пояснити.

Потім перевірте пристрій основної LAN і підтвердьте, що його вихід не змінився. Це та регресія, яку цей проєкт спричиняє найчастіше: широке правило, призначене для гостей, застосоване до кожного інтерфейсу, бо збіг було написано за призначенням.

Насамкінець вирішіть, що відбувається, коли тунель вимкнено. Гості або залишаються без інтернету, або переходять на схвалений вами шлях, і якщо залишити це невирішеним, це означає тихе повернення до звичайного з'єднання, а це саме той витік, який мала запобігти гостьова політика. Рецепт маршрутизації інтернет-трафіку проходить через той самий вибір шляху для маршрутизатора на базі pfSense.

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