WireGuard DNS DNAT: захаваць працоўным зваротны шлях

DNAT перапісвае пункт прызначэння, а не крыніцу. Вырашыце, як вышэйшы рэзалвер зможа адказаць, перш чым дадаваць правіла, і трымайце кожнае супадзенне вузкім.

Направіць DNS-запыт кліента WireGuard на іншы рэзалвер выглядае як адно правіла, а паводзіць сябе як тры рашэнні. Пункт прызначэння трэба перапісаць, пакет трэба пераслаць, а адказ павінен знайсці дарогу назад праз стан трансляцыі, створаны шлюзам. Прапусціце трэцяе — і запыт спакойна сыйдзе, а кліент будзе чакаць вечна.

Вазьміце прыклад аўтарызаваных кліентаў у 10.77.0.0/24, якія прыходзяць праз wg0, запытваюць абвешчаны адрас 10.77.0.1 і маюць патрэбу ў рэзалверы на 203.0.113.53. Адрас вышэйшага ўзроўню — гэта падстаўка для дакументацыі, а не працоўная служба.

Перанакіраванне запыту змяняе толькі яго пункт прызначэння

Правіла DNAT для пункта прызначэння ў PREROUTING перапісвае адрас да прыняцця рашэння аб маршрутызацыі, таму пакет затым накіроўваецца да новага пункта прызначэння замест старога. Адрас крыніцы кліента гэтай аперацыяй не закранаецца. Менавіта таму правіла, якое выглядае поўным, можа ўсё яшчэ даваць цішыню: запыт цяпер ідзе да рэзалвера, які ніколі не чуў пра прыватны дыяпазон кліента. Шлюз пераклаў адно поле і атрымаў у спадчыну другую праблему.

Абодва транспарты DNS патрабуюць адпаведных правіл, бо кліент пераключаецца на TCP, калі адказ абрэзаны.

Правілы ніжэй выбіраюць адзін уваходны інтэрфейс, адзін дыяпазон кліентаў і адзін зыходны адрас прызначэння. Нішто іншае на шлюзе не закранаецца, а запыт ад самога шлюза не супадае зусім.

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

Шлях адказу — асобнае рашэнне

Дзве схемы дазваляюць адказу вярнуцца, і ранні выбар адной з іх эканоміць сеанс адладкі. Альбо вышэйшы рэзалвер мае маршрут назад да 10.77.0.0/24 праз гэты шлюз, альбо шлюз транслюе крыніцу на выхадзе, каб адказ прыйшоў на адрас, які вышэйшы ўзровень ужо ведае. Працуюць абодва; толькі адзін адпавядае ўзроўню кантролю, які вы маеце над вышэйшым узроўнем.

Маршрутызацыя заслугоўвае першай спробы, бо яна захоўвае адрас кліента бачным для рэзалвера і пазбягае другой праслойкі трансляцыі. Калі вышэйшы ўзровень па-за вашым кантролем, трансляцыя крыніцы на пэўным выхадным інтэрфейсе — практычны выбар.

Абмяжуйце гэтую трансляцыю так жа строга, як перанакіраванне, інакш правіла стане 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

Адсочванне злучэнняў трымае адлюстраванне ў пары, таму адказ перапісваецца назад у зыходны картэж кліента на зваротным шляху. Без выхаднога правіла рэзалвер адпраўляе свой адказ на прыватны адрас, да якога не можа дабрацца, і кліент бачыць тайм-аўт замест памылкі.

Пішыце правілы вузей, чым выглядае задача

Дазвол на перасыланне належыць да таго ж абсягу. Дазвольце паток ад кліента да рэзалвера і зваротны трафік, які conntrack ужо распазнае, замест таго каб прымаць кожнае DNAT-злучэнне на машыне. Суцэльны дазвол таксама санкцыянуе перанакіраванні портаў, якія не маюць дачынення да DNS.

Уласны рэзалвер шлюза — гэта іншы шлях кода. Запыт, выдадзены лакальна, ідзе праз OUTPUT, таму тэставанне з абалонкі шлюза не запускае ні правіла PREROUTING, ні палітыку перасылання. Вось чаму лакальны тэст можа прайсці, пакуль кожны кліент падае, і зваротнае сустракаецца гэтак жа часта.

Тут нічога не ахоплівае DNS праз HTTPS на порце 443 або DNS праз TLS на порце 853, і нічога не ахоплівае IPv6. Кліент з наладжаным рэзалверам IPv6 будзе спакойна ігнараваць усю схему.

Што даказвае свежы запыт

Адсочванне злучэнняў памятае ранейшыя адлюстраванні, таму запыт, адпраўлены да змены правіла, можа быць адказаны са старога стану і зрабіць новае правіла падобным на зламанае. Пачніце з новага порта крыніцы і, там дзе кліент кэшуе адказы, з новага імя.

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

Першая каманда паказвае, ці ўвогуле вырашаецца шлях кліента, а другая — трансляцыю, якую шлюз фактычна ўсталяваў, уключаючы абодва кірункі картэжа. Адлюстраванне, накіраванае на правільны рэзалвер, з лічыльнікам адказаў, які застыў на нулі, — гэта праблема зваротнага шляху, а не фільтрацыі.

Пераканайцеся, што рэзалвер ведае імёны, якія вы чакаеце, перш чым нешта перанакіроўваць. Замена, якая адказвае на публічныя імёны, але не на вашу прыватную зону ператварае працоўны пошук у NXDOMAIN, які выглядае як зламаны тунель. Праверце рэзалвер напрамую, са шлюза, перш чым задзейнічаць шлях кліента. А даведка па пашырэннях iptables апісвае семантыку DNAT і masquerade, на якую абапіраюцца гэтыя правілы.

Падобныя артыкулы