Интерна имена не раде на VPN-у док се јавни сајтови нормално резолују

Један корисник пријављује да се име интранет домаћина не резолује преко VPN-а. Други извештај, са истог лаптопа, каже да тест цурења и даље показује упите које одговара локални резолвер. Звуче као један проблем, а то су два, са различитим доказима, и уобичајена поправка за први погоршава други. Раздвојите их пре него што додирнете било какву поставку.

Два симптома која нису једна грешка

То што се интерно име не резолује значи да је питање отишло негде где нема одговора за њега. Упити који напуштају тунел значе да је питање отишло на погрешно место чак и када је одговор био доступан. То су супротне грешке: једна је одговор који недостаје, друга је додатно одредиште.

Замка је у томе што додавање канцеларијског резолвера свуда поправља прво и гарантује друго. Додавање јавног резолвера свуда чини супротно.

Запишите оба запажања са временском ознаком, па прођите кроз четири провере испод по реду.

Резолвер ког адаптера добија питање

На Windows-у DNS клијент бира сервере према редоследу везивања адаптера, а тунелски адаптер није аутоматски први. Отворите напредна подешавања адаптера и померите везу за даљински приступ изнад физичког адаптера, па се поново повежите да би промена важила за нову сесију.

Редослед везивања је само прва половина. Клијент такође мора да зна која имена припадају том адаптеру, а то је питање суфикса, а не редоследа.

Ставите резултат ipconfig /all са радне машине поред резултата са лаптопа, оба снимљена док је тунел активан. Радна машина ће показати DNS суфикс специфичан за везу на свом канцеларијском адаптеру, а лаптоп можда неће показати ниједан на тунелу. Та разлика објашњава читаву класу извештаја типа „сервер је ту, а име и даље не ради“, јер без суфикса кратко име се никада не допуњава у зону коју опслужује канцеларијски резолвер.

Кратком имену треба суфикс пре него што му треба рута

Куцање неквалификованог имена домаћина тражи од резолвера да погоди домен. Погодак долази са листе суфикса везане за везу, а ако је та листа празна, упит одлази као једна ознака коју ниједна приватна зона неће препознати.

Копирајте суфикс са радне машине у IPv4 својства VPN адаптера на картици DNS, па се поново повежите. На Linux-у еквивалент је домен претраге на тунелској вези, који systemd-resolved излаже по вези, а не глобално.

Држите две поставке одвојено у белешкама. Суфикс мења шта се пита; адреса резолвера мења кога се пита. Поправка једног док је други погрешан даје резултат који изгледа случајно.

Питајте резолвер директно, па онда име

Директан упит канцеларијском резолверу одваја проблем имена од проблема путање, јер потпуно заобилази избор резолвера у клијенту.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Прва команда тражи од одређеног сервера потпуно квалификовано име. Ако одговори, резолвер и путања до њега су у реду и грешка је у избору или суфиксу. Ако истекне време, адреса је погрешна или недоступна и проблем је у рутирању, а не у DNS-у. Друга команда показује шта се дешава са кратким именом, а трећа исписује конфигурацију резолвера по вези на systemd домаћину.

Пазите на одговоре са џокер знаком, које неке мреже враћају за непозната имена. Одговор који изгледа уверљиво није доказ да је одговорио намеравани сервер, зато упоредите враћену адресу са оном коју интерна услуга стварно користи. Ако адреса припада паркинг страници или проксију, резолвер је одговорио, али одговор никада није био ваш. Та разлика штеди сат времена јурења тунела који је радио све време.

На Linux-у, VPN клијент који преписује /etc/resolv.conf у потпуности замењује локалне резолвере. vpnc излаже DNSUpdate no да то заустави, а systemd-resolved може да усмери само наведене домене на тунелску везу. Оба приступа задржавају јавна имена на локалном резолверу док интерна имена шаљу у канцеларију.

Цурења су правило, а не поље за потврду

Резолуција имена је UDP размена на порту 53, па тунел који преноси веб саобраћај али не UDP оставља упит на физичкој путањи. Докажите то снимањем на физичкој NIC картици док се резолује јавно име. Упит видљив на том интерфејсу у читљивом облику значи да га тунел не преноси.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ако се упит појави на том интерфејсу у читљивом облику, тунел га не преноси. Поправка је правило које дозвољава порт 53 само ка резолверу који је VPN потиснуо и одбацује остала одредишта, уз конфигурацију клијента која тихо не одбацује потиснуту опцију.

Последњи део је важнији него што изгледа. Покрените OpenVPN са route-nopull и потиснута DNS опција нестаје заједно са рутама, осим ако се филтер повлачења прошири да је задржи. а клијент који игнорише dhcp-option DNS наставиће да користи оно што је имао пре. Свака промена на страни сервера захтева нову сесију да би ступила на снагу, јер се листа резолвера доставља када се тунел подигне, а застарела сесија наставља да показује старо стање.

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