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.

Између два краја стоје три фазе: push мора да стигне, клијент га мора изложити, а hook га мора применити. Читајте средњу фазу у дневнику клијента, а последњу у стању резолвера, никада обрнуто, јер линија у дневнику доказује само прве две.

Потврдите да је push стигао и пронађите власника

Почните именовањем покретача: гола 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 из базена. Затворен порт изгледа тачно као покварен push, а исто и резолвер који одговара само из унутрашњости тунелске мреже. Поновите снимак након једног прекида и поновног повезивања, јер подешавања која се појаве при првом повезивању а нестану при другом су квар животног циклуса у hook-у, а не опција која недостаје.

Задржите једног власника и проверавајте по реду

Скрипта која преписује DNS адаптера на основу претпостављеног стања тунела дуплира конфигурацију коју профил већ носи, и тихо пада први пут кад је претпоставка погрешна. Преферирајте сопствена DNS подешавања везе или један документован hook, и запишите који сте изабрали да следећа особа не дода други.

Затворите петљу са четири провере: гурнута адреса присутна на вези тунела, интерно име разрешено као потпуно квалификовано име, исто име разрешено без суфикса, и обоје још тачно након једног поновног повезивања. Један снимак вам каже која од четири није прошла. Приручник за OpenVPN 2.6 наводи dhcp-option и скрипт директиве са њиховим напоменама за платформе.