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 увогуле не можа выкарыстоўваць слухач. Паспяховае развязанне не дае правоў на адрас, які яно вярнула, таму трымайце гэтыя два пытанні асобна.

Падобныя артыкулы