Роумингтегі VPN клиенті кеңсе үшін қызметті хосттай ала ма?

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

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

Қосылу бағыты қызмет бағыты туралы ештеңе айтпайды

Клиент туннельді бастағанда, ол пайда болғаннан кейін екі бағыт та пайдалана алатын жолды ашады. Жаңа қосылым хабтан сол клиентке қарай кіре ала ма — бұл шлюз саясатының мәселесі, қосылған адамның қасиеті емес. Мысалы, маршрутталған OpenVPN хабында серверге клиенттің ішкі мекенжайына маршрут және тең дәрежелі қатынасқа рұқсат беретін қайта бағыттау қажет.

Роумингтегі ноутбуктердегі агентті сұрайтын түгендеу жүйесін немесе үйдегі жұмыс станциясынан сынақ API қажет әзірлеушіні елестетіңіз. Екеуі де кеңсе жағы әңгімені бастағанын қалайды, бұл әдеттегі клиенттен-серверге үлгісінің керісі.

Хостингтік қашықтан қолжетімділік өнімдері бұл жерде әртүрлі, және бұл айырмашылық ақау емес. Кейбір басқарылатын VPN қызметтері қосылған клиенттерге қарай сұралмаған қосылымдарды әдейі бөгейді, себебі олардың моделі клиенттен-ресурсқа, ресурстан-клиентке емес. Әріптесіңізге оның ноутбугі сервер бола алады деп уәде бермес бұрын өнімнің құжатталған архитектурасын оқыңыз.

Портты ашпас бұрын қайтару жолын қадағалаңыз

Жолдың үш бөлігі бар: шлюзде клиенттің ішкі мекенжайына нұсқайтын маршрут, нақты қоңырау шалушыға рұқсат беретін саясат және мақсатта тыңдайтын қызмет. Әр бөлік түрліше істен шығады, сондықтан «VPN қосулы» деген сөз дерлік ештеңе айтпайды.

Жақсы жаңалық — ішкі жол клиенттің үй маршрутизаторында портты қайта бағыттауды қажет етпейді. Қызметті үй WAN мекенжайында емес, туннель мекенжайында жариялаудың мәні осында, өйткені үй WAN мекенжайында әшкерелену мен NAT ережелері мүлде басқа болар еді. Үй маршрутизаторы кеңседен келетін қосылымды hairpin жасаудан да бас тартуы мүмкін, сол себепті WAN жолы VPN-ге қатысы жоқ себептермен істен шығады. Трафикті туннель ішінде ұстау екі мәселені де бірден болдырмайды.

Мақсат жағын да тексеріңіз. Тек 127.0.0.1-ке байланған қызмет туннель интерфейсіне келетін қосылымды қабылдай алмайды, шлюз маршруттары қаншалықты дұрыс болса да. Портқа тек жергілікті қосымша желіден рұқсат беретін хосттың firewall ережесі де кеңсе трафигін тастайды, және бұл ереже жоғарыдағы VPN саясатынан тәуелсіз.

Атаулар мен мекенжайлар — дизайн шешімдері

Туннель ішіндегі мекенжай автоматты түрде ат болып қалмайды. Өзіңіз басқаратын жеке DNS жазбасы ашу протоколы туннельден өтеді деп үміттенуден анағұрлым анық, өйткені жергілікті multicast ат шешуі жергілікті сегментте қалады және қосымша желіаралық DNS болмайды.

Мекенжай тұрақтылығы да соншалықты маңызды. Егер VPN клиенттері қысқа жалдау пулынан алса, ноутбуктың ішкі мекенжайы сессиялар арасында өзгереді және оған құрылған әрбір бетбелгі, firewall ауқымы мен мониторинг тексерісі үнсіз бұзылады. Резервтеуді немесе құжатталған динамикалық жаңарту жолын пайдаланыңыз.

Атауды VPN сәйкестігінің иесімен келісіңіз, жазба, мекенжай бөлу және қолжетімділік саясаты үш бөлек билетте емес, бірге өзгерсін.

Қызметті сынаңыз, мүшелікті емес

Мақсаттан ненің және қай мекенжайда тыңдап жатқанын растаңыз, содан кейін шлюздің қайтару жолы туралы көрінісін растаңыз:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Енді кеңсе жағынан жаңғырық емес, нақты сұраныспен сынаңыз. Қызметке қарсы сәтті curl жолды, саясатты және тыңдаушыны бірден дәлелдейді, ал сәтті ping ICMP рұқсат етілгенін ғана дәлелдейді. Сұраныс сәтсіз болса, firewall-ды кеңейтіп үміттенудің орнына үш бөліктен кері жүріңіз.

Қолжетімділік сол әңгімеге жатады. Ноутбук ұйықтайды, желілер арасында жүреді және күн соңында ажырайды. Кез келген сағатта жауап беруі керек қызмет әрқашан қосулы хостқа тиесілі, ал барынша күш салынатын қызмет осы шектеу жазылып, клиентте қала алады.

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

Қатысты мақалалар