Pritunl-дың жеке DNS-і істемей ме? Тар resolver-маршрутын қосыңыз

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

Resolver сіздің клиент пулыңызды қабылдамайтынын растаңыз

Ақау қолжетімділікте емес, көзде екенін дәлелдеуден бастаңыз. Қосылған клиенттен жеке resolver-ге тікелей сұраныс жіберіп, сұраныстың уақыты бітетінін немесе бас тарту ретінде қайтатынын бақылаңыз. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 уақыты бітіп, сол сұраныс шлюзден сәтті болса, бұл resolver-дегі қатынау саясатын көрсетеді. SERVFAIL жауабы мүлдем басқа жерге, әдетте аймаққа немесе жоғарғы ағындағы жіберушіге сілтейді.

Сынамас бұрын клиенттің мекенжайын жазып алыңыз. Клиенттегі ip -4 addr show tun0 немесе консольде көрсетілген жалдау resolver-дің қай пулды көретінін айтады.

Содан кейін жолдың мүлдем бар екенін растаңыз. Resolver мекенжайын туннельге жіберетін маршрут – алғышарт, шешім емес; егер пакеттер ешқашан жетпесе, көз саясаты мүлдем қарастырылмайды. Клиентте ip route get 10.40.0.53 көмегімен тексеріңіз.

Барлығын аударудың орнына бір хост-маршрут қосыңыз

Pritunl-дың жеке DNS жөніндегі нұсқаулығы тар шешімді сипаттайды: resolver мекенжайы үшін NAT қосылған /32 маршруты, сол мекенжай клиенттердің DNS сервері ретінде таңдалады. Маршрут resolver көретін көзді тек DNS трафигі үшін өзгертеді. Қолданба трафигі өзі үшін таңдаған көзді сақтайтын дизайнды ұстанады.

Оны сервердің қолдау көрсетілетін маршрут иесі арқылы, бар маршруттарды қабаттасуға тексергеннен кейін конфигурациялаңыз. Жоғарыдағы мысалда межелі NAT қосылған 10.40.0.53/32, ал клиент пулы 10.90.0.0/24 болып қалады. Бір қызметті түзету үшін бүкіл жеке диапазонды аудармаңыз, өйткені клиенттің нақты мекенжайына сүйенетін әрбір төменгі саясат оның орнына шлюзді көре бастайды. Сынақ іздеуі кезінде resolver-дің сұраныс журналын бақылап, ол нақты алатын мекенжайды растаңыз. Тек хост-маршрут аударма немесе рұқсат туралы ештеңе дәлелдемейді.

Resolver әлі де аударылған көзге UDP және TCP арқылы рұқсат беруі керек, ал оның жауаптары қайта алуға қабілетті болуы тиіс. Көзді өзгерту жетіспейтін аймақты немесе жазбаны жасай алмайды.

Сұранысты сервер ме, әлде клиент пе жіберетінін шешіңіз

Pritunl сондай-ақ VPN Client DNS Mapping-ке байланған DNS-прокси конфигурациясын құжаттайды, онда сервер клиенттер үшін жоғарғы ағын сұраныстарын жібереді. Бұл модельде жоғарғы ағын көзі сервердің өз желілік контекстіне жатады, ал клиент жағындағы ерекшелік – дұрыс емес шешім.

Бірдеңе қоспас бұрын қай модель белсенді екенін анықтаңыз. Үш қабаттасатын түзету, прокси, клиенттегі resolver-ді ауыстыру және қолмен жасалған NAT скрипті әдетте ешкім мынаны анықтамағанын білдіреді: сұранысты қай компонент жіберуі керек. bootstrap-ты да тексеріңіз: тек жеке resolver туннель пайда болғанға дейін соңғы нүктені табудың жалғыз жолы бола алмайды, ал resolver-ге тұрақты өзгеріс қосылымнан ұзаққа созылмауы керек.

Жария веб-бетті емес, жеке іздеуді сынаңыз

Өзгерісті қолданып, қайта қосылғаннан кейін клиенттің әсер етуші resolver конфигурациясын қарап шығыңыз, содан кейін тек жеке аймақта бар екенін білетін атауды шешіңіз. Нақты серверсіз dig intranet.example.net клиенттің нақты нені қолданатынын көрсетеді. Одан кейін сол іздеу қайтарған мекенжайға сұраныс жіберіңіз, өйткені шешу мен қызметке қатынау – бөлек қадамдар. DNS-over-HTTPS арқылы жария сайттарды жүктейтін браузер операциялық жүйенің жеке resolver жолы туралы ештеңе дәлелдемейді. Жария қайталама resolver де ішкі аймақ үшін билік емес.

Resolver мекенжайын, /32 маршрутын және клиенттің DNS параметрін бірге сервер жазбаларына тіркеңіз. Осы конфигурацияның жартысы ғана қалпына келтірілсе, бастапқы ақау қайталанады.

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