რატომ ვერ გადის GRE და ESP AWS NAT-კარიბჭეში

გვირაბი ვერ მუშაობს, უსაფრთხოების ჯგუფი უკვე ყველა ტრაფიკს უშვებს, და დასკვნა ის არის, რომ AWS VPN-ს ბლოკავს. ის არაფერს ბლოკავს. მართული NAT-კარიბჭე გადასცემს გარე პროტოკოლების დოკუმენტირებულ ერთობლიობას, და ბუნებრივი GRE ან ბუნებრივი ESP მასში არ შედის, ამიტომ დამატებული არცერთი წესი კარიბჭეს მათ გადაცემას არ აიძულებს. ნებართვის წესი და ტრანსპორტირების უნარი ორი განსხვავებული რამ არის, და მათგან მხოლოდ ერთია თქვენს ხელში შესაცვლელად.

წესების ნაკრები პროტოკოლების ნაკრები არ არის

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

AWS-ის NAT-კარიბჭის პროტოკოლის სპეციფიკაცია მართული სერვისისთვის TCP-ს, UDP-ს და ICMP-ს ჩამოთვლის. ეს არის მთელი მხარდაჭერილი ნაკრები. სხვა IP პროტოკოლისთვის ნებართვის წესი მას ვერ გააფართოებს, რადგან წესი ფასდება იმაზე გაცილებით ადრე, სანამ კარიბჭის გადაცემის გზას მიაღწევენ.

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

PPTP გვიჩვენებს, რატომ იტყუება პორტის ტესტი

PPTP არის პორტის შემოწმების ყველაზე ნათელი ძველი მაგალითი, რომელიც არაფერს ამტკიცებს. ის ხსნის TCP კონტროლის კავშირს 1723 პორტზე და შემდეგ გვირაბის მონაცემებს GRE-ზე გადასცემს, რომელიც IP პროტოკოლი 47-ია. პროტოკოლი 47 TCP პორტი 47 არ არის, და ამ ორ რიცხვს ერთმანეთთან არაფერი აკავშირებს გარდა ციფრების გაზიარებისა.

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

იგივე მსჯელობა ვრცელდება ნებისმიერ პროტოკოლზე, რომლის კონტროლის არხი TCP ან UDP-ია, ხოლო მონაცემთა გზა ასეთი არ არის.

IPsec გადარჩება მხოლოდ როგორც UDP

IPsec არის შემთხვევა, როცა პასუხი პირობითია და არა ბრტყელი არა. AWS ადოკუმენტირებს NAT-ის გავლას, როგორც მხარდაჭერილ მოწყობას NAT-კარიბჭის გავლით IPsec-ისთვის. NAT-T-ის შეთანხმებისას ESP UDP-ში იფუთება და კარიბჭე ჩვეულებრივ UDP-ს ხედავს 50 პროტოკოლის ნაცვლად.

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

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

შეამოწმეთ გზა პოლიტიკის გაფართოებამდე

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

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

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

როცა ტრანსპორტი არ ერგება

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

შემომავალი VPN სერვერის ჰოსტინგი ცალკე პასუხის მქონე ცალკე პრობლემაა. NAT-კარიბჭე გამავალ თარგმანს იძლევა და ზოგად შემომავალი პორტების გადამისამართებას არ იძლევა, ამიტომ მის უკან მდგარ სერვერს საკუთარი პირობებით დაპროექტებული დამტკიცებული საჯარო შესასვლელი სჭირდება.

მუშაობის რიგი: დაასახელეთ გარე პროტოკოლი, დაადასტურეთ შემდეგი ნაბიჯი, შეადარეთ დოკუმენტირებულ ნაკრებს, შემდეგ შეცვალეთ არქიტექტურა ან ტრანსპორტი. სხვა პორტის ნომერი GRE-ს TCP-დ ვერ აქცევს, და კიდევ ერთი ნებადართული წესი დასრულებულ კონტროლის გაცვლას მუშა მონაცემთა არხად ვერ აქცევს.