Зошто барањата на dnsmasq излегуваат од VPN по DNS пренасочување

LAN клиентот правилно стигнува до својот VPN, а сепак неговите DNS барања се појавуваат на погрешниот нагорен канал. Тоа не е истекување во вообичаената смисла; тоа е она што се случува кога рутерот престанува да го препраќа барањето и сам одговара на него. Пресретнувањето ја препишува дестинацијата на локален сокет, а потоа резолверот отвора втор, неповрзан разговор со сопствената изворна адреса и сопствената одлука за рутирање. Ознаките ставени на текот на клиентот го опишуваат првиот разговор и апсолутно ништо за вториот.

Ознаката не патува со барањето

Ознаките на пакетот живеат на conntrack запис и на пакетот во лет. Правилото REDIRECT го завршува тој лет: полезниот товар се предава на локален сокет, а оригиналниот запис ја завршил својата работа. Она што потоа го напушта рутерот е нов сокет создаден од процесот на резолверот, со адресата на самиот рутер како извор.

Затоа рутата на политиката врзана за адресата на LAN клиентот никогаш не се совпаѓа со барањето кон горниот тек. Новиот сокет ѝ припаѓа на dnsmasq, а не на клиентот, и јадрото ја оценува рутата за сопствениот сообраќај на рутерот. Правилата за извор, правилата за интерфејс и правилата за ознаки сите гледаат друга торка. Претпоставката дека ознаката се пренесува е најчестата грешка во ова поставување и таа е невидлива во снимање на страната на клиентот.

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

Каде препраќањето се претвора во локално решавање

Започнете со утврдување дали портата 53 се пренасочува, се преведува на друг домаќин или се остава на мира, бидејќи трите случаи се однесуваат различно. Пренасочувањето на локална порта го завршува препраќањето, додека преведувањето на друга машина го држи пакетот во движење и ја одржува торката на клиентот значајна.

Погледнете ги двата протокола. Резолвер достапен преку UDP и TCP ќе биде тестиран преку двата, а множество правила што покрива само UDP остава тивка дупка за големи одговори. Се бројат и правилата што ги создава сопствениот менаџер за конфигурација на рутерот, а уредувањето на создадена датотека обично губи од следното вчитување.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

Дајте му на резолверот сопствена излезна политика

Горниот тек специфичен за домен е најчистата алатка кога само некои имиња го бараат тунелот. dnsmasq прифаќа server линија ограничена на домен, со изборен интерфејс или изворна адреса што го насочува барањето надвор од избраниот уред. Токму тоа насочување го прави вториот разговор да го следи VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

Доменот, адресата и интерфејсот погоре се места за вашите сопствени вредности. Изборот на домен и контролата на излезот остануваат одделни одлуки: рутата мора да постои, изворната адреса мора да биде дозволена од резолверот кон горниот тек и огнениот ѕид мора да го дозволи одговорот. Самото насочување по интерфејс не е fail-closed, бидејќи исчезнат тунел може да го остави резолверот да падне на друг пат. Држете го секој јавен резервен пат далеку од именски простор што мора да остане приватен.

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

Што не може да зачува заедничкиот кеш

Еден препраќач со еден кеш служи секој LAN клиент, и тоа ја урива разликата што на некои мрежи им е потребна. Ако два клиенти мора да го решат истото име различно, заедничкиот сокет нема начин да врати кој клиент прашал. Политиката по клиент мора да живее во одделни примероци на резолверот или во функција за препраќање што го чува идентитетот.

Кешираниот одговор исто така не е доказ за новиот пат. Одговорот може да дојде од меморијата додека рутата кон горниот тек останува скршена.

Правилата за порта 53 не кажуваат ништо за апликациите што зборуваат DNS преку HTTPS или преку TLS. Тие барања никогаш не стигнуваат до пренасочувањето, затоа политика изградена само на порта 53 опишува подмножество од сообраќајот и треба да се документира како подмножество.

Проверете го вториот разговор, не првиот

Тестирајте со едно име што вие го контролирате и гледајте ги двете страни. Снимањето на страната на клиентот докажува дека барањето ја напуштило LAN; само страната на рутерот докажува каде отишло потоа.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Исчистете го кешот пред секој обид, бидејќи топлиот одговор крие скршен горен тек. Повторете преку TCP, потоа повторете со исклучен тунел за да видите што прави резолверот кога неговиот претпочитан пат го нема. Токму тоа последно однесување одлучува дали дизајнот е fail-closed или само среќен.