OpenVPN жіберген DNS еленбейді: оны қай компонент қолданады

Журнал сервер жіберген опцияны көрсетеді, туннель қосулы, ал ішкі атаулар әлі шешілмейді. Резолверге тікелей сұраныс жауап береді, яғни сервер дұрыс, бірақ әр қолданба жергілікті маршрутизатордан сұрай береді. Клиентке жеткен нәрсе ұсыныс, резолвердегі өзгеріс емес, ал атауларды шешуге ие компонент Linux, Windows және macOS жүйелерінде әртүрлі. Опцияны иесінен ажыратқанда, төрт ақау барлық дерлік есепті қамтиды: hook жоқ, екі бәсекелес hook, бөлінген DNS жоба бойынша жұмыс істейді, немесе қысқа атауға сервер емес, суффикс қажет.

Жіберілген опция — ұсыныс, орнату емес

Серверде екі директива әсерді емес, ниетті сипаттайды:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Клиент конфигурацияланған резолвер алмайды. Ол орта айнымалыларын алады, foreign_option_1 және одан кейінгілерді, әр жіберілген жолға бір-бірден, ал жергілікті бір нәрсе оларды оқып, операциялық жүйенің резолвер күйін қайта жазуға тиіс. Linux жүйесінде әдепкі бойынша ешнәрсе мұны істемейді, сондықтан дұрыс сервер мен қосылған клиент әлі де LAN арқылы атауларды шеше алады.

Екі шеттің арасында үш кезең бар: жіберу жетуі керек, клиент оны ашуы керек, ал hook оны қолдануы керек. Ортаңғы кезеңді клиент журналынан, ал соңғысын резолвер күйінен оқыңыз, ешқашан керісінше емес, өйткені журнал жолы тек алғашқы екеуін дәлелдейді.

Жіберу жеткеніне көз жеткізіп, иесін табыңыз

Іске қосқышты атаудан бастаңыз: жалаң openvpn пәрмен, systemd данасы, NetworkManager немесе жеткізуші клиенті. Бұл hook қайда өмір сүре алатынын шешеді. systemd-resolved бар хостта, resolvectl status әр қосылымды нақты пайдаланылатын DNS серверлері мен іздеу домендерімен бірге тізіп шығарады, ал туннель қосылымы әрдайым tun0 деп аталмайды.

Егер жіберілген мекенжай журналда болып, бірақ ешбір қосылымда болмаса, интеграция жетіспейді. Егер ол қосылымда болып, сұраныстар әлі басқа жаққа шықса, мәселе мынада, қай сұраныстар сол қосылымды таңдайды. NetworkManager dns=dnsmasq файлында /etc/NetworkManager/NetworkManager.conf жергілікті қайта жіберушіні іске қосады, ол бөлінген DNS-ті әдейі қолданады: VPN доменінің ішіндегі атаулар VPN резолверіне барады, қалғаны бұрынғы жолын сақтайды. Бұл мінез-құлық барлық трафик көшеді деп күткенде ақау сияқты көрінеді; қосылым бойынша параметрлерді мынамен тексеріңіз nmcli connection show "My VPN", мұнда ipv4.dns және ipv4.dns-search құрылғы хабарлағанның артындағы мәндерді сақтайды, оны бүлінген деп атамас бұрын. Егер әр сұраныс шынымен VPN резолверіне жетуі керек болса, алып тастаңыз dns=dnsmasq -ты NetworkManager.conf файлынан және NetworkManager-ді қайта іске қосыңыз, бұл атауларды шешуді қосылым параметрлеріне қайтарады; әйтпесе бөлінген DNS-ті қалдырып, жіберілген домендер тізімін түзетіңіз.

Linux: опцияларды резолверге беріңіз

Тарату пакеттері бұл үшін hook ұсынады, ал клиентке оны іске қосуға рұқсат берілуі керек. systemd-resolved жоқ хосттағы әдеттегі орналасу:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved кезінде ескі resolv.conf скрипті елеулі ештеңе өзгертпеуі мүмкін, өйткені stub резолвер әр қосылым бойынша күйді сақтайды. update-systemd-resolved көмекшісі мынаны пайдаланатын hook пішінін құжаттайды up-restart және down-pre, бұл интерфейс бір қосылу әрекетінен ұзақ өмір сүргенде маңызды. Не таңдасаңыз да, күйге бір компонент ие болуы керек. NetworkManager жанына қатысы жоқ hook қосу бір қосылымға екі жазушы береді, ал нәтиже сонда конфигурацияға емес, реттілікке тәуелді болады.

NetworkManager жіберілген опцияны мүлде елемеген жағдай да бар: сервер мекенжайы қосылымның IPv4 параметрлеріне енгізілгенше солай болды, содан кейін резолвер күйі оның қолданылып жатқанын көрсетті. Скрипттерді қайта жазбас бұрын сынап көруге тұрарлық, өйткені бұл мәселені shell hook-інен туннельді әлдеқашан көтеріп жүрген қосылым профиліне көшіреді.

Windows пен macOS әртүрлі бөліктерді қолданады

Windows клиенті VPN адаптерінің DNS серверлерін шынымен орнатады, бірақ Windows әлі де интерфейсті метрика бойынша таңдайды және қысқа атауды кеңейту үшін әлі де суффикс қажет. Профильді емес, адаптер күйін растаңыз:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Егер мекенжай жоқ болса, оны мынамен орнатыңыз Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, содан кейін суффиксті адаптердің IPv4 қасиеттеріне қосыңыз, сонда fileserver болады fileserver.corp.example. Машина көлеміндегі SearchList мәні Tcpip\Parameters астында дәл солай істейді. Ұзын атау шешіліп, жалаң атау шешілмейтін жерде резолвер әлдеқашан дұрыс, ал кінә іздеу тізімінде. Түзетулер ретімен: мынаны жіберіңіз DOMAIN клиент суффиксті үйренуі үшін, сол суффиксті адаптердің немесе қосылымның іздеу тізіміне қосыңыз, және уақытша шара ретінде атауды мына жерге бекітіңіз hosts файлына, немесе LMHOSTS -не Windows жүйесінде; NetBIOS шолуы маршрутизатордан өтпейді, сондықтан кеңсе LAN-ында қысқа атау табатын хабарлама туннель клиентіне ешқашан жетпейді.

block-outside-dns block-outside-dns — Windows клиентінің мінез-құлқы, тасымалданатын профиль жолы емес, және оны Linux немесе macOS профиліне көшіру оны онда қайталамайды. Егер Windows жүйесінде ашық атаулар жұмыс істеп, ішкі атаулар істемесе, Кеңейтілген параметрлердегі адаптер ретін мынамен салыстырыңыз ipconfig /all. macOS жүйесінде қызмет бойынша резолвер реті жүйеге тиесілі, сондықтан мынаны пайдаланыңыз scutil --dns қай домен үшін қай резолвер сұралатынын көру үшін, және кез келген жеке хабарланған профиль түзетуін жалпы емес, клиентке тәуелді деп қараңыз.

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

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

Сұраныстың қайда кеткенін дәлелдеңіз

Бір іздеу кезіндегі түсірілім дауды шешеді: tcpdump -ni eth0 port 53 физикалық интерфейсте сұраныстарды көрсетеді, яғни олар туннельден тыс шығады және резолвер ешқашан ауыстырылмаған. dig @10.8.0.1 name.corp.example содан кейін қалған екі жағдайды ажыратады. Егер тікелей сұраныс жауап берсе, резолвер жұмыс істейді және клиент оны пайдаланбайды; егер уақыт бітсе, резолвер туннель арқылы қолжетімсіз және ешбір жергілікті өзгеріс көмектеспейді.

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

Қолжетімділік VPN хосттағы брандмауэрді де қамтиды, ол пулдан UDP және TCP 53-ке рұқсат беруі керек. Жабық порт дәл бүлінген жіберуге ұқсайды, тек туннель желісінің ішінен жауап беретін резолвер де солай. Бір рет ажыратып, қайта қосылғаннан кейін түсірілімді қайталаңыз, өйткені бірінші қосылуда пайда болып, екіншісінде жоғалатын параметрлер hook-тегі өмірлік цикл ақауы, ал жоқ опция емес.

Бір иесін ұстаныңыз және ретімен тексеріңіз

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

Циклді төрт тексерумен жабыңыз: жіберілген мекенжай туннель қосылымында бар, ішкі атау толық білікті атау ретінде шешіледі, сол атау суффикссіз де шешіледі, және екеуі бір қайта қосылудан кейін де ақиқат. Бір түсірілім төртеуінің қайсысы сәтсіз болғанын айтады. OpenVPN 2.6 нұсқаулығы тізіп шығарады dhcp-option және скрипт директиваларын платформалық ескертпелерімен бірге.