ორ WAN-იანი VPN პოლიტიკა რომელ პაკეტს უნდა დაემთხვეს?

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

დაასახელეთ ორი საუბარი

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

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

იპოვეთ, სად ხედავს თქვენი პოლიტიკა პაკეტს სინამდვილეში

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

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

დაადასტურეთ ტრანსპორტი, რომელზეც შეთანხმდით

UDP-ში ინკაფსულირებული IPsec-ისთვის RFC 3948 ESP-ს UDP-ის შიგნით ათავსებს და იყენებს არა ESP ნიშანს, რომ IKE საერთო პორტზე გასარჩევი დარჩეს. ჩვეულებრივი ESP IP პროტოკოლია და არა TCP ან UDP პორტი, ამიტომ პორტის ნომერზე დაწერილი ფაიერვოლის წესი მას საერთოდ არ დაემთხვევა. ეს განსხვავება განსაზღვრავს, სჭირდება თუ არა თქვენს WAN პოლიტიკას UDP წესი, პროტოკოლის წესი, თუ ორივე.

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

შეამოწმეთ დაბრუნების გზა, სანამ აიღებთ ვალდებულებას

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

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

გადაამოწმეთ ორივე ფენა ორი ჩაწერით

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

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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