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 път изобщо не може да използва слушателя. Успешното разрешаване не дава право на адреса, който е върнало, затова дръжте тези два въпроса разделени.

Подобни статии