Жеке DNS атаулары VPN клиенттерінде неге сәтсіз болады және қайдан тексеру керек

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

Кез келген профильді өңдеуден бұрын клиенттің атаумен не істейтінін тексеріңіз. Linux-та resolvectl query files.corp.example жауапты қай қосылым мен қай шешуші жасағанын көрсетеді. Windows-та Resolve-DnsName files.corp.example жауап берген серверді және ол қайтарған мекенжайды көрсетеді.

Бірдеңені өзгертуден бұрын жауапты оқыңыз

Атау бірнеше миллисекунд ішінде NXDOMAIN болып қайтса, сұрау сіздің аймағыңызға ешқашан жетпеген және оның орнына қандай да бір жария немесе қонақүй шешушісі жауап берген. Ұзақ үзілістен кейін қайтса, жолда бірдеңе UDP 53 портын тастайды және клиент ақыр соңында қосалқы нұсқаға көшкен. Дұрыс мекенжаймен жауап берсе, бірақ қосылым әлі де тұрып қалса, іздеу тәртіпте және мәселеңіз маршруттауда немесе қызметтің өзінде.

Бұл үшке бөлу бір сағат болжамды үнемдейді. Ол сондай-ақ VPN-ге мүлдем тию керек пе, соны айтады: дұрыс жеке мекенжайға шешілетін атау шешуші жолын әлдеқашан дәлелдеген, сондықтан қалған жұмыс деректер жолында.

Шешушіні туннельдің ішінен таратыңыз

Клиенттер екі топқа бөлінеді. Біріне сервер қосылым орнатылғанда шешуші тағайындай алады; екіншісі баптауды ешбір шлюз қашықтан өзгерте алмайтын жергілікті файлда ұстайды.

OpenVPN бірінші топта. Серверде push "dhcp-option DNS 10.8.0.53" мен push "dhcp-option DOMAIN corp.example" басқару арнасымен түседі, бірақ клиент конфигурациясында pull әлі қосулы болса ғана. Қолмен өңделген және pull-filter ignore "dhcp-option" алып жүрген клиент оларды ешқашан көрмейді, ал сол бір жол «сервер оны итереді, бірақ менің ноутбугім келіспейді» деген таңғаларлық көп жағдайды түсіндіреді.

WireGuard екінші топта, өйткені протоколда опция келіссөзі мүлдем жоқ. Шешуші мен іздеу домені клиенттің өз [Interface] блогына DNS = 10.8.0.53, corp.example ретінде кіреді. wg-quick мұны resolvconf немесе systemd-resolved арқылы қолданады, ал Windows-та ресми клиент туннель тұрғанда ғана бар NRPT ережелерін орнатады: Get-DnsClientNrptPolicy оларды тізіп шығады, бұл клиенттің файлыңызды қашан да болса қолданғанын көрудің жылдам жолына айналдырады.

IPsec/IKEv2 ортада тұр. strongSwan-ның attr плагині пулдан алынған DNS серверін қайтара алады, ал Windows клиенті мұны әдетте қабылдайды, бірақ өз атау серверін бекіткен профиль шлюз ұсынғанның бәрінен басым болады. Linux клиентінде балама қол қадамы — resolvectl dns wg0 10.8.0.53, одан кейін resolvectl domain wg0 '~corp.example'; екеуі де интерфейспен бірге жоғалады, бұл туннельге байланған баптау үшін дәл керек нәрсе.

Әр сұрауды жұтып қоймай, жұрнақты шектеңіз

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

Ішке тек жеке жұрнақты жіберіңіз. systemd-resolved ішінде ~ басталатын домен тек маршруттауға арналған, яғни ~corp.example сол жұрнақ астындағы сұраулар сол қосылымның серверлеріне барады, ал қалғаны физикалық желіні пайдалануды жалғастырады дегенді білдіреді. Windows мұны атау кеңістігіне шектелген NRPT ережелерімен, macOS болса /etc/resolver/ астындағы қосымша шешуші файлымен жасайды.

Multicast атаулары өз жауабына лайық. .local атаулары дизайны бойынша link-local (RFC 6762), ал нүктеден нүктеге tun интерфейсі бұл multicast тобын тасымалдамайды, сондықтан қосымша жария шешуші оларды жарияламайды және ішкі unicast шешушіден олар туралы сұрасаңыз NXDOMAIN қайтады. avahi тәрізді шағылдырғыш шағылдыру режимінде екі сегментті қоса алады, бірақ бұл ешбір клиент талап ете алмайтын сервер жағындағы шешім. Принтер немесе NAS атаумен қолжетімді болуы керек болса, оның орнына аймағыңызда оған A жазбасын беріңіз.

Жауаптың қайта алатынын дәлелдеңіз

Қолжетімсіз мекенжайға нұсқайтын дұрыс жауап маршрутты тексермейінше дәл шешуші мәселесіндей көрінеді. Ядродан жауап қайда кететінін сұраңыз: ip route get 10.20.5.20 интерфейсті және пайдалырағы, пайдаланатын бастау мекенжайын атайды.

Шешушінің мекенжайын өзін бақылаңыз. DNS = 10.8.0.53 жанында AllowedIPs = 10.20.0.0/16 бар клиент сұрауларын физикалық NIC арқылы сыртқа жібереді, онда олар үнсіз өледі, өйткені шешуші туннель талап ететін ешбір префикстің ішінде емес. Бұл сәйкессіздік осы саладағы ең көп кездесетін бір себепті ақау және DNS баптауын рұқсат етілген префикстермен жол жол бойынша салыстырмайынша көрінбейді.

Қабаттасатын ауқымдар керісінше ақау тудырады. Жауап дұрыс, маршрут бар және ол дұрыс емес хостқа нұсқайды, өйткені үйдегі 192.168.0.0/24 туннельдің сол ауқымға маршрутынан нақтырақ. Бір жағын қайта нөмірлеңіз немесе тар маршрутты итеріп жіберіңіз, содан кейін қызмет хостының файрволы мен қайту жолын растаңыз; strongSwan-ның қайта бағыттау туралы жазбалары сол жолдың sysctl жағын қамтиды.

Сертификаттар адамдар DNS-ке артатын жеке сәйкестендіру тексерісі. Браузер шешу қатесінің орнына атау сәйкессіздігін хабарласа, іздеу әлдеқашан жұмыс істеген және түзету керек нәрсе — сертификаттағы SAN. HTTPS-ті атаумен тексеріңіз, ешқашан жалаң IP-мен емес.

Шлюзден емес, клиенттен қайта тексеріңіз

Пайдаланушы шағымданатын қолданбаның ішінде тексеріңіз, өйткені пәрмен жолындағы іздеу браузердің сол жолмен жүретінін дәлелдемейді. Chrome-ның қауіпсіз DNS-і мен Firefox-тың network.trr.mode баптауы жүйелік шешушіні толық айналып өте алады, ал олар солай жасағанда жеке атау не сәтсіз болады, не жария шешушіге ағып кетеді. resolvectl query-ні қолмен іске қосылған dig @10.8.0.53 files.corp.example-мен салыстыру екеуінің қайсысы болғанын айтады.

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

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