Один пристрій через VPN на роутері потребує трьох правил, а не перемикача

На VPN на роутері немає перемикача для кожного пристрою; перемикач, який ви шукаєте, — це ярлик, що пише правила маршрутизації політики від вашого імені. У момент, коли одному ноутбуку, одному діапазону портів, одному списку адрес або одному сегменту LAN потрібно використовувати тунель, а все інше залишається в WAN, ви будуєте маршрут політики, а не вмикаєте функцію. Робота має три рухомі частини, і кожна відмовляє по-своєму: позначена таблиця без маршруту виглядає як тиша, мітка, поставлена не в тому ланцюжку, виглядає так, ніби нічого не сталося, а відсутнє правило NAT виглядає як тунель, який підключається і нічого не несе. Ще дві частини губляться, бо ніколи не з'являються в правилі mangle, і це DNS та IPv6.

Міф: тунель — це налаштування клієнта

VPN-клієнт на боці роутера добре робить одну грубу річ: він кладе 0.0.0.0/0 у головну таблицю маршрутизації і спрямовує її в тунель. WireGuard виводить це з AllowedIPs, OpenVPN а з redirect-gateway, який надсилає сервер, і обидва змінюють шлях для кожного хоста за роутером. Звуження AllowedIPs або додавання route-nopull змінює те, що встановлює клієнт. Це не змінює того, на кого поширюється встановлення, бо клієнт ніколи не бачить пристроїв. Він бачить лише пакети.

Вибір за джерелом або призначенням — це рішення маршрутизації, тому він належить до шару політики роутера: правило mangle плюс друга таблиця на RouterOS, MARK плюс ip rule на OpenWrt або DD-WRT, або правило брандмауера, шлюзом якого є тунель, на pfSense. Рецепт клієнта WireGuard від Netgate — це те, що варто прочитати перед здогадками, бо на цій платформі шлюз правила, призначення інтерфейсу та запис вихідного NAT мають узгодитися, перш ніж хоч один клієнт почне використовувати тунель.

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

Частина перша: тунель, який не є маршрутом за замовчуванням

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

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 розділяє те, що 6.x тримав разом: таблицю оголошують через /routing table add name=vpn fib, а потім посилаються на неї за назвою в маршруті та в правилі mangle. Фрагмент для 6.x, який пише routing-mark без визначення таблиці, завантажується чисто і нічому не відповідає. Інша класика — дві половини 0.0.0.0/1 або два маршрути за замовчуванням на однаковій відстані в одній таблиці: ядро вибирає один, і поведінка може змінитися після перезавантаження.

Частина друга: позначте до пошуку маршруту

Селектор вирішує, які пакети потраплять до цієї таблиці. RouterOS зазвичай починає зі списку адрес для політики призначення або з адреси джерела для політики пристрою:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Прошивка Linux робить те саме з міткою netfilter і правилом, яке спрямовує позначені пакети до таблиці, яку ви заповнили:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Ланцюжок — не вибір стилю. На момент, коли пакет досягає FORWARD, пошук маршруту вже відбувся, тому MARK або DROP там може лише переписати чи відкинути. Мітка має потрапити до PREROUTING для пересиланого трафіку і до OUTPUT для трафіку, який створює сам роутер, де живуть DNS, NTP і перевірки оновлень роутера. Саме цей вихідний шлях — звичайна причина, чому повністю тунельована конфігурація в тесті на витік усе ще відповідає від резолвера провайдера.

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

Частина третя: NAT, DNS і виняток для LAN

Трафіку, що виходить через тунель, потрібна адреса джерела, на яку відповість інша сторона. Обмежте трансляцію інтерфейсом тунелю: out-interface=VPN_NAME на RouterOS, -o tun0 у Linux, відповідний запис вихідного NAT на pfSense. Правило masquerade без цього обмеження переписує трафік, який ви хотіли залишити в спокої, і симптом у тому, що пристрій поза тунелем втрачає свою публічну адресу.

Виняток для LAN викликає більше тем підтримки, ніж сам тунель. Якщо позначена таблиця містить лише маршрут за замовчуванням, адреса принтера або NAS з вибраного пристрою збігається з цим маршрутом і зникає в тунелі. Додайте маршрут LAN до тієї самої таблиці або виключіть локальну підмережу в селекторі; працюють обидва варіанти, і виняток легше тримати коректним, коли ви згодом додаєте VLAN.

DNS іде окремим шляхом. Запити, які роутер пересилає, породжуються роутером і йдуть за OUTPUT, а не за пересиланою міткою, тому повністю тунельований ноутбук усе ще може розв'язувати імена через провайдера. Спрямуйте клієнтів на резолвер, доступний через тунель, або позначте власний трафік port-53 роутера, а потім перевірте розв'язану адресу, замість того щоб вважати, що відповідь подорожувала разом із веб-запитом.

Коли правило збігається, але застосунок усе ще використовує WAN

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

IPv6 — це тихий обхід. У пристрою є друга родина адрес із власним маршрутом за замовчуванням і власним набором правил, і збіг лише за адресою IPv4 — це половина політики. Застосуйте той самий селектор до ip6tables або еквівалента nftables, або навмисно вимкніть IPv6 у цьому сегменті, а не випадково.

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

Перевірте двома пристроями та перезавантаженням

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

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

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