WireGuard DNS DNAT: cavab yolunu işlək saxlayın

WireGuard müştərisinin DNS sorğusunu başqa həllediciyə yönəltmək bir qayda kimi görünür, ancaq üç qərar kimi davranır. Təyinat yenidən yazılmalı, paket ötürülməli və cavab şlüzün yaratdığı tərcümə vəziyyətindən keçib geri yol tapmalıdır. Üçüncünü atsanız, sorğu sakitcə çıxır, müştəri isə sonsuza qədər gözləyir.

İcazəli müştərilərin 10.77.0.0/24 daxilində olub wg0 üzərindən gəlməsi, elan edilmiş ünvanı 10.77.0.1 sorğulaması və 203.0.113.53 ünvanında həllediciyə ehtiyac duyması nümunəsinə baxın. Yuxarı axın ünvanı işlək xidmət deyil, sənədləşdirmə üçün yer saxlayıcıdır.

Sorğunun yönləndirilməsi yalnız təyinatını dəyişir

PREROUTING zəncirindəki təyinat-NAT qaydası marşrut qərarı verilməzdən əvvəl ünvanı yenidən yazır, buna görə paket sonra köhnə yerinə yeni təyinat istiqamətində marşrutlaşdırılır. Müştərinin mənbə ünvanı bu əməliyyatdan təsirlənmir. Tam görünən qaydanın yenə də sükut yaratmasının səbəbi budur: sorğu artıq müştərinin şəxsi diapazonunu heç vaxt eşitməmiş həllediciyə gedir. Şlüz bir sahəni tərcümə etdi və ikinci problemi miras aldı.

Hər iki DNS nəqli uyğun qaydalar tələb edir, çünki cavab kəsiləndə müştəri TCP-yə keçir.

Aşağıdakı qaydalar bir gələn interfeysi, bir müştəri diapazonunu və bir orijinal təyinat ünvanını seçir. Şlüzdə başqa heç nə təsirlənmir və şlüzün öz sorğusu heç uyğun gəlmir.

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

Cavab yolu ayrı bir qərardır

Cavabın geri qayıtmasına iki quruluş imkan verir və birini erkən seçmək bir sazlama sessiyasına qənaət edir. Ya yuxarı axın həlledicisinin bu şlüzdən 10.77.0.0/24 şəbəkəsinə geri marşrutu var, ya da şlüz çıxışda mənbəni tərcümə edir ki, cavab yuxarı axının artıq tanıdığı ünvana çatsın. Hər ikisi işləyir; yalnız biri yuxarı axın üzərindəki nəzarətinizə uyğun gəlir.

Marşrutlaşdırma ilk cəhdi haqq edir, çünki müştərinin ünvanını həlledici üçün görünən saxlayır və ikinci tərcümə qatından qaçır. Yuxarı axın nəzarətinizdən kənardadırsa, konkret çıxış interfeysində mənbə tərcüməsi praktik seçimdir.

Bu tərcümənin əhatəsini yönləndirmə qədər dar saxlayın, əks halda qayda ona təsadüfən uyğun gələn hər şey üçün ümumi təyinatlı NAT-a çevrilir:

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

Bağlantı izləmə xəritələməni cütlükdə saxlayır, buna görə cavab geri qayıdarkən müştərinin orijinal kortejinə yenidən yazılır. Çıxış qaydası olmadan həlledici cavabını çata bilmədiyi şəxsi ünvana göndərir və müştəri xəta yerinə fasilə görür.

Qaydaları iş göründüyündən daha dar yazın

Ötürmə icazəsi eyni əhatəyə aiddir. Qutudakı hər DNAT bağlantısını qəbul etmək yerinə müştəri-həlledici axınına və conntrack-in artıq tanıdığı dönüş trafikinə icazə verin. Hər şeyi qəbul etmək DNS ilə heç bir əlaqəsi olmayan port yönləndirmələrinə də icazə verir.

Şlüzün öz həlledicisi fərqli kod yoludur. Yerli olaraq verilən sorğu OUTPUT-dan keçir, buna görə şlüz qabığından test etmək nə PREROUTING qaydasını, nə də ötürmə siyasətini işə salır. Yerli testin keçib hər müştərinin uğursuz olmasının səbəbi budur və əksi də eyni dərəcədə yaygındır.

Burada heç nə 443 portunda HTTPS üzərindən DNS-i və ya 853 portunda TLS üzərindən DNS-i əhatə etmir, IPv6-nı da əhatə etmir. IPv6 həlledicisi qurulmuş müştəri bütün quruluşu məmnuniyyətlə görməzliyə vuracaq.

Təzə sorğu nəyi sübut edir

Bağlantı izləmə əvvəlki xəritələmələri xatırlayır, buna görə qayda dəyişikliyindən əvvəl göndərilən sorğu köhnə vəziyyətdən cavablandırıla və yeni qaydanı pozulmuş göstərə bilər. Yeni mənbə portundan başlayın və müştəri cavabları keşlədiyi yerlərdə yeni addan istifadə edin.

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

Birinci əmr müştəri yolunun ümumiyyətlə həll edib-etmədiyini, ikincisi isə şlüzün həqiqətən quraşdırdığı tərcüməni, kortejin hər iki istiqaməti daxil olmaqla göstərir. Düzgün həllediciyə işarə edən, lakin cavab sayğacı sıfırda ilişib qalmış xəritələmə filtrləmə deyil, dönüş yolu problemidir.

Hər hansı yönləndirmədən əvvəl həlledicinin gözlədiyiniz adları bildiyini təsdiqləyin. İctimai adlara cavab verən, amma şəxsi zonanıza verməyən əvəzedici işlək axtarışı qırıq tunel kimi görünən NXDOMAIN-ə çevirir. Müştəri yolu işə qarışmazdan əvvəl həllediciyi birbaşa şlüzdən yoxlayın. iptables genişlənmələri arayışı isə bu qaydaların əsaslandığı DNAT və masquerade semantikasını sənədləşdirir.