NAT-ын ард байгаа WireGuard peer рүү порт дамжуулах: DNAT ба SNAT

DNAT хүсэлтийг хүргэдэг ч хариу буруу хаягаас гардаг. Тохирох SNAT дүрэм нэмж, хоёуланг нь туннель тохируулсны дараа байрлуулна.

Хөтөч https://203.0.113.10:8443-ыг хүсэхэд прокси холболтыг хүлээн авч, WireGuard peer дээрх үйлчилгээ хэзээ ч хариу өгдөггүй. DNAT дүрэм ажлаа хийж байна; бүтэлгүйтэж буй хэсэг нь хариу юм. Пакетыг хоёр хөрвүүлэлтээр дамжуулан ажиглавал дутуу дүрэм тодорхой болно. Засвар нь зөв hook дахь нэг нэмэлт NAT мэдэгдэл, шинэ туннель биш.

Нэг хүсэлтийг эхнээс эцэс хүртэл ажигла

Хүсэлт проксийн нийтийн интерфейс дээр ирэх бөгөөд эх сурвалж нь клиентийн нийтийн хаяг, очих газар нь проксийн хаяг юм. nat PREROUTING дотор DNAT дүрэм очих газрыг peer-ийн туннелийн хаяг болох 10.90.0.2 руу дахин бичнэ. Дараа нь маршрутын шийдвэр пакетыг wg0-оор гаргаж, дамжуулах зам бүрэн болно.

Peer дээр пакет одоо анхны нийтийн эх хаягийг агуулж байна, учир нь юу ч түүнийг дахин бичээгүй. Үйлчилгээ холболтыг хүлээн авч, хариуг өөрийн өгөгдмөл гарц руу илгээнэ, энэ нь peer-ийн өмнөх гэрийн чиглүүлэгч юм. Тэр чиглүүлэгчид хэзээ ч хараагүй урсгалд ямар ч төлөв байхгүй тул пакетыг хаяна эсвэл өөрийн нийтийн хаяг руу хөрвүүлнэ, клиент үүнийг хүлээн авахгүй.

Тэгш бус байдал нь бүх асуудал: хүсэлт проксигоор явдаг бол хариу шууд явахыг оролддог. Проксийн холболт хяналт нь хариу проксигоор буцаж ирэхэд л тусална, эх хаяг анхны клиент рүү зааж байхад тэр тийшээ буцаж чадахгүй.

Буцах хөрвүүлэлтийг нэм

Дамжуулагдаж буй урсгалын эх сурвалжийг peer рүү явахаас өмнө проксийн туннелийн хаяг руу дахин бич. Дараа нь үйлчилгээ 10.90.0.1 рүү хариу өгч, прокси үүнийг хүлээн авч, пакет клиент руу буцахаас өмнө холболт хяналт хоёр хөрвүүлэлтийг эргүүлнэ.

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 дүрэм санаатайгаар нарийн: энэ нь хөрвүүлсэн очих газар болон туннелийн интерфейст тохирч, тиймээс wg0-оор санамсаргүй гарч буй хамааралгүй урсгалыг дахин бичихгүй. Өргөн masquerade дүрэм клиентийн хаягийг ч нуух байсан, гэхдээ үүнийг урсгал бүрд хийж, NAT хүснэгтийг шалгахад хэцүү болгох байсан.

Дүрмүүдийг туннель байгаа газарт байрлуул

Туннелийн хаяг эсвэл интерфейсийг дурдсан дүрмүүд wg-quick үүнийг тохируулсны дараа ажиллах ёстой. Интерфейс PreUp-аас өмнө үүсдэг боловч хаяг, MTU, DNS, маршрутууд дараа нь хэрэглэгдэж, PostUp энэ бүхэн байранд орсны дараа ажиллана. Нэмэлтүүдийг PostUp-д, устгалуудыг PreDown-д тавь.

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

Устгалууд нэмэлтүүдтэй токен токеноор тохирох ёстой, multiport болон интерфейсийн тохирлуудыг оруулан. Нэг тохирлоор ялгаатай устгал юу ч устгахгүй бөгөөд дараагийн дахин холболт дүрмийн хоёр дахь хуулбарыг нэмнэ. Хэдэн дахин холболтын дараа хүснэгтэд тохиргооны мөрт холбоход хэцүү давхардал үлддэг.

Үр дүнг iptables -t nat -S ашиглан дахин холболтын дараа шалга. Хэрэв ижил дүрэм хоёр удаа гарч ирвэл PreDown мөр тохирохгүй бөгөөд цэвэрлэгээ чимээгүйгээр бүтэлгүйтнэ.

Дамжуулалт, шүүлт болон нөгөө NAT

IPv4 дамжуулалтыг байнгын болгон идэвхжүүлж, дараа нь шүүлтийн хүснэгтэд дамжуулагдаж буй урсгалыг зөвшөөр. DNAT нь FORWARD гинжинээс өмнө болдог тул шүүлтийн дүрэм нийтийн хаягтай биш, хөрвүүлсэн очих газартай тохирно. Хэрэв UFW галт ханыг удирддаг бол зөвшөөрлийг маршрутын дүрмээр илэрхийл; энгийн host дүрэм дамжуулагдаж буй урсгалыг хамардаггүй.

Проксийн дүрмүүд зөв байсан ч өөр хоёр NAT давхарга зам эвдэж болно. Гэрийн холболтод нийтийн хаяг чиглүүлэгчид хамаарах бөгөөд түүний галт хананд порт нээх нь тухайн портыг прокси руу илгээх порт дамжуулалтын бичлэг үүсгэхтэй ижил биш. Гаднаас нээлттэй мэт харагдаж байгаа ч юу ч хариу өгдөггүй портод ихэвчлэн яг тэр зураглал дутмаг байдаг.

NAT VPS дээр үйлчилгээ үзүүлэгч нийтийн портыг хувийн хаяг руу буулгадаг. Зураглал нь таны зарласан порттой тохирох ёстой бөгөөд зөрүү нь эвдэрсэн туннельтай яг адил харагдана. WireGuard-ийн тохиргоог өөрчлөхөөс өмнө үйлчилгээ үзүүлэгчийн зураглалыг баталгаажуул.

Буцах замыг шалгаж, өртгийг хүлээн зөвшөөр

Проксийн LAN биш сүлжээнээс холбогдож, дараа нь холболт нээлттэй байхад хөрвүүлэлтийн хосыг шалга:

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

conntrack бичлэг анхны tuple, хөрвүүлсэн tuple болон хариуны чиглэлийг харуулах ёстой. Хэрэв хариу байхгүй бол peer туннелээр илгээхгүй байгаа бөгөөд энэ нь ихэвчлэн SNAT дүрэм хэрэглэгдээгүй эсвэл peer-ийн өөрийн галт хана урсгалыг хаясан гэсэн үг.

PostUp дүрмүүдийг дахин хэрэглэж байгааг батлахын тулд нэг удаа дахин ачаалж, дараа нь туннелийг зогсоож, PreDown тэдгээрийг устгасныг батал. Холболт тасарсны дараа үлддэг үхсэн дүрмүүд нь дараагийн өөрчлөлт урьдчилан таамаглашгүй ажиллах шалтгаан юм.

Эцэст нь SNAT-ийн өртгийг хүлээн зөвшөөр. Үйлчилгээ хүсэлт бүрийг проксигоос ирсэн гэж хардаг тул хандалтын логид, клиент тутмын хурдны хязгаар, зөвшөөрөгдсөн хаягийн жагсаалт хэрэглэгчдийг ялгахаа больсон. Hairpin тохиолдолд проксийн LAN дахь клиентүүдэд өөрийн эх хөрвүүлэлт хэрэгтэй. Хэрэв peer-т клиентийн жинхэнэ хаяг хэрэгтэй бол хувилбар нь клиентийн сүлжээ рүү буцах маршрут бөгөөд энэ нь илүү их ажил боловч мэдээллийг хадгална.

Холбоотой нийтлэлүүд