WireGuard DNS DNAT: შეინარჩუნეთ პასუხის გზა მუშა მდგომარეობაში

WireGuard-ის კლიენტის DNS მოთხოვნის სხვა resolver-ზე მიმართვა ერთ წესს ჰგავს და სამი გადაწყვეტილების მსგავსად იქცევა. დანიშნულება უნდა გადაიწეროს, პაკეტი უნდა გაიგზავნოს, და პასუხმა უნდა იპოვოს გზა უკან გეითვეის მიერ შექმნილ თარგმანის მდგომარეობაში. გამოტოვეთ მესამე და მოთხოვნა სუფთად გავა, სანამ კლიენტი სამუდამოდ დაელოდება.

ავიღოთ 10.77.0.0/24-ში ავტორიზებული კლიენტების მაგალითი, რომლებიც wg0-ით მოდიან, იკითხავენ გამოცხადებულ მისამართს 10.77.0.1 და სჭირდებათ resolver 203.0.113.53-ზე. ზედა მისამართი დოკუმენტაციის ჩანაცვლებაა და არა მუშა სერვისი.

მოთხოვნის გადამისამართება მხოლოდ მის დანიშნულებას ცვლის

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

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

პასუხის გზა ცალკე გადაწყვეტილებაა

ორი მოწყობა პასუხს უკან დაბრუნების საშუალებას აძლევს, და ერთის ადრე არჩევა დებაგინგის სესიას ზოგავს. ან ზედა resolver-ს აქვს უკან დაბრუნების მარშრუტი 10.77.0.0/24-ში ამ გეითვეის გავლით, ან გეითვეი გასასვლელზე თარგმნის წყაროს, რათა პასუხი მივიდეს მისამართზე, რომელიც ზედამ უკვე იცის. ორივე მუშაობს; მხოლოდ ერთი შეესაბამება თქვენს კონტროლს ზედაზე.

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

შეზღუდეთ ეს თარგმანი ისევე მკაცრად, როგორც გადამისამართება, თორემ წესი ზოგადი დანიშნულების 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

კავშირების თვალთვალი დაწყვილებულად ინახავს ასახვას, ამიტომ პასუხი უკან დაბრუნებისას კლიენტის თავდაპირველ tuple-ზე გადაიწერება. გასასვლელი წესის გარეშე resolver პასუხს კერძო მისამართზე აგზავნის, სადაც ვერ მიაღწევს, და კლიენტი შეცდომის ნაცვლად დროის ამოწურვას ხედავს.

წესები დაწერეთ უფრო ვიწროდ, ვიდრე დავალება ჩანს

გადაგზავნის ნებართვა იმავე არეალს ეკუთვნის. დაუშვით კლიენტიდან resolver-ისკენ ნაკადი და უკანა ტრაფიკი, რომელსაც conntrack უკვე ცნობს, ნაცვლად იმისა, რომ მანქანაზე ყოველი DNAT კავშირი მიიღოთ. ყოვლისმომცველი დაშვება პორტების გადაგზავნასაც აძლევს ნებას, რომელთაც DNS-თან კავშირი არ აქვთ.

გეითვეის საკუთარი resolver სხვა კოდის გზაა. ლოკალურად გამოცემული მოთხოვნა OUTPUT-ში გადის, ამიტომ გეითვეის shell-იდან ტესტირება არც PREROUTING წესს ავარჯიშებს და არც გადაგზავნის პოლიტიკას. ამიტომ ლოკალური ტესტი შეიძლება ჩააბაროს, სანამ ყოველი კლიენტი ვარდება, და პირიქითაც ისეთივე ჩვეულებრივია.

აქ არაფერი არ მოიცავს DNS-ს HTTPS-ის ზევით 443 პორტზე ან DNS-ს TLS-ის ზევით 853 პორტზე, და არაფერი არ მოიცავს IPv6-ს. IPv6 resolver-ით კონფიგურირებული კლიენტი მთელ მოწყობას სიხარულით უგულებელყოფს.

რას ამტკიცებს ახალი მოთხოვნა

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

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

პირველი ბრძანება აჩვენებს, საერთოდ იხსნება თუ არა კლიენტის გზა, ხოლო მეორე — თარგმანს, რომელიც გეითვეიმ რეალურად დააყენა, tuple-ის ორივე მიმართულების ჩათვლით. სწორ resolver-ზე მიმთითებელი ასახვა, რომლის პასუხების მთვლელი ნულზეა გაჭედილი, დაბრუნების გზის პრობლემაა და არა ფილტრაციის.

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