როდის იმსახურებს NAT ადგილს საიტ-საიტ VPN-ის შიგნით

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

გადაწყვიტეთ რომელი მისამართი გადაიწერება

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

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

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

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

მიჰყევით დატვირთვას და დაბრუნების გზას

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

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

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

შეადარეთ საიტის გადანომრვას

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

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

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

დაამტკიცეთ ორივე მიმართულება რეალური სესიით

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

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

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

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