Роутер 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 көйгөйүнбү кууп жатканыңызды айтат жана ишти бүтүргөнчө үйдө иштеген принтер калат.