WireGuard DNS DNAT: одржите повратни пут функционалним

DNAT преписује одредиште, а не извор. Одлучите како надређени resolver може да одговори пре него што додате правило, и држите свако поклапање уско.

Усмеравање DNS упита WireGuard клијента ка другом resolver-у изгледа као једно правило, а понаша се као три одлуке. Одредиште мора да се препише, пакет мора да се проследи, а одговор мора да нађе пут назад кроз стање превода које је направио gateway. Прескочите треће и упит мирно оде, док клијент чека заувек.

Узмите пример овлашћених клијената у 10.77.0.0/24 који долазе преко wg0, питају објављену адресу 10.77.0.1 и потребан им је resolver на 203.0.113.53. Надређена адреса је документациони чувар места, а не услуга која ради.

Преусмеравање упита мења само његово одредиште

Правило NAT одредишта у PREROUTING преписује адресу пре него што се донесе одлука о рутирању, па се пакет затим рутира ка новом одредишту уместо старог. Изворна адреса клијента није дотакнута том операцијом. Зато правило које изгледа потпуно ипак може да произведе тишину: захтев сада путује до resolver-а који никада није чуо за приватни опсег клијента. Gateway је превео једно поље и наследио други проблем.

Оба DNS транспорта захтевају одговарајућа правила, јер се клијент враћа на TCP када одговор буде скраћен.

Правила испод бирају једно долазно сучеље, један опсег клијената и једну оригиналну адресу одредишта. Ништа друго на gateway-у није погођено, а упит самог gateway-а уопште се не поклапа.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

Повратни пут је засебна одлука

Два распореда омогућавају да се одговор врати, а рани избор једног штеди сесију за отклањање грешака. Или надређени resolver има руту назад ка 10.77.0.0/24 кроз овај gateway, или gateway преводи извор на излазу тако да одговор стигне на адресу коју надређена страна већ зна. Оба раде; само једно одговара нивоу контроле који имате над надређеном страном.

Рутирање заслужује први покушај, јер чува адресу клијента видљивом за resolver и избегава други слој превода. Када је надређена страна ван ваше контроле, превод извора на конкретном излазном сучељу је практичан избор.

Ограничите тај превод једнако тесно као преусмеравање, иначе правило постаје NAT опште намене за све што се случајно поклопи:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

Пишите правила ужа него што задатак изгледа

Дозвола за прослеђивање припада истом обиму. Дозволите ток од клијента ка resolver-у и повратни саобраћај који conntrack већ препознаје, уместо да прихватите сваку DNAT везу на машини. Опште прихватање такође одобрава прослеђивања портова која немају везе са DNS-ом.

Сопствени resolver gateway-а је други кодни пут. Упит издат локално пролази кроз OUTPUT, па тестирање из љуске gateway-а не вежба ни правило PREROUTING ни политику прослеђивања. Зато локални тест може да прође док сваки клијент пада, а обрнуто је једнако често.

Ништа овде не покрива DNS преко HTTPS на порту 443 или DNS преко TLS на порту 853, и ништа не покрива IPv6. Клијент са конфигурисаним IPv6 resolver-ом радо ће игнорисати цео распоред.

Шта доказује свеж упит

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

Прва команда показује да ли се клијентски пут уопште решава, а друга приказује превод који је gateway заиста инсталирао, укључујући оба смера tuple-а. Мапирање које показује на исправан resolver са бројачем одговора заглављеним на нули је проблем повратног пута, а не филтрирања.

Пре него што било шта преусмерите, потврдите да resolver зна имена која очекујете. Замена која одговара на јавна имена, али не на вашу приватну зону претвара радну претрагу у NXDOMAIN који изгледа као покварен тунел. Тестирајте resolver директно, са gateway-а, пре него што се укључи клијентски пут. А референца за iptables екстензије документује семантику DNAT и masquerade на коју се ова правила ослањају.

Повезани чланци