დისტანციურ /24-ზე წვდომა გვირაბის გავლით: NETMAP, DNAT თუ მარშრუტი?
მთელი პრეფიქსის NETMAP-ით დამისამართება, ჰოსტზე DNAT წესების დამატება ან რეალური დიაპაზონის მარშრუტიზაცია — და გადაწყვეტილება იმის მიხედვით, თუ რა უნდა დაინახოს მოშორებულმა მხარემ და ვის შეუძლია ტრაფიკის დაწყება.
გვირაბის ბოლო წერტილის უკან არსებულ ქვექსელზე სამი გზით შეგიძლიათ მოხვდეთ და ფაქტების შეგროვების ერთი წუთი ჩვეულებრივ ორ მათგანს გამორიცხავს. ფაქტებია: უნდა გაარჩიოს თუ არა იქაურმა სერვერებმა მომხმარებლები, შეეცდება თუ არა იქიდან ვინმე თქვენს დიაპაზონთან დაკავშირებას და ვის შეუძლია მოშორებული როუტერის რედაქტირება. უპასუხეთ ამ სამს და დიზაინი თავად აირჩევა. დანარჩენი ვარაუდობს, რომ თქვენ მართავთ ბოლო წერტილს და შეგიძლიათ მისი firewall-ის რედაქტირება.
სამი ვარიანტი და რას ცვლის თითოეული სინამდვილეში
პრეფიქსის დამისამართება, ჰოსტზე DNAT და მარშრუტიზებული პრეფიქსი ერთსა და იმავე ორ დიაპაზონს შორის გადაადგილებს პაკეტებს, მაგრამ სხვადასხვა რამეს ცვლის. დამისამართება ქმნის ალიას დიაპაზონს და გზაში არითმეტიკულად გადაწერს მისამართებს. ჰოსტის წესებიც გადაწერენ, ოღონდ თითოეული დანიშნულება ხელით არის მითითებული. მარშრუტიზებული პრეფიქსი არაფერს გადაწერს: პაკეტები ინარჩუნებენ რეალურ მისამართებს და ორივე მხარე თანხმდება, სად ცხოვრობს ეს მისამართები.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
გამორიცხვა დაიწყეთ მოშორებული მხრიდან, სადაც შეზღუდვების შეცვლა ყველაზე რთულია. თუ იქაური სერვერი კლიენტის მისამართებს ლოგებში წერს, ნებადართულ სიასთან ამოწმებს ან სხვა სისტემას გადასცემს, წყაროს თარგმნა მის ერთადერთ იდენტიფიკატორს ანადგურებს. თუ მოშორებულ მხარეს შემოსვლაც სჭირდება, თარგმნა სრულიად გამორიცხულია, რადგან იქ არავინ იცის, რომ ალიასი არსებობს. მხოლოდ მაშინ, როცა მოშორებული მხარე მხოლოდ მოთხოვნებს პასუხობს, იაფი ვარიანტები უსაფრთხო ხდება.
პრეფიქსების წყვილები და რატომ უნდა დაემთხვეს ზომები
NETMAP არის nat ცხრილის სამიზნე, რომელიც იდენტური სიგრძის პრეფიქსების წყვილზე მუშაობს. მას შიგნით თითო მისამართის ცხრილი არ აქვს: ის აცლის პრეფიქსს, ინარჩუნებს ჰოსტის ბიტებს და ხელახლა ამაგრებს მათ ახალ პრეფიქსს, ამიტომ /24 აისახება /24-ზე და არასოდეს /25-ზე. პოზიცია განსაზღვრავს მიმართულებას: დანიშნულების დამთხვევა PREROUTING-ში გადაწერს, სად მიდის პაკეტი, ხოლო წყაროს დამთხვევა POSTROUTING-ში გადაწერს, საიდან მოვიდა.
ჰოსტი 192.168.2.17-ზე თქვენს კლიენტებს ჩანს როგორც 10.50.1.17 და ბოლო ოქტეტი დეკორაცია არ არის — ორივე მხარეს ერთი და იგივე რიცხვია. ხვალ დაამატეთ ჰოსტი 192.168.2.40-ზე და მისი ალიასი იქნება 10.50.1.40, რედაქტირებადი წესის გარეშე.
კლიენტებს მაინც სჭირდებათ მარშრუტი ალიასის დიაპაზონისთვის, რომელიც თქვენს მოწყობილობაზე მიუთითებს, გარდა იმ შემთხვევისა, როცა ალიასი უკვე მისაწვდომ ქვექსელშია. gateway-ს ალიასისთვის მარშრუტი არ სჭირდება, რადგან დანიშნულების თარგმნა PREROUTING-ში სრულდება, მარშრუტის ძიებამდე. forwarding-იც ჩართული უნდა იყოს, თორემ kernel გადაწერის შემდეგ პაკეტს ჩამოაგდებს. ქვემოთ მოცემული სამი ბრძანება მთელი კონფიგურაციაა Debian-ის სტილის gateway-ზე, კლიენტებით br0-ზე, ალიასით 10.50.1.0/24-ზე და გვირაბით tun0-ზე.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEპასუხმა თავად უნდა მოძებნოს უკან დაბრუნების გზა
დანიშნულების გადაწერა მხოლოდ იმას წყვეტს, სად მიეწოდება პაკეტი. მოშორებულ სერვერს მაინც უნდა უპასუხოს მისამართს, რომელზეც თავად მიდის, და ამის მოწყობის ორი გზაა. თარგმნეთ წყარო, რათა პასუხები თქვენს მოწყობილობას დაუბრუნდეს, ან დატოვეთ წყარო უცვლელი და მოშორებულ მხარეს მიეცით მარშრუტი კლიენტების დიაპაზონისთვის.
გამავალი masquerade-ი უფრო მოკლე გზაა: ერთი წესი POSTROUTING-ში და მოშორებული მხარე ხედავს თქვენს გვირაბის მისამართს, ამიტომ საკუთარი მარშრუტი არ სჭირდება. ფასი ის არის, რომ ყველა მომხმარებელი ერთ მისამართად იკუმშება და თითო მომხმარებლის ლოგები აზრს კარგავს. წყაროს ხელუხლებლად დატოვება ინარჩუნებს ამ ინფორმაციას, მაგრამ მაშინ მოშორებულმა საიტმა კლიენტების დიაპაზონის პასუხები გვირაბის გავლით უნდა დააბრუნოს.OpenVPN სერვერზე ეს არის push-ით გაგზავნილი push "route 10.50.9.0 255.255.255.0", დამატებით route 192.168.2.0 255.255.255.0 ხაზი.
ძვირი მარცხი იმაშია, რომ ორივეს ნახევარი გააკეთო. თუ ტრაფიკის ნაწილს masquerade-ს უკეთებ, სანამ მოშორებული მხარე სხვა ტრაფიკისთვის უკან დაბრუნების მარშრუტსაც ატარებს, პასუხები ჩამოდის ინტერფეისზე, სადაც კავშირის თვალყურის დევნების ჩანაწერი არასოდეს უნახავს. კლიენტი იტყობინება timeout-ს მოთხოვნაზე, რომელიც სერვერმა მოწოდებულად ჩაწერა. ნაკადის ორივე მიმართულებამ ერთი და იმავე netfilter ინსტანცია უნდა გადაკვეთოს: ერთი gateway თარგმნის და არა ორი firewall სერიაში.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nჩანაწერი ორივე მიმართულებით წაიკითხეთ: საწყისი tuple დანიშნულებაზე თქვენს ალიასს ინარჩუნებს, ხოლო პასუხის tuple რეალურ მისამართს ატარებს. თუ პასუხის tuple არ არის, პრობლემა წესი კი არა, დაბრუნების გზაა. თუ PREROUTING-ის მრიცხველები არასოდეს გაიზარდა, პაკეტი ამ hook-ს არასოდეს მიმდგარა.
კოლიზიები და ძიება, რომელიც პირველი სრულდება
ორი სხვადასხვა დიაპაზონი შეიძლება დაეჯახოს და ორივე მარცხი გატეხილ გვირაბს ჰგავს და არა ცუდ წესს. ალიასი, რომელსაც იგონებთ, მთელ გზაზე გამოუყენებელი უნდა იყოს, ხოლო რეალური მოშორებული დიაპაზონი თქვენს ქსელში უკვე არ უნდა არსებობდეს. დუბლირება წარმოქმნის წყვეტილ ტრაფიკს არასწორი ჰოსტისკენ, რომლის დიაგნოსტირება უარის თქმულ კავშირზე უფრო რთულია. სანამ წესს დაამატებთ, routing ცხრილს ჰკითხეთ.
gateway-ზე, ip route get 192.168.2.17 უნდა მიუთითებდეს გვირაბის მოწყობილობაზე; ლოკალური bridge ნიშნავს, რომ მოშორებული დიაპაზონი დაჩრდილულია და ვერც ერთი nat წესი ვერ შეაკეთებს. თუ თქვენი ქსელი უკვე იყენებს 192.168.2.0/24-ს, ნაცვლად იმისა, რომ კოლიზიაზე დამისამართება დააწყოთ, მოშორებულ საიტს გადანომრეთ.
რეალური კლიენტიდან გამოცდა და შემდეგ შენარჩუნება
გამოსცადეთ მანქანიდან, რომელიც რეალურად გამოიყენებს ალიასს და არა gateway-დან, რადგან ლოკალურად წარმოებული ტრაფიკი PREROUTING-ს არასოდეს არ გადის ისე. გახსენით კავშირი ერთ ალიასიან ჰოსტთან და დააკვირდით, როგორ ჩნდება ერთად მრიცხველები და conntrack ჩანაწერი, შემდეგ დახურეთ და დაადასტურეთ, რომ ჩანაწერი ქრება. მოძველებული ჩანაწერი ნახევრად ღია კავშირზე მიუთითებს, რაც ჩვეულებრივ ნიშნავს, რომ პასუხი არასოდეს დაბრუნებულა.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17ორი-სამი წარმატებული კავშირი არითმეტიკას ამტკიცებს, მაგრამ გამძლეობაზე ან შემდეგ ინჟინერზე არაფერს ამბობს. წესები შეინახეთ იქ, საიდანაც ჩატვირთვის პროცესი კითხულობს მათ, რაც Debian-სა და Ubuntu-ზე ნიშნავს iptables-save > /etc/iptables/rules.v4 netfilter-persistent-ის ჩართული მდგომარეობით. გადატვირთვისას გამქრალი დამისამართება არაფერზე უარესია, რადგან გათიშვა დასაბრალებელი უახლესი ცვლილების გარეშე მოდის.
წესების გვერდით დატოვეთ ჩანაწერი: ალიასის დიაპაზონი, რეალური დიაპაზონი, წყვილის მიზეზი და რომელი მხარე შეიძლება იწყებდეს. ეს ჩანაწერი განასხვავებს დიზაინს წესების იმ გროვისგან, რომლის წაშლასაც ვერავინ ბედავს. ის აგვარებს მოგვიანებით გაჩენილ კითხვასაც, როცა მოშორებული საიტი ჰოსტს ამატებს და მისამართი, რომელიც არავის დაუკონფიგურირებია, უკვე პასუხობს. თუ ჩანაწერში წერია, რომ მოშორებულ მხარეს უკან დაბრუნების მარშრუტი სჭირდება, შემდეგმა ადამიანმა იცის, რომ masquerade-ის წესის მოცილება კავშირს წყვეტს. დოკუმენტაცია აქ იაფია, ხოლო NAT-ზე დამოკიდებულების ხელახლა აღმოჩენა ღამის სამ საათზე არა.