Клієнти LAN ігнорують VPN роутера, доки не ввімкнеться маршрутизація за політиками

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

Правило фільтра не може вибрати інтерфейс

Потік пакетів на Linux-роутері спершу виконує рішення про маршрут, а потім хук forward. Коли правило збігається з вихідним тунельним пристроєм, ядро вже вирішило, що тунель — це вихід. Якщо головна таблиця досі віддає перевагу маршруту за замовчуванням через WAN, пакет прямує до провайдера, і щойно написане правило дозволу його ніколи не побачить. Цей єдиний факт про порядок пояснює, чому сторінка нових правил міжмережевого екрана нічого не змінює.

У прикладі нижче використано LAN 192.168.8.0/24 на br-lan, тунельний пристрій tun0 і одну приставку за адресою 192.168.8.23, яка має йти через тунель.

Прочитайте пошук, перш ніж редагувати правила

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

ip -4 route get 198.51.100.7 from 192.168.8.23

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

Прив'яжіть таблицю до клієнтів, які хочете охопити

Маршрутизація за політиками вставляє пошук правил перед головною таблицею. Побудуйте таблицю, маршрут за замовчуванням у якій — тунель, потім прив'яжіть її до селектора: вхідного інтерфейсу, адреси джерела або позначки міжмережевого екрана. Пріоритети задають порядок, а головна таблиця стоїть далеко внизу списку, на 32766, тому правило з малим номером перевіряється першим. Селектори інтерфейсу охоплюють кожного клієнта на мосту; селектори адреси — одну машину.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

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

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

Тримайте локальні призначення поза тунелем

Нова таблиця знає лише ті маршрути, які ви до неї поклали. Префікса LAN немає, тому трафік принтера й NAS пішов би маршрутом за замовчуванням у тунель і зник. Маршрут throw завершує пошук у цій таблиці й повертає рішення головній таблиці.

ip -4 route add throw 192.168.8.0/24 table 200

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

Правила й маршрути, додані під час роботи, зникають після перезавантаження або оновлення прошивки. Додайте їх до механізму запуску роутера, перезавантажте один раз і знову перевірте з клієнта: його публічну адресу, другого клієнта, який має залишитися на WAN, і лічильники тунелю під час нового з'єднання.