VPN арқылы тек бір жеке қосалқы желіні қалай жіберуге болады

Бір жеке қосалқы желіні туннель арқылы, ал қалғанын әдеттегі жолыңызбен өткізу кішкентай өтініш, бірақ қателесудің көп жолы бар. Нәтижені split tunneling деген жазуы бар құсбелгі емес, шешімнің қай жерде орындалатыны шешеді: клиенттің өз маршрут кестесінде, сервер жіберетін маршрутта немесе екі жақ келісетін саясатта. Қате қабатты таңдасаңыз, не ешқашан қаламаған толық туннельге, не қарсы жақ қабылдаудан бас тартатын туннельге бастайтын маршрутқа тап боласыз. Кез келген конфигурацияны ашпас бұрын мен үш шартты тексеру қолданамын, содан кейін төмендегі механизмдердің бірін таңдаймын.

Дизайнды шешетін үш шарт

Біріншіден, сізге желі иесінен нақты префикс пен маска керек. 10.x желісі префикс емес; 10.20.0.0/16 префикс болып табылады. Оның үйдегі LAN-мен, Docker көпірімен немесе сіз іске қосқан басқа VPN-мен қабаттаспайтынын тексеріңіз, өйткені қабаттасу маршрутты екіұшты етеді және ядро сіз ойламаған жазбаны таңдайды.

Екіншіден, қайтарылатын трафикке кім жауап береді. Пакетті туннельге бағыттау оны тек VPN серверіне жеткізеді. Егер қосалқы желі клиенттер пулыңызға қайтатын маршруты жоқ басқа маршрутизатордың артында болса, сервер трафикті маскалауы керек, әйтпесе сол маршрутизатор пулыңызды үйренуі керек. Клиент жағындағы ешбір маршрут жоқ қайтару жолын түзетпейді.

Үшіншіден, орындау нүктесі. Кейбір клиенттер маршрут орнатады, қалғанын операциялық жүйе жасайды. Басқалары саясатты келіседі, ал шлюз қабылдамайтын саясат мүлдем туннель жасамайды: пакеттер айқын қатесіз тасталады. Бірдеңе жазбас бұрын осы екеуінің қайсысы сіздікі екенін анықтаңыз.

WireGuard: AllowedIPs — маршрут кестесі

Клиентте AllowedIPs туннельге кіруге болатын межелерді тізімдейді, ал wg-quick әр жазбаны кәдімгі маршрутқа айналдырады. Сондықтан бұл тапсырманың клиенттік жартысы бір жол.

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

Енді сол клиент үшін сервердің жазбасымен салыстырыңыз. Ол сервердің клиентке не жіберетінін сипаттайды, бұл әдетте клиенттің туннель мекенжайы, жеке қосалқы желі емес.

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

Осы екеуін ауыстыру — мен ең жиі көретін қате. 10.20.0.0/16-ті сервердің peer бөлімінің астына қою бүкіл қосалқы желі сол клиенттің артында дегенді білдіреді, ал бұл рұқсат емес, сайттан сайтқа деген талап. Ешбір peer-дің AllowedIPs-іне сәйкес келмейтін пакеттер үнсіз тасталады, сондықтан қате жазба дәл брандмауэр мәселесіне ұқсайды.

Маршруттарды өзіңіз басқарсаңыз, [Interface] астында Table = off орнатып, қалаған маршруты қосыңыз. Сонда ештеңе автоматты түрде қосылмайды, сондықтан маршрут интерфейсті көтеретін нәрсенің ішінде болуы керек.

OpenVPN: маршрутты жіберіңіз, содан кейін оның жеткеніне көз жеткізіңіз

Қарапайым серверде өзгеріс сервер конфигурациясындағы клиент пулының қасындағы бір директива.

push "route 10.20.0.0 255.255.0.0"

Клиент қосылған кезде оны қосады. Сәтсіздік режимі сол профиль redirect-gateway-ті де жібергенде немесе біреу route-nopull-ті бұрын қосқанда көрінеді: біріншісі сессияны толық туннельге айналдырады, екіншісі сіздің маршрутыңызды қоса, жіберілген барлық маршрутты тастайды.

Толық туннельді серверге қатысты тар мінез қажет клиент өзіне керек емес бөліктерді ғана елемеуі керек. OpenVPN 2.4 және одан кейінгі нұсқаларда pull-filter дәл осы үшін бар.

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

Мекенжай отбасыларын бөлек ұстаңыз: жіберілген IPv4 маршруты IPv6-ға шешілетін ішкі қызметке ештеңе бермейді, және сол қызмет туннель арқылы сәтсіз аяқталады, қалғаны дұрыс көрінгенімен.

Жеке қосалқы желі VPN серверінде емес, басқа клиенттің артында болса, серверге хабарлау керек. client-config-dir арқылы әр клиентке iroute 10.20.0.0 255.255.0.0 бар файл қосыңыз, оған қоса сәйкес route, басқа клиенттер жолды үйренуі үшін. iroute болмаса, сервердің сол префиксті дәл сол туннель арқылы жіберуге себебі жоқ.

IPsec: трафик селекторлары келісуі керек

IPsec-те жіберетін маршрут жоқ. Екі жақ туннель ішінде қандай мекенжайлар болатынын келіседі, ал келісілген селекторлардан тыс трафик шифрланбайды және ол арқылы жіберілмейді. strongSwan клиентінде селекторлар айқын.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Егер шлюз екі жақта да 0.0.0.0/0-пен конфигурацияланған болса, IKEv2 тарылуы әдетте балалық SA-ны екі ұсыныстың қиылысына дейін азайтады, бұл күтілетін нәтиже. Кейбір шлюздер оның орнына өз селекторларына сәйкес келмейтін ұсынысты қабылдамайды, сонда журнал маршруттау шағымының орнына сәтсіз балалық SA көрсетеді. Бұл орын алса, өзгеріс шлюзге қатысты, өйткені клиент маршруты қарсы жақ қабылдамайтын селектор үшін туннель жасай алмайды.

Windows-та кіріктірілген клиент сол шешімді екі параметрдің артына жасырады. Туннельді бөлу қосулы болуы керек, ал префикс профильде тіркелуі керек.

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

Префиксті тіркеу оны қайта қосылудан кейін сақтап қалады, мұны қолмен қосылған маршрут жасамайды.

Соңғы нүкте мен DNS-ті шешімнен тыс ұстаңыз

VPN-нің соңғы нүктесі туннельсіз қолжетімді болып қалуы керек, әйтпесе туннель өзіне құлайды. Тек 10.20.0.0/16 маршрутталғанда бұл автоматты, өйткені соңғы нүкте жария мекенжай. Толық туннель профилінде олай емес, және клиентке туннель көтерілмес бұрын соңғы нүктеге айқын хост маршруты қажет.

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

Тексеріңіз, содан кейін қайта жүктеп, қайта тексеріңіз

Үш сынақ маршруттау мәселесін қамтиды. Ядродан алыс мекенжайдың қайда кететінін сұраңыз, қосалқы желінің ішінен бірдеңе алыңыз, содан кейін әдеттегі жария сұраныс әлі де әдеттегі байланысыңыз арқылы шығатынын растаңыз.

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

Бірінші жол интерфейсті атайды. Егер ол сіздің физикалық интерфейсіңізді атаса, маршрут ешқашан орнықпаған. Windows-та Find-NetRoute -RemoteIPAddress 10.20.5.7 сол сұраққа жауап береді, ал соңғы сынақ әлі де әдеттегі мекенжайыңызды көрсетуі керек, VPN серверінің емес.

Содан кейін қайта жүктеңіз. Қолмен қосылған маршруттар жоғалады, ал профильден, жіберілген конфигурациядан немесе AllowedIPs-тен келген маршруттар қайтады. Егер тар қатынас қайта жүктеуге дейін жұмыс істеп, кейін сәтсіз болса, кінә маршрутта емес, туннельдің қалай басталатынында.

Оны дайын деп атамас бұрын төрт нәрсені растаңыз: префикс желі иесінен келген және жергілікті ештеңемен қабаттаспайды, қайтару жолы бар немесе оны маскалау ережесі алмастырады, сіз конфигурациялаған механизм өз платформаңызда маршруттауды орындайтын механизм, және таза қайта жүктеуден кейін де сол сынақтар өтеді. strongSwan-ның жіберу туралы жазбалары оқуға тұрарлық, егер қайтару жолы үнемі сәтсіз болатын бөлік болса.