VPN orqali faqat bitta xususiy quyi tarmoqni qanday yuborish mumkin

Tunnel orqali faqat bitta xususiy quyi tarmoqni o'tkazib, qolgan hamma narsani odatdagi yo'lingizdan yuborish kichik so'rov, ammo uni noto'g'ri qilishning ko'p yo'li bor. Natijani split tunneling yozuvli katakcha emas, qaror qayerda bajarilishi hal qiladi: mijozning o'z marshrut jadvalida, server itarib yuboradigan marshrutda yoki ikki tomon kelishadigan siyosatda. Noto'g'ri qatlamni tanlasangiz, yo hech qachon xohlamagan to'liq tunnelga, yo qarshi tomon qabul qilishdan bosh tortadigan tunnelga olib boradigan marshrutga duch kelasiz. Har qanday konfiguratsiyani ochishdan oldin men uch shartli tekshiruvdan foydalanaman, so'ng quyidagi mexanizmlardan birini tanlayman.

Dizaynni hal qiladigan uch shart

Birinchidan, sizga tarmoq egasidan aniq prefiks va maska kerak. 10.x tarmog'i prefiks emas; 10.20.0.0/16 prefiks. Uy LAN tarmog'ingiz, Docker ko'prigi yoki siz ishga tushirgan boshqa VPN bilan qoplanishmasligini tekshiring, chunki qoplanish marshrutni noaniq qiladi va yadro siz o'ylamagan yozuvni tanlaydi.

Ikkinchidan, qaytib keladigan trafikka kim javob beradi. Paketni tunnelga yo'naltirish uni faqat VPN serveriga yetkazadi. Agar quyi tarmoq mijozlar hovuzingizga qaytish marshruti bo'lmagan boshqa marshrutizator ortida bo'lsa, server trafikni maskalashi kerak, yoki u marshrutizator hovuzingizni o'rganishi kerak. Mijoz tomonidagi hech bir marshrut yo'qolgan qaytish yo'lini tuzatmaydi.

Uchinchidan, bajarish nuqtasi. Ba'zi mijozlar marshrut o'rnatadi, qolganini operatsion tizim bajaradi. Boshqalari siyosat bo'yicha kelishadi, va shlyuz qabul qilmaydigan siyosat umuman tunnel yaratmaydi: paketlar aniq xatosiz tashlab yuboriladi. Biror narsa yozishdan oldin bu ikkisidan qaysi biri sizniki ekanini aniqlang.

WireGuard: AllowedIPs bu marshrut jadvali

Mijozda AllowedIPs tunnelga kirishga ruxsat berilgan manzillarni sanaydi, wg-quick esa har bir yozuvni oddiy marshrutga aylantiradi. Demak, bu ishning mijoz yarmi bitta satr.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Endi xuddi shu mijoz uchun serverning yozuvi bilan solishtiring. U server mijozga nima yuborishini tasvirlaydi, bu odatda mijozning tunnel manzili, xususiy quyi tarmoq emas.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Bu ikkisini almashtirish men eng ko'p ko'radigan xato. 10.20.0.0/16 ni serverning peer bo'limi ostiga qo'yish butun quyi tarmoq o'sha mijoz ortida degani, va bu saytdan saytga da'vo, ruxsat emas. Hech bir peer ning AllowedIPs iga mos kelmaydigan paketlar jimgina tashlab yuboriladi, shuning uchun noto'g'ri yozuv aynan brandmauer muammosiga o'xshaydi.

Marshrutlarni o'zingiz boshqarsangiz, [Interface] ostida Table = off o'rnating va kerakli marshrutni qo'shing. Unda hech narsa avtomatik qo'shilmaydi, shuning uchun marshrut interfeysni ko'taradigan narsa ichida bo'lishi kerak.

OpenVPN: marshrutni itarib yuboring, so'ng u yetib borganiga ishonch hosil qiling

Oddiy serverda o'zgarish server konfiguratsiyasida mijozlar hovuzi yonidagi bitta direktiva.

push "route 10.20.0.0 255.255.0.0"

Mijoz ulanganda uni qo'shadi. Xato rejimi o'sha profil redirect-gateway ni ham itarib yuborganda yoki kimdir allaqachon route-nopull qo'shganda ko'rinadi: birinchisi sessiyani to'liq tunnelga aylantiradi, ikkinchisi siznikini ham qo'shib, itarib yuborilgan barcha marshrutni tashlaydi.

To'liq tunnel serveriga qarshi tor xatti-harakat kerak bo'lgan mijoz faqat o'zi xohlamagan qismlarni e'tiborsiz qoldirishi kerak. OpenVPN 2.4 va undan keyingi versiyalarda pull-filter aynan shu uchun mavjud.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Manzil oilalarini alohida saqlang: itarib yuborilgan IPv4 marshrut IPv6 ga hal qilinadigan ichki xizmat uchun hech narsa qilmaydi, va o'sha xizmat tunnel orqali muvaffaqiyatsiz bo'ladi, qolgan hamma narsa yaxshi ko'rinadi.

Xususiy quyi tarmoq VPN serverida emas, balki boshqa mijoz ortida bo'lsa, serverga xabar berish kerak. client-config-dir orqali har bir mijoz uchun iroute 10.20.0.0 255.255.0.0 bo'lgan fayl qo'shing, shuningdek mos route ni ham, boshqa mijozlar yo'lni o'rganishi uchun. iroute bo'lmasa, serverning o'sha prefiksni aynan o'sha tunnel orqali yuborishga asosi yo'q.

IPsec: trafik selektorlari kelishishi kerak

IPsec da itarib yuboriladigan marshrut yo'q. Ikki tomon tunnel ichida qaysi manzillar borligini kelishadi, kelishilgan selektorlardan tashqari trafik esa shifrlanmaydi va u orqali yuborilmaydi. strongSwan mijozida selektorlar ochiq.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Agar shlyuz ikki tomonda ham 0.0.0.0/0 bilan konfiguratsiya qilingan bo'lsa, IKEv2 torayishi odatda bola SA ni ikki taklifning kesishmasigacha kamaytiradi, bu esa kerakli natija. Ba'zi shlyuzlar buning o'rniga o'z konfiguratsiyalangan selektorlariga mos kelmaydigan taklifni rad etadi, va jurnal o'shanda marshrut shikoyati o'rniga muvaffaqiyatsiz bola SA ko'rsatadi. Bu sodir bo'lganda o'zgarish shlyuzga tegishli, chunki mijoz marshruti qarshi tomon qabul qilmaydigan selektor uchun tunnel yarata olmaydi.

Windows da o'rnatilgan mijoz xuddi shu qarorni ikki sozlama ortiga yashiradi. Tunnel bo'linishi yoqilgan bo'lishi kerak, prefiks esa profilga ro'yxatdan o'tkazilishi kerak.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Prefiksni ro'yxatdan o'tkazish uni qayta ulanishdan keyin ham saqlab qoladi, qo'lda qo'shilgan marshrut buni qilmaydi.

Oxirgi nuqta va DNS ni qarordan tashqarida saqlang

VPN oxirgi nuqtasi tunnelsiz ham yetib boriladigan bo'lib qolishi kerak, aks holda tunnel o'z ichiga qulaydi. Faqat 10.20.0.0/16 marshrutlanganda bu avtomatik, chunki oxirgi nuqta ommaviy manzil. To'liq tunnel profilida bunday emas, va klient tunnel ko'tarilishidan oldin oxirgi nuqtaga aniq xost marshruti kerak.

DNS bu marshrut itarish siz uchun qabul qilmaydigan ikkinchi qaror. Ichki nomlar odatda faqat xususiy tarmoq yeta oladigan hal qiluvchi orqali hal qilinadi. Server DNS serverini itarib yuborsa, har bir nom u orqali o'tadi; yubormasa, ichki nomlar yo muvaffaqiyatsiz bo'ladi, yo ommaviy tarzda siz o'ylamagan narsaga hal qilinadi. Bo'lingan DNS ichki hal qiluvchida bitta qidiruv domenini saqlaydi, lekin bu mijoz qo'llab-quvvatlashiga bog'liq, shuning uchun uni marshrutlashning yon ta'siri emas, alohida ish deb biling.

Tekshiring, so'ng qayta yuklang va yana tekshiring

Uch sinov marshrutlash savolini qamrab oladi. Yadrodan uzoq manzil qayerga ketishini so'rang, quyi tarmoqning ichidan biror narsa oling, so'ng oddiy ommaviy so'rov hali ham odatdagi ulanish orqali chiqishini tasdiqlang.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Birinchi satr interfeysni nomlaydi. Agar u sizning jismoniy interfeysingizni nomlasa, marshrut hech qachon o'rnashmagan. Windows da Find-NetRoute -RemoteIPAddress 10.20.5.7 xuddi shu savolga javob beradi, va oxirgi sinov hali ham odatdagi manzilingizni ko'rsatishi kerak, VPN serverinikini emas.

So'ng qayta yuklang. Qo'lda qo'shilgan marshrutlar yo'qoladi, profildan, itarib yuborilgan konfiguratsiyadan yoki AllowedIPs dan kelgan marshrutlar qaytadi. Agar tor kirish qayta yuklashdan oldin ishlab, keyin muvaffaqiyatsiz bo'lsa, ayb marshrutda emas, tunnel qanday boshlanishida.

Uni tayyor deb atashdan oldin to'rt narsani tasdiqlang: prefiks tarmoq egasidan kelgan va hech qanday mahalliy narsa bilan qoplanmagan, qaytish yo'li bor yoki uni maskalash qoidasi almashtiradi, siz konfiguratsiya qilgan mexanizm platformangizda marshrutlashni bajaradigan mexanizm, va toza qayta yuklashdan keyin ham xuddi shu sinovlar o'tadi. StrongSwan ning yo'naltirish bo'yicha eslatmalari o'qishga arziydi, agar qaytish yo'li doim muvaffaqiyatsiz bo'ladigan qism bo'lsa.