Адна прылада праз 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, а захаваны здымак, які аднаўляе стары набор правілаў, перазапіша вашу табліцу. Праверце, што кожнае правіла ёсць у захаванай канфігурацыі і што пазначаны стандартны маршрут існуе пасля загрузкі, а не толькі пасля таго, як вы яго ўвялі.

Калі нешта не атрымалася, спачатку зніміце адзнаку і паглядзіце, ці вернецца звычайны трафік, затым зніміце табліцу. Гэты парадак кажа вам, ці ганяецеся вы за праблемай маршрутызацыі або за праблемай фаерсцяны, і пакідае дом з працоўным прынтарам, пакуль вы даводзіце справу да канца.