SNAT, DNAT და Masquerade: რას აკეთებს VPN-ის თითოეული NAT წესი

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

რას გადაწერს თითოეული წესი

წყარო NAT, ჩვეულებრივ იწერება SNAT, ცვლის ნაკადის წყაროს მისამართს, როცა ის ტოვებს მარშრუტიზატორს ან კარიბჭეს. მიმღები სერვისი პასუხობს თარგმნილ მისამართზე და მთარგმნელი ყუთი აბრუნებს ცვლილებას იმ მდგომარეობით, რომელიც ამ კავშირისთვის შეინარჩუნა. Linux-ში ეს მდგომარეობა conntrack-ში ცხოვრობს, ამიტომ conntrack -L ორიგინალურ და პასუხის წყვილებს გვერდიგვერდ ბეჭდავს.

დანიშნულების NAT, DNAT, სამაგიეროდ დანიშნულებას ცვლის. UDP 51820-ზე საჯარო მისამართზე გაგზავნილი პაკეტი შეიძლება გადაიწეროს შიდა WireGuard სერვერზე 10.8.0.2:51820-ზე. ასე აქვეყნებს სახლის მარშრუტიზატორი ან ღრუბლოვანი დატვირთვის გამანაწილებელი VPN-ის მსმენელს და ეს არაფერს ამბობს იმაზე, რისი გადატანაც გვირაბს შეუძლია შემდეგ.

Masquerade ეკუთვნის SNAT-ის ოჯახს. წესი არ ასახელებს მისამართს; იყენებს იმას, რაც გამავალ ინტერფეისს აქვს პაკეტის გასვლისას. Linux აძლევს მას საკუთარ სამიზნეს და ეს ჩვეულებრივი არჩევანია WAN ინტერფეისზე, რომელიც მისამართს DHCP-დან ან PPPoE-დან იღებს.

სად ცხოვრობს ასახვა, იქ განისაზღვრება ხარვეზი

ჩაწერეთ წყვილი ყოველ საზღვარზე: გვირაბამდე, მის შიგნით და საჯარო ინტერფეისზე. გვირაბის შიგნით ჩაჭერა კანონიერად განსხვავდება გარეთასგან და ვინც ორივეს ადარებს იმის ცოდნის გარეშე, სად ხდება თარგმანი, არასწორ ჰოსტს გაედევნება.

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

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

Masquerade თუ გამოკვეთილი SNAT

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

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

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

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

წესების კითხვა Linux კარიბჭეზე

დისტანციური წვდომის კარიბჭეს, რომლის კლიენტები 10.8.0.0/24-ზე არიან და WAN ინტერფეისს eth0 ჰქვია, სჭირდება ჩართული გადამისამართება და ფილტრის პოლიტიკა, რომელიც ნაკადს უშვებს, სანამ რომელიმე NAT წესი დაეხმარება. iptables-ის ვერსია ორივე მიმართულებას nat ცხრილში ინახავს:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables-ის ფორმა იყენებს იმავე ორ კაუჭს დასახელებული ინტერფეისითა და გამოკვეთილი ჯაჭვით:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

ორივე ნაწყვეტი ვარაუდობს, რომ ფილტრის ჯაჭვი უკვე იღებს გადამისამართებულ ნაკადს. NAT ნებართვის წესი არ არის და სწორად თარგმნილი პაკეტი მაინც შეიძლება ერთი ცხრილის შემდეგ გადაიგდოს. დაადასტურეთ ცოცხალი ასახვა conntrack -L-ით, დაადასტურეთ რა არის ჩატვირთული nft list ruleset-ით ან iptables-save -t nat-ით, შემდეგ ჩაიწერეთ ორივე ინტერფეისზე, რომ ნახოთ მისამართის ნამდვილად შეცვლა.

მარცხის რეჟიმები, რომლებიც ცუდ წესს ჰგავს

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

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

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

საკონტროლო სია წესის შენახვამდე

ჯერ დაასახელეთ მიმართულება: წყარო, დანიშნულება თუ ორივე. შემდეგ დაადგინეთ, ვინ უნდა ინახავდეს მდგომარეობას — კარიბჭე, ზედა მარშრუტიზატორი თუ IPsec-ის პარტნიორი — და დაადასტურეთ, რომ პასუხის გზა მის გავლით ბრუნდება. შეზღუდეთ წესი იმ კლიენტების დიაპაზონით, დანიშნულებითა და ინტერფეისით, რომლებიც ნამდვილად გულისხმობთ, და წინასწარ გადაწყვიტეთ, შორეულმა ბოლომ კარიბჭე უნდა ნახოს თუ კლიენტის ორიგინალური მისამართი.

შეამოწმეთ კლიენტიდან და არა კარიბჭიდან. კარიბჭეზე მდებარე ბრაუზერს შეუძლია კლიენტის თარგმანის წესი სრულად გვერდი აუაროს, ამიტომ იქ მომუშავე გვერდი გვირაბზე არაფერს ამტკიცებს. გაგზავნეთ ერთი კლიენტიდან წამოსული მოთხოვნა, დააკვირდით მრიცხველებსა და conntrack ცხრილს და გაიმეორეთ გვირაბის ხელახალი დაკავშირებისა და WAN მისამართის შეცვლის შემდეგ, თუ რომელიმე მათგანი შესაძლებელია იქ, სადაც მუშაობთ.