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

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

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

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