DNS турнат од OpenVPN се игнорира: кој компонент го применува

Дневникот ја покажува опцијата што серверот ја турна, тунелот е кренат, а внатрешните имиња уште не се разрешуваат. Директното барање до резолверот одговара, значи серверот е во ред, но секоја апликација продолжува да го прашува локалниот рутер. Она што стигна до клиентот е предлог, не промена во резолверот, а компонентот што го поседува разрешувањето имиња се разликува на 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, што е важно кога интерфејсот го надживува еден обид за поврзување. Што и да изберете, еден компонент мора да ја поседува состојбата. Додавањето неврзан hook покрај NetworkManager дава двајца пишувачи на истата врска, а резултатот тогаш зависи од редоследот, а не од вашата конфигурација.

Има и случај кога NetworkManager целосно ја игнорирал турнатата опција сето додека адресата на серверот не била внесена во IPv4 поставките на врската, по што состојбата на резолверот покажала дека е во употреба. Вреди да се проба пред да се препишуваат скрипти, зашто проблемот се преместува од shell hook во профилот на врската што веќе го носи тунелот.

Windows и macOS применуваат различни делови

Клиентот за Windows навистина ги поставува DNS серверите на VPN адаптерот, но 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 и скрипт директивите со нивните платформски забелешки.