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 дын жөнөтүү тууралуу эскертүүлөрү окууга татыктуу, эгер кайтаруу жолу дайыма ийгиликсиз болгон бөлүк болсо.