Роутер VPN арқылы бір құрылғыны өткізу үшін ауыстырғыш емес, үш ереже керек

Роутер VPN-де әр құрылғыға арналған ауыстырғыш жоқ; сіз іздеп жүрген ауыстырғыш — сіздің орныңызға саясаттық маршруттау ережелерін жазатын қысқа жол. Бір ноутбук, бір порт диапазоны, бір мекенжай тізімі немесе бір LAN сегменті туннельді пайдалануы керек болғанда, ал қалғаны WAN-да қалатын болса, сіз функцияны қосып жатқан жоқсыз, саясаттық маршрут құрып жатырсыз. Жұмыстың үш қозғалмалы бөлігі бар және әрқайсысы өзінше істен шығады: маршруты жоқ таңбаланған кесте үнсіздікке ұқсайды, дұрыс емес тізбекке қойылған белгі ештеңе болмағандай көрінеді, ал жетіспейтін NAT ережесі қосылатын, бірақ ештеңе тасымайтын туннельге ұқсайды. Тағы екі бөлік mangle ережесінде ешқашан көрінбегендіктен жоғалады, олар — DNS және IPv6.

Аңыз: туннель — клиенттің параметрі

Роутер жағындағы VPN клиенті бір дөрекі істі жақсы істейді: 0.0.0.0/0-ді негізгі маршруттау кестесіне қойып, оны туннельге бағыттайды. WireGuard мұны AllowedIPs-тен алады, OpenVPN ал серверден жіберілген redirect-gateway-ден алады, және екеуі де роутердің артындағы әрбір хосттың жолын өзгертеді. AllowedIPs-ті тарылту немесе route-nopull қосу клиенттің не орнататынын өзгертеді. Бұл орнату кімге қолданылатынын өзгертпейді, өйткені клиент құрылғыларды мүлде көрмейді. Ол тек пакеттерді көреді.

Көз немесе межелік бойынша таңдау — маршруттау шешімі, сондықтан ол роутердің саясат қабатына жатады: RouterOS-те mangle ережесі мен екінші кесте, OpenWrt немесе DD-WRT-де MARK пен ip rule, немесе pfSense-те шлюзі туннель болатын firewall ережесі. Netgate-тің WireGuard клиентінің рецепті — болжам жасамас бұрын оқу керек нәрсе, өйткені бұл платформада ереженің шлюзі, интерфейсті тағайындау және шығыс NAT жазбасы бір клиент туннельді пайдаланбай тұрып келісуі керек.

Аңыздың екінші жартысы — екінші роутер. Тағы бір қорап сатып алу немесе құрылғыны қонақ SSID-ге көшіру жиі жұмыс істейді, бірақ себебі аппаратура емес: бұл құрылғыны өз подсетіне қояды, сол арқылы firmware түсінетін көз селекторын береді. Егер сол сегментті өз роутеріңізде анықтай алсаңыз, қосымша қорап сізде болмаған мәселені шешеді.

Бірінші бөлік: әдепкі маршрут емес туннель

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 ережесінде атымен сілтейсіз. Кестені анықтамай routing-mark жазатын 6.x үзіндісі таза жүктеледі және ештеңеге сәйкес келмейді. Тағы бір классика — 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 firmware дәл солай 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 resolver-інен жауап беруінің әдеттегі себебі.

Құрылғы саясатына жылжымайтын сәйкестік керек. Мекенжайды DHCP-де қалдырыңыз немесе арнайы сегмент үшін интерфейсті сәйкестендіріңіз; кейін басқа құрылғыға көшетін мекенжай туннельді үнсіз дұрыс емес клиентке қолданады. Өз подсеті бар SSID бойынша көпір — сол идеяның неғұрлым төзімді нұсқасы, ол IPv6 ережелеріне де орын береді.

Үшінші бөлік: NAT, DNS және LAN ерекшелігі

Туннельден шығатын трафикке арғы жақ жауап беретін көз мекенжайы керек. Түрлендіруді туннель интерфейсімен шектеңіз: RouterOS-те out-interface=VPN_NAME, Linux-те -o tun0, pfSense-те сәйкес шығыс NAT жазбасы. Осы шектеусіз masquerade ережесі сіз тиіспеуге тиісті трафикті қайта жазады, ал симптом — туннельсіз құрылғының өз жалпыға ортақ мекенжайынан айырылуы.

LAN ерекшелігі туннельдің өзінен де көп қолдау тақырыбын тудырады. Егер таңбаланған кестеде тек әдепкі маршрут болса, таңдалған құрылғыдан принтер немесе NAS межелігі сол әдепкіге сәйкес келіп, туннельге кіріп кетеді. LAN маршрутын сол кестеге қосыңыз немесе селекторда жергілікті подсетті алып тастаңыз; екеуі де жұмыс істейді, ал кейін VLAN қосқанда алып тастау дұрыс күйде ұстауға оңайырақ.

DNS бөлек жолмен жүреді. Роутер жіберетін сұраныстар роутерден шығады және OUTPUT-ке бағынады, бағытталған белгіге емес, сондықтан толық туннельденген ноутбук әлі де ISP арқылы атауды шеше алады. Клиенттерді туннель арқылы қолжетімді resolver-ге бағыттаңыз немесе роутердің өзінің port-53 трафигін таңбалаңыз, содан кейін жауап веб-сұраныспен бірге жүрді деп болжамай, шешілген мекенжайды тексеріңіз.

Ереже сәйкес келгенде, бірақ қолданба әлі де WAN-ды пайдаланса

Межелік тізімдері тез ескіреді. Атау тізімде жоқ мекенжайға шешіледі, сондықтан сұраныс WAN-ға кетеді, ал тізімдегі мекенжайға жасаған барлық тестіңіз жұмыс істеген болатын. Тізімді клиент қолданатын resolver-ден жаңартыңыз және бір құрылғыдан барлық трафикті шынымен қаласаңыз, көзге негізделген селекторды қалаңыз.

IPv6 — үнсіз айналып өту жолы. Құрылғының өз әдепкі маршруты мен өз ережелер жинағы бар екінші мекенжай тұқымдасы бар, ал тек IPv4 мекенжайына сәйкестендіру — саясаттың жартысы. Сол селекторды ip6tables-ке немесе nftables баламасына қолданыңыз, немесе сол сегменттегі IPv6-ны апатты түрде емес, әдейі өшіріңіз.

Орнатылған қосылымдар да маңызды. Өзгеріске дейін жасалған conntrack жазбасы мерзімі бітпейінше ескі жолмен жүреді, сондықтан өңдеу кезінде ашық тұрған браузер ешқашан қолданылмаған ережеге дәл ұқсайды. Саясатты бағаламас бұрын жаңа қосылым ашыңыз немесе күйді тазалаңыз.

Екі құрылғымен және қайта жүктеумен тексеріңіз

Туннельге кіруі тиіс құрылғыны және кірмеуі тиіс құрылғыны сынап, жылдамдық санының орнына екінші хопты салыстырыңыз. Әрқайсысынан traceroute екінші хопта туннель шлюзін немесе ISP шлюзін көрсетеді; екеуі бірдей көрінсе, белгі немесе кесте ереженің айтқанын істемейді. Тест үшін жаңа қосылымдарды пайдаланыңыз.

Сосын қайта жүктеңіз. Іске қосылу реті — жұмыс істеп тұрған саясат бұзылатын жер, өйткені клиент жетпейтін маршрут орнатылмай тұрып жұмыс істеуі керек, ал ескі ережелер жинағын қалпына келтіретін сақталған сурет кестеңізді қайта жазады. Әрбір ереженің сақталған конфигурацияда екенін және таңбаланған әдепкінің жүктеуден кейін бар екенін тексеріңіз, тек тергеннен кейін ғана емес.

Бірдеңе істемесе, алдымен белгіні алып тастап, қалыпты трафиктің қайтатынын қараңыз, содан кейін кестені алып тастаңыз. Бұл рет маршруттау мәселесін ме, әлде firewall мәселесін ме қуып жатқаныңызды айтады және жұмысты бітіргенше үйде жұмыс істейтін принтер қалады.