NAT arxasındakı WireGuard peer-inə port yönləndirmə: DNAT və SNAT

Brauzer https://203.0.113.10:8443 ünvanını sorğulayır, proxy bağlantını qəbul edir, WireGuard peer-indəki xidmət isə heç vaxt cavab vermir. DNAT qaydası öz işini görür; uğursuz olan hissə cavabdır. Paketi hər iki çevirmədən keçirərək izləyin və çatışmayan qayda aydın olacaq. Düzəliş düzgün hook-da bir əlavə NAT ifadəsidir, yeni tunel deyil.

Bir sorğunu başdan sona izləyin

Sorğu proxy-nin ictimai interfeysinə gəlir: mənbə müştərinin ictimai ünvanı, təyinat isə proxy ünvanıdır. nat PREROUTING-də DNAT qaydası təyinatı peer-in tunel ünvanına, 10.90.0.2-yə yenidən yazır. Sonra marşrut qərarı paketi wg0 vasitəsilə çölə göndərir və yönləndirmə yolu tamamlanır.

Peer-də paket indi orijinal ictimai mənbə ünvanını daşıyır, çünki heç nə onu yenidən yazmayıb. Xidmət bağlantını qəbul edir və cavabını öz defolt şlüzünə göndərir, bu da peer-in qarşısındakı ev marşrutlaşdırıcısıdır. Həmin marşrutlaşdırıcının heç görmədiyi axın üçün heç bir vəziyyəti yoxdur və ya paketi atır, ya da öz ictimai ünvanına çevirir, müştəri bunu qəbul etməyəcək.

Problemin bütünü asimmetriyadır: sorğu proxy-dən keçir, cavab isə birbaşa getməyə çalışır. Proxy-nin bağlantı izləməsi yalnız cavab proxy-dən geri qayıtdıqda kömək edir və mənbə ünvanı hələ də orijinal müştəriyə işarə etdiyi müddətcə cavab ora qayıda bilməz.

Geri çevirməni əlavə edin

Yönləndirilən axının mənbəyini proxy-nin tunel ünvanına çevirin, o, peer-ə yollanmazdan əvvəl. Sonra xidmət 10.90.0.1-ə cavab verir, proxy onu alır və paket müştəriyə qayıtmazdan əvvəl bağlantı izləməsi hər iki çevirməni tərsinə çevirir.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING qaydası qəsdən dardır: çevrilmiş təyinatla və tunel interfeysi ilə uyğunlaşır, ona görə də wg0-dan çıxan əlaqəsiz trafiki yenidən yazmır. Geniş masquerade qaydası da müştəri ünvanını gizlədərdi, amma bunu hər axın üçün edər və NAT cədvəlini yoxlamağı çətinləşdirərdi.

Qaydaları tunelin mövcud olduğu yerə qoyun

Tunel ünvanına və ya interfeysinə istinad edən qaydalar wg-quick onu qurduqdan sonra işləməlidir. İnterfeys PreUp-dan əvvəl yaradılır, lakin ünvanlar, MTU, DNS və marşrutlar sonra tətbiq olunur, PostUp isə bütün bunlar yerində olduqdan sonra işləyir. Əlavələri PostUp-a, silmələri PreDown-a qoyun.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Silmələr əlavələrlə token-token uyğun olmalıdır, o cümlədən multiport və interfeys uyğunluqları. Bir uyğunluqla fərqlənən silmə heç nə silmir və növbəti yenidən qoşulma qaydanın ikinci nüsxəsini əlavə edir. Bir neçə yenidən qoşulmadan sonra cədvəldə konfiqurasiya sətrinə aid etmək çətin olan dublikatlar olur.

Nəticəni iptables -t nat -S ilə yenidən qoşulmadan sonra yoxlayın. Əgər eyni qayda iki dəfə görünürsə, PreDown sətri uyğun gəlmir və təmizləmə səssizcə uğursuz olur.

Yönləndirmə, filtrləmə və digər NAT

IPv4 yönləndirməsini davamlı olaraq aktivləşdirin, sonra filtrləmə cədvəlində yönləndirilən axına icazə verin. DNAT FORWARD zəncirindən əvvəl baş verir, ona görə də filtr qaydası ictimai ünvana deyil, çevrilmiş təyinatla uyğunlaşır. Əgər firewall-u UFW idarə edirsə, icazəni marşrut qaydası kimi ifadə edin; adi host qaydası yönləndirilən trafiki əhatə etmir.

Proxy qaydaları düzgün olsa belə, iki başqa NAT qatı yolu yenə də poza bilər. Ev bağlantısında ictimai ünvan marşrutlaşdırıcıya aiddir və onun firewall-unda portu açmaq, o portu proxy-ə göndərən port yönləndirmə qeydi yaratmaqla eyni şey deyil. Çöldən açıq görünən, amma heç nə cavab verməyən port çox vaxt məhz həmin xəritələmədən məhrumdur.

NAT VPS-də provayder ictimai portu şəxsi ünvana xəritələyir. Xəritələmə elan etdiyiniz portla uyğun olmalıdır və uyğunsuzluq pozulmuş tunelə tam bənzəyir. WireGuard konfiqurasiyasını dəyişməzdən əvvəl provayderin xəritələməsini təsdiqləyin.

Geri yolu yoxlayın və qiymətini qəbul edin

Proxy-nin LAN-ı olmayan şəbəkədən qoşulun, sonra bağlantı açıq ikən çevirmə cütünü yoxlayın:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack qeydi orijinal tuple-ı, çevrilmiş tuple-ı və cavab istiqamətini göstərməlidir. Cavab yoxdursa, peer tuneldən göndərmir, bu da adətən SNAT qaydasının tətbiq olunmadığını və ya peer-in öz firewall-unun axını atdığını bildirir.

PostUp-ın qaydaları yenidən tətbiq etdiyini sübut etmək üçün bir dəfə yenidən başladın, sonra tuneli dayandırın və PreDown-ın onları sildiyini təsdiqləyin. Bağlantı kəsiləndən sonra qalan ölü qaydalar sonrakı dəyişikliyin gözlənilməz davranmasının səbəbidir.

Nəhayət, SNAT-ın nəyə başa gəldiyini qəbul edin. Xidmət hər sorğunu proxy-dən gələn kimi görür, ona görə də giriş jurnalları, hər müştəri üzrə sürət limitləri və ünvan icazə siyahıları artıq istifadəçiləri fərqləndirmir. Hairpin halı proxy-nin LAN-ındakı müştərilər üçün öz mənbə çevirməsini tələb edir. Əgər peer-ə həqiqi müştəri ünvanları lazımdırsa, alternativ müştəri şəbəkəsinə geri marşrutdur, bu daha çox işdir, lakin məlumatı qoruyur.