Сіздің VPN үш DNS серверін жібереді: қайсысы жауап береді?
Қосымша жазбалар резервтік нұсқа, домен бойынша маршрут немесе физикалық байланыстың қалдығы болуы мүмкін. Тізімді ағып кету деп атамас бұрын әрқайсысын өз аясына сәйкестендіріңіз.
Қосылғаннан кейін параметрлер бетін ашыңыз, үш DNS мекенжайы тізімделеді; аудит сұрағы — соның қайсысы соңғы сұранысыңызды өңдеді. Тек сан ештеңеге жауап бермейді, өйткені клиенттің жіберуі, физикалық интерфейс және домен бойынша саясат бәрі бір көрініске жазады. Бұл жазбалардың аялары әртүрлі, ал жауап берушіні позиция емес, ая шешеді. Көздерді бөлуден бастаңыз, содан кейін өзіңізге маңызды атауға ие болатын көзді тексеріңіз.
Тізім неге профиліңізден ұзын
VPN клиенті туннель байланысы үшін шешуші мекенжайларын жібереді, ал операциялық жүйе оларды физикалық интерфейсте бұрыннан бар нәрсенің қасында ұстайды. Маршрутизатор, корпоративтік DHCP жалдауы, екінші VPN және домен бойынша саясат әрқайсысы өз жазбасын қосады. Сондықтан беттегі үш мекенжай бір жұмысқа үш үміткер емес, үш ая болуы мүмкін. Санды ағып кетудің дәлелі деп оқу осы аудиттің бірінші қатесі.
Бір интерфейс ішінде клиент өз серверлерін шынымен кезекпен сынайды, сондықтан реттелген тізім мағынасыз емес. Кезек емес нәрсе — біріктірілген көрініс, онда профиль, физикалық байланыс және домен ережелерінің жазбалары бір ғана реттеусіз қатар тұрады. Осы айырмашылық нені тексеру керектігін шешеді: реттілік бір ая ішіндегі мінез-құлықты түсіндіреді, ал ая қалғанын түсіндіреді.
Шифрланған DNS суретті қолданбаның ішінен бұзады. Өзінің DNS-over-HTTPS шешушісі бар браузер немесе чат клиенті сұраныстарды операциялық жүйе тізімінен толық айналып өтіп жібереді, сондықтан параметрлер бетіндегі мекенжайлар қолданба ешқашан жасамаған трафикті сипаттайды. Атау қате шыққаны үшін профильді кінәламас бұрын қолданбаның өз шешуші параметрін тексеріңіз.
Үш тексерудің әрқайсысы нені айтады
Әр көз өз ізін басқа жерде қалдырады, ал бірде-бір команда барлығын көрсетпейді. Бұл — параметрлер бетінің қасында ұстауға тұрарлық сәйкестендіру:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved пайдаланатын жүйеде resolvectl status өкілетті, өйткені ол DNS-ті маршруттау домендерімен бірге әр байланыс үшін хабарлайды. macOS scutil --dns арқылы жауап береді, ол аясы бар шешушілерді сынау ретімен тізімдейді. Windows екі жартыға бөледі: әр интерфейс серверлері үшін Get-DnsClientServerAddress және суффикс ережелері үшін Get-DnsClientNrptPolicy. Нақты пайдаланылып жатқан шешушіге тиесілі команданы іске қосыңыз, өйткені контейнерлік орындалу ортасы мен жұмыс үстелінің шешушісі бар машинада бірден көбі орнатылған болуы мүмкін.
Аймағыңызға жауап бере алмайтын резервтік шешуші
Екінші жазба әдетте қолжетімділік үшін бар, ал қолжетімділік резерв атауларды білгенде ғана жұмыс істейді. Жария шешушіден ішкі хост атауын сұраңыз, ол NXDOMAIN қайтарады немесе сізге қатысы жоқ іздеу доменінен үлгілік жауап береді. Ешкім тексермеген ауысу керек болған сәтте дәл үзіліс тудырады.
Split DNS осыны болдырмау үшін бар: компания суффикстері аймақты ұстайтын шешушіге барады, ал жария атаулар әдепкі жолда қалады. Дизайн дұрыс, ол суффикстер тізімінің толықтығына тәуелді. Microsoft әр суффикс үшін шешуші саясатын құжаттайды, ол мұны Windows-та басқарады, және сол идея systemd-resolved-те маршруттау домендері және macOS-те аясы бар шешушілер ретінде көрінеді.
Резерв жауап бере алатын аймақтарды саясаттағы суффикстермен салыстырыңыз. Бұл салыстыру пайдаланушы туннель өзгерісінен кейін бір ішкі сайт шешілуін тоқтатты деп хабарламас бұрын олқылықты табады.
Саясат арқылы сұраңыз, оны айналып өтпей
Операциялық жүйенің шешушісі арқылы сұраңыз, өйткені серверге тікелей сұраныс саясатты айналып өтеді және сол сервер айтатын нәрсені ғана хабарлайды. Екі жауаптың арасындағы олқылық — бүкіл мәселе:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Егер жүйе сұранысы жеке мекенжайды қайтарса, ал тікелей сұраныс NXDOMAIN қайтарса, саясат жұмыс істейді және әлсіз жер — резерв. Егер екеуі де бірдей жария жауап қайтарса, атау сіз ойлаған аядан тыс шешіледі, ал суффикстер тізімі — қарайтын жер. Екі шығысты да сақтаңыз, өйткені шешуші туралы дау параметрлер бетінің скриншотынан гөрі екі жолмен тезірек бітеді.
Содан кейін сәтсіздік жолын жаттықтырыңыз, өйткені ешкім сынамаған резерв — болжам. Бір сұраныс үшін таңдаулы шешушіні қара қуысқа айналдырып, қай мекенжай қайтатынын бақылаңыз:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Сұраныс біткен бойда сол маршрутты жойыңыз, әйтпесе келесі адам жұмбақты мұра етеді. Егер сол терезеде ішкі атаулар әлі шешілсе, оларға көзделген аядан тыс бірдеңе жауап берді. Егер олардың орнына уақыты бітсе, резерв жоқ немесе дұрыс шектелген, және шешушінің өз журналы екеуінің қайсысы болғанын айтады.
Шешіңіз: ұстап қалу, шектеу немесе жою
Екінші шешушіні қажетті атау кеңістігіне жауап берсе және профиль астында қолжетімді болса, ұстап қалыңыз. Оны бір суффиксті ғана көруі керек болса шектеңіз, ал аясы да, құжатталған мақсаты да болмаса жойыңыз. Жұмыссыз жазба — пайдасыз болашақ ағып кету, ал жеткізушінің әдепкі мәні мақсат емес.
Нәтижені төрт баған түрінде жазыңыз: суффикс, шешуші, интерфейс және иесі. Ол жол кез келген скриншоттан тезірек келесі аудит сұрағына жауап береді және тізімді үнсіз қайта реттейтін клиент жаңартуынан аман қалады.