OpenVPN DNS на пролазнику: dnsmasq и обим заштитног зида

Покрените dnsmasq на адреси тунела, дозволите DNS само из скупа клијената, гурните разрешивач, затим тестирајте директне упите и сопствену претрагу апликације.

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

Слушалац је локална услуга с два смера

Унутра, клијент шаље упит на адресу тунела пролазника на порту 53. Напоље, демон прослеђује тај упит свом конфигурисаном узводном серверу. Обе половине морају да раде и отказују на различите начине.

Истек који пријави клијент и истек који се види на пролазнику нису иста грешка.

Вежите адресу тунела, не сваку адресу

Посвећена инстанца dnsmasq за овај посао потребна је изричита адреса слушања, начин везивања који подноси појаву тунела након покретања и један јасан узводни сервер. Ово је најмања верзија коју користим:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic везује појединачне адресе и носи се с тим када се tun0 појави касније, што је важно на хосту на ком се VPN услуга поново покреће. Навођење loopback-а одржава локалне алате у раду без додавања јавног слушаоца. no-resolv спречава демона да наследи узводне сервере из конфигурације разрешивача хоста, а no-hosts спречава ову инстанцу да објави hosts датотеку пролазника. Ниједна од тих опција не даје никоме дозволу да упитује услугу.

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

Дозволите DNS улаз, не транзит тунела

Правила заштитног зида која ово омогућавају су правила локалног улаза ограничена на интерфејс тунела, скуп клијената, адресу пролазника и порт 53. Два правила, по једно за протокол, довољна су:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS ради преко TCP-а као и преко UDP-а, па правило само за UDP оставља велике одговоре у отказу на начин који изгледа повремено. Ово нису ufw route дозволе и не смеју да постану широка дозвола на tun0. Редослед је важан колико и садржај: раније правило које одбацује сав улаз са tun0 и даље побеђује, а додавање дозволе испод коначног одбацивања не ствара ништа.

Ако је DNS пролазника сада део дизајна, намерно прегледајте ту ранију политику и запишите зашто.

Узводна половина је одвојен пут

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

Не додајте неограничен излаз тунела да би одговори радили; праћени одговори то не захтевају.

Гурните опцију, затим проверите предају

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

push "dhcp-option DNS 10.90.0.1"

Клијенту Linux-а из командне линије може да затреба интеграција разрешивача у његовом менаџеру веза, а управљаном уређају може да затреба ажуриран профил управљања. После повезивања потврдите активни разрешивач на клијенту уместо да претпоставите да је гурнута опција примењена. Када два механизма истовремено покушавају да поставе DNS, добијате трку која изгледа као трепереће разрешавање.

Циљ је један власник конфигурације разрешивача клијента, а гурнута опција је тај власник обично само када се платформа клијента слаже.

Тестирајте оно што сте заиста изградили

Упитајте једно приватно потпуно квалификовано име и једно дозвољено спољашње име директно према адреси тунела, преко UDP-а и TCP-а. Затим поновите уобичајеним путем претраге апликације.

Ако директни упити раде, а апликација и даље отказује, квар је у предаји, а не на серверу:

  • Клијент никада није применио гурнуту опцију.
  • Касније је постављен други разрешивач и победио је у трци.
  • Апликација користи сопствену библиотеку разрешивача или кеширан одговор.

Завршите потврдом да извор изван одобрене VPN стазе уопште не може да користи слушаоца. Успешно разрешавање не овлашћује адресу коју је вратило, зато држите ова два питања одвојено.

Повезани чланци