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

Поврзани статии