პორტის გადამისამართება NAT-ის მიღმა არსებულ WireGuard peer-ზე: 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 მართავს firewall-ს, გამოხატეთ ნებართვა მარშრუტის წესად; ჩვეულებრივი host წესი გადაცემულ ტრაფიკს არ ფარავს.

კიდევ ორ NAT შრეს შეუძლია გზის გატეხვა მაშინაც, როცა პროქსის წესები სწორია. სახლის კავშირზე საჯარო მისამართი როუტერს ეკუთვნის და მის firewall-ში პორტის გახსნა არ არის იგივე, რაც პორტის გადაცემის ჩანაწერის შექმნა, რომელიც ამ პორტს პროქსიზე აგზავნის. პორტი, რომელიც გარედან ღიად გამოიყურება, მაშინ როცა არაფერი პასუხობს, ხშირად სწორედ ამ დაკავშირებას აკლდება.

NAT VPS-ზე პროვაიდერი საჯარო პორტს კერძო მისამართზე ასახვას უკეთებს. ასახვა უნდა შეესაბამებოდეს იმ პორტს, რომელსაც აცხადებთ, და შეუსაბამობა ზუსტად გატეხილ გვირაბს ჰგავს. WireGuard-ის კონფიგურაციის შეცვლამდე დაადასტურეთ პროვაიდერის ასახვა.

შეამოწმეთ დაბრუნების გზა და მიიღეთ ხარჯი

დაუკავშირდით ქსელიდან, რომელიც პროქსის LAN არ არის, შემდეგ შეამოწმეთ თარგმანის წყვილი, სანამ კავშირი ღიაა:

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

conntrack ჩანაწერმა უნდა აჩვენოს ორიგინალური tuple, თარგმნილი tuple და პასუხის მიმართულება. თუ პასუხი აკლია, peer გვირაბით არ აგზავნის, რაც ჩვეულებრივ ნიშნავს, რომ SNAT წესი არ გამოყენებულა ან peer-ის საკუთარმა firewall-მა ნაკადი ჩააგდო.

ერთხელ გადატვირთეთ, რომ დაამტკიცოთ PostUp-ის მიერ წესების ხელახალი გამოყენება, შემდეგ გააჩერეთ გვირაბი და დაადასტურეთ, რომ PreDown-მა ისინი წაშალა. მკვდარი წესები, რომლებიც გაწყვეტას გადაურჩება, არის მიზეზი იმისა, რომ შემდგომი ცვლილება არაპროგნოზირებად იქცევა.

ბოლოს, მიიღეთ რასაც SNAT ღირს. სერვისი ყოველ მოთხოვნას პროქსიდან მოსულად ხედავს, ამიტომ წვდომის ჟურნალები, კლიენტზე დაშვებული სიჩქარის ლიმიტები და დაშვებული მისამართების სიები აღარ განასხვავებს მომხმარებლებს. hairpin შემთხვევას საკუთარი წყაროს თარგმანი სჭირდება პროქსის LAN-ში მყოფი კლიენტებისთვის. თუ peer-ს ნამდვილი კლიენტის მისამართები სჭირდება, ალტერნატივა კლიენტის ქსელისკენ დაბრუნების მარშრუტია, რაც მეტი სამუშაოა, მაგრამ ინფორმაციას ინახავს.