Зашто dnsmasq упити излазе изван VPN-а након DNS преусмеравања

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

Ознака не путује са упитом

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

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

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

Где се прослеђивање претвара у локално разрешавање

Почните тако што ћете утврдити да ли је порт 53 преусмерен, преведен на другог хоста или остављен на миру, јер се три случаја понашају различито. Преусмеравање на локални порт завршава прослеђивање, док превођење на другу машину држи пакет у кретању и задржава tuple клијента смисленим.

Погледајте оба протокола. Резолвер доступан преко 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'

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

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

Upstream специфичан за домен најчишћи је алат када само нека имена требају тунел. dnsmasq прихвата server линију ограничену на домен, са необавезним интерфејсом или адресом извора која усмерава упит из изабраног уређаја. Управо то усмеравање чини да други разговор следи VPN.

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

Домен, адреса и интерфејс горе су заменске вредности за ваше сопствене. Избор домена и контрола излаза остају одвојене одлуке: рута мора да постоји, адресу извора мора да дозволи upstream резолвер и заштитни зид мора да дозволи одговор. Само усмеравање интерфејсом није 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

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