შეინახეთ თუ SNAT-ით გადათარგმნეთ VPN კლიენტების IP მისამართები ღრუბლის საზღვარზე

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

სამი პირობა წყვეტს

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

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

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

მარშრუტი გაყალბების ნებართვა არ არის

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

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

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

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

რას ყიდულობს თარგმნა და რა ღირს

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

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

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

რელე სხვა ინტერფეისია

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

ეს თავსართი სანდოა მხოლოდ მაშინ, როცა backend მას პროქსისგან იღებს და არა სხვა რამისგან. nginx-ის ტერმინებით ეს ნიშნავს სანდო პარტნიორის ცალსახად დასახელებას, ნაცვლად იმისა, რომ ყველაფრის გვჯეროდეს, რაც მოდის:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

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

ჩაწერეთ, რას ხედავს თითოეული საზღვარი

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

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