Едно устройство през рутер 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

Маршрутът unreachable е причината маркираната таблица да превъзхожда списък с изключения в основната таблица. Когато тунелът падне, маркираните пакети получават незабавно „недостъпно“, вместо тихо да се върнат към 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 и проверките за обновяване на рутера. Именно този изходящ път е обичайната причина напълно тунелирана настройка да отговаря от резолвера на ISP при тест за изтичане.

Политиката за устройство се нуждае от съвпадение, което не се измества. Резервирайте адреса в DHCP или съпоставете интерфейс за отделен сегмент; адрес, който по-късно се премести на друго устройство, тихо прилага тунела към грешния клиент. Мост за всеки SSID със собствена подмрежа е по-трайната версия на същата идея и дава на правилата за IPv6 място, където да живеят.

Трета част: NAT, DNS и изключението за LAN

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

Изключението за LAN причинява повече теми за поддръжка от самия тунел. Ако маркираната таблица съдържа само маршрут по подразбиране, дестинация за принтер или NAS от избраното устройство съвпада с това по подразбиране и изчезва в тунела. Добавете LAN маршрута в същата таблица или изключете локалната подмрежа в селектора; и двете работят, а изключването е по-лесно да остане правилно, когато по-късно добавите VLAN.

DNS поема отделен път. Заявките, които рутерът препраща, произхождат от рутера и следват OUTPUT, а не маркировката за препращане, така че напълно тунелиран лаптоп може все още да резолвва през ISP. Насочете клиентите към резолвер, достъпен през тунела, или маркирайте собствения трафик на порт 53 на рутера, след което проверете резолвнатия адрес, вместо да предполагате, че отговорът е пътувал с уеб заявката.

Когато правилото съвпада, но приложението все още използва WAN

Списъците с дестинации остаряват бързо. Име се резолвва към адрес, който не е в списъка, така че заявката поема WAN, докато всеки тест, който сте правили срещу адреса от списъка, е работел. Обновявайте списъка от същия резолвер, който използва клиентът, и предпочитайте селектор по източник, когато наистина искате целия трафик от едно устройство.

IPv6 е тихият обходен път. Устройството има второ семейство адреси със свой маршрут по подразбиране и свой набор от правила и съвпадението само по IPv4 адреса е половината политика. Приложете същия селектор към ip6tables или еквивалента в nftables, или изключете IPv6 за този сегмент умишлено, а не случайно.

Установените връзки също имат значение. Запис в conntrack, създаден преди промяната, следва стария път, докато изтече, така че браузър, който е останал отворен по време на редакцията, изглежда точно като правило, което никога не се е приложило. Отворете нова връзка или изчистете състоянието, преди да съдите за политиката.

Проверете с две устройства и рестарт

Тествайте устройството, което трябва да е в тунела, и устройството, което не трябва, и сравнете втория хоп, а не число за скорост. Traceroute от всяко показва на втория хоп или шлюза на тунела, или шлюза на ISP; ако и двете изглеждат еднакво, маркировката или таблицата не прави това, което казва правилото. Използвайте нови връзки за теста.

След това рестартирайте. Редът на стартиране е мястото, където работеща политика става счупена, защото клиентът трябва да е активен, преди да се инсталира маршрутът unreachable, а запазен снимък, който възстановява стария набор от правила, ще презапише таблицата ви. Проверете, че всяко правило е в запазената конфигурация и че маркираният маршрут по подразбиране съществува след зареждане, а не само след като сте го въвели.

Ако нещо се провали, първо премахнете маркировката и вижте дали нормалният трафик се връща, след това премахнете таблицата. Този ред ви казва дали преследвате проблем с маршрутизацията, или проблем със защитната стена, и оставя домакинството с работещ принтер, докато довършвате работата.