NAT VPN серверінде ме, әлде маршрутизаторда ма? Екеуі де жұмыс істей алады

Ноутбукте қосылымды әдепкі маршрут ретінде белгілеу — бәрі есте сақтайтын қадам, және ол шлюзде ештеңені өзгертпейтін қадам. Клиент енді интернет сұраныстарын туннельге жібереді; олар ғимараттан шыға ма, бұл жіберуге, аударма нүктесіне және клиенттің жеке мекенжайына жететін қайтару жолына байланысты. Екі конфигурация үшеуін де бере алады, олар жұмысты әртүрлі жерлерге қояды, және жауап бағытына ешкім жауапты болмағанда екеуі де сол бір тыныш түрде сәтсіздікке ұшырайды. Олардың арасынан таңдау клиент пулын кім көруі керек деген сұрақ.

Аңыз: клиент маршруты шығуды құрады

Мәжбүрлі туннельдеу — клиент жағындағы саясат: ол трафиктің физикалық адаптерге емес, VPN адаптеріне баратынын шешеді. Microsoft-тың VPN маршруттау құжаттамасы осы бөлу мен мәжбүрлеу мінезін сипаттайды, және бұл клиенттің маршруттар кестесі туралы мәлімдеме, сервердің жіберу ережелері туралы емес. Клиент тұрғысынан туннель — интернет өмір сүретін орын; шлюз тұрғысынан пакет жоғарыда ешкім естімеген мекенжайдан келді. Ешбір жақ жеке-дара қате конфигурацияланбаған, сондықтан ноутбук қасындағы адамға ақау сынған сервер сияқты көрінеді.

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

Алдымен жауап жолын сызыңыз

Кез келген параметрге қол тигізбес бұрын жолды нақты мекенжайлармен жазып шығыңыз және оған екі ықтимал аударма нүктесін белгілеңіз. Бұл зертхана 10.70.0.0/24 VPN пулын пайдаланады, онда бір клиент 10.70.0.37 мекенжайында, сервердің LAN мекенжайы 172.16.40.10, маршрутизатор 172.16.40.1 мекенжайында және қоғамдық шығу 203.0.113.40 мекенжайында.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

A нұсқасы: VPN серверінде аудару

Мұнда сервер пакетті маршрутизаторға бермес бұрын клиенттің көзін өзінің LAN мекенжайына аударады, ал маршрутизатор шығу жолында әдеттегі аудармасын қолданады. Жауапта маршрутизатордың салыстыруы сервер мекенжайын, сервердің салыстыруы клиент мекенжайын қалпына келтіреді. Қатарынан екі күйі бар аударма қалыпты және орындалатын, екеуі де жазылса; маршрутизаторға пулға дейінгі маршрут ешқашан қажет емес, және бұл осы конфигурацияның тартымдылығы.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT бар деп болжаудың орнына серверде әлдеқашан не бар екенін көру үшін осы оқылымдарды пайдаланыңыз. Блогтан көшірілген Linux masquerade ережесі Windows конфигурациясы емес, және VPN тыңдаушысы үшін хосттың файрволындағы рұқсат клиент сұранысын әрі қарай жіберу рұқсатымен бірдей саясат емес. Сервердің жіберу рөлін оның өз басқару интерфейсінен растаңыз, содан кейін аударманы бөлек қараңыз, өйткені екеуін көбіне орналастырудың әртүрлі бөліктері қосады.

B нұсқасы: пулды маршрутизаторға көшіру

Екінші конфигурацияда сервер клиенттің нақты көз мекенжайын жібереді, ал маршрутизатор оны аударады. Бұл клиент пулын шетте көрінетін күйде ұстайды, бұл маршрутизатор трафик саясаты, журналдау немесе тексеру орны болса көмектеседі. Бұл сондай-ақ маршрутизаторға 10.70.0.0/24 үшін 172.16.40.10 көрсететін қайтару маршруты, сонымен қатар сол префиксті шынымен қамтитын интернет саясаты қажет дегенді білдіреді; LAN ішкі желісі үшін жазылған ереже пулға тыныш түрде таралмайды.

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

DNS, IPv6 және қабылдауды айқын етіңіз

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

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

Қабылдау үшін рұқсат етілген бір клиент сұранысын және оның жауабын екі шекара арқылы қадағалаңыз және сол сәтте әр шекара қандай мекенжайды көруі керектігін жазыңыз. Дәл сол жазба келесі пул өзгерісін жоғалған қайтару маршруты кімдікі деген даудан гөрі бес минуттық өңдеуге айналдырады. Жазбаны билетте емес, клиент профилімен бірге сақтаңыз, өйткені келесі инженер ең алдымен профильді табады.