AWS Site-to-Site VPN NAT Gateway-მდე: VGW თუ Transit Gateway

ყველა პირველად ერთსა და იმავე დიაგრამას ხატავს: VPN VPC-ში, NAT gateway ინტერნეტში, დამთავრდა. მაგრამ AWS არ უჭერს მხარს ამ გზას, როცა VPN virtual private gateway-ზე სრულდება, და წარუმატებლობა იმდენად ჩუმია, რომ გუნდები მას რამდენჯერმე თავიდან აშენებენ. მომუშავე გადაწყვეტას transit gateway სჭირდება, რაც ცვლის gateway-ს და route-ების ცხრილებს ორივე მხარეს. დახატვამდე შეადარეთ ორივე ფორმა.

ტოპოლოგია, რომელიც აშკარად გამოიყურება და მხარდაჭერილი არ არის

AWS-ის NAT gateway-ის დოკუმენტაცია ხაზს ავლებს, რომელიც ყველას აკვირვებს, ვისაც მხოლოდ ერთი VPC-ის არქიტექტურა აქვს აწყობილი: Site-to-Site VPN კავშირიდან ტრაფიკი ვერ გამარშრუტდება NAT gateway-ზე virtual private gateway-ის გავლით. gateway-ის ტიპი, რომელზეც VPN სრულდება, განსაზღვრავს, საერთოდ არსებობს თუ არა თარგმანის გზა. შეცდომა ცოცხლობს იმიტომ, რომ გვირაბის სტატუსი UP-ია და იმავე subnet-ის EC2 ინსტანცია ინტერნეტს უპრობლემოდ აღწევს. არც ერთი დაკვირვება არ ამოწმებს გატეხილ მიმართულებას.

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

Virtual private gateway transit gateway-ის წინააღმდეგ

Virtual private gateway ერთ VPC-ს ეკუთვნის. ის ამთავრებს VPN-ს, route-ებს ამატებს ამ VPC-ის ცხრილებში და იქ ჩერდება. მას არ აქვს attachment მოდელი, ამიტომ ვერ გადასცემს ტრაფიკს სხვა VPC-ს ან საერთო გასასვლელ სეგმენტს. ეს ერთი VPC-ის ფარგლებია მთელი შეზღუდვა, და VPC-ის შიგნით დამატებული არც ერთი route ამას არ ცვლის.

Transit gateway რეგიონული ცენტრია, სადაც VPN, ყოველი spoke VPC და საერთო სერვისების VPC attachment-ებად ჩნდება. მას აქვს საკუთარი route-ების ცხრილები, რომლებიც ირჩევენ, რომელი attachment მიიღებს მოცემულ prefix-ს.

სწორედ ეს ცენტრი ხდის შესაძლებელს ცენტრალიზებულ გასასვლელს: VPN ერთ attachment-ად ეშვება, გასასვლელი VPC მეორედ, და transit gateway-ის route-ების ცხრილი ინტერნეტისკენ მიმართულ prefix-ებს პირველიდან მეორეში აგზავნის. virtual private gateway-ის შემთხვევაში მეორე attachment არ არსებობს, ამიტომ გადაწყვეტას ვერ შეაკერებთ მოგვიანებით.

მხარდაჭერილი გასასვლელი გზა, hop-ობით

საცნობარო გადაწყვეტას ხუთი hop აქვს და ყოველი ისარი route-ირების გადაწყვეტილებაა, რომელიც უნდა დააკონფიგურიროთ. ტრაფიკი ლოკალური ქსელიდან გადადის Site-to-Site VPN attachment-ში, transit gateway-ის ცხრილი გადასცემს მას გასასვლელი VPC-ის attachment-ს, სადაც subnet-ის ცხრილი აგზავნის საჯარო NAT gateway-ზე. NAT gateway თარგმნის წყაროს და internet gateway პაკეტს გარეთ გააქვს.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

ორი დეტალი განსაზღვრავს, იმუშავებენ თუ არა ბოლო hop-ები. NAT gateway საჯარო უნდა იყოს, elastic IP-ით და route-ით internet gateway-ისკენ, რადგან კერძო NAT gateway ქსელებს შორის თარგმნის და არასოდეს ხდება ინტერნეტის გასასვლელი.

დაგეგმეთ ერთი NAT gateway თითოეული Availability Zone-ისთვის, რომელსაც აპირებთ მოემსახუროთ, და ყოველი subnet-ის ცხრილი ლოკალურზე მიუთითებდეს. თქვენს ჩანაწერებში transit gateway-ის ცხრილი და VPC-ის ცხრილები ცალკე ობიექტებად შეინახეთ, რადგან ერთი attachment-ს ირჩევს, მეორე კი VPC-ის შიგნით რესურსს. default route მხოლოდ ერთში ტოვებს გზის ნახევარს გაურკვეველს და წარმოშობს იმ ნაწილობრივ ხარვეზებს, რომელთა მიკუთვნება ყველაზე რთულია.

სწორედ დაბრუნების გზაზე ცდება ეს გადაწყვეტები

NAT gateway ინახავს მდგომარეობას უკვე ნანახი ნაკადებისთვის, ამიტომ გამავალი კავშირის პასუხები ბრუნდება ახალი შემომავალი წესის გარეშე. ეს თვისება არ აქვეყნებს ლოკალურ სერვისს ინტერნეტში, და ისე მოპყრობა, თითქოს აქვეყნებს, გუნდს ერთ დღეს ართმევს ისეთი კავშირის გამართვას, რომელიც არასოდეს დამყარდებოდა. კლიენტის მიერ წამოწყებული ტრაფიკისთვის ოთხი route უნდა შეთანხმდეს: ლოკალური პოლიტიკა, transit gateway-ის ცხრილი, გასასვლელი subnet-ის ცხრილი და NAT subnet-ის ცხრილი. გამოტოვეთ უკანასკნელი და მოთხოვნა შენობას ტოვებს, სანამ პასუხი AWS-ის შიგნით იღუპება.

გადაამოწმეთ VPN-ის უკან მყოფი რეალური კლიენტით და ნახეთ, რომელ საჯარო წყაროს მისამართს წარადგენს. თუ ეს NAT gateway-ის elastic IP-ია, თარგმანი ხდება; თუ სხვა რამეა, სხვა გასასვლელს ზომავთ.

ამ ხარვეზის ასიმეტრიული ვარიანტი ადრე უნდა ამოვიცნოთ. როცა ერთი Availability Zone-ის NAT subnet-ის ცხრილში კლიენტის prefix-ზე დაბრუნების route არის, მეორეში კი არა, ახალი კავშირები წარმატდება ან ცდება იმის მიხედვით, რომელ ზონაში ვარდება ნაკადი, და ეს ნიმუში არასტაბილურ ინტერნეტად იკითხება. შეადარეთ subnet-ის ცხრილები ყოველი ზონისთვის, რომელსაც ემსახურებით, იმ ზონის გასწორების ნაცვლად, სადაც ticket გაიხსნა, რადგან დაკარგული route მთელი ხარვეზია და მეორე მხარეს არაფერი უნდა შეიცვალოს.

როდის არის აშკარა proxy უკეთესი გადაწყვეტა

HTTP proxy გასასვლელი VPC-ის ინსტანციაზე ლეგიტიმური ალტერნატივაა და ხშირად იაფი. კლიენტები მის გამოსაყენებლად კონფიგურდება, proxy საკუთარ კავშირს ხსნის გარეთ, და დაბრუნების გზა მისი პრობლემა ხდება და არა სიმეტრიული route-ირების თავსატეხი. მცირე რაოდენობის აპლიკაციისთვის ეს transit gateway-ის სამუშაოს დიდ ნაწილს აქრობს. ის ასევე იძლევა მომხმარებლის მიხედვით ლოგირებას, რასაც NAT gateway ვერ შექმნის.

თუმცა გამჭვირვალე არ არის. ყველაფერი, რაც proxy-ის პარამეტრებს უგულებელყოფს, და ყოველი პროტოკოლი, რომელიც HTTP არ არის, ამ გზას არ გაჰყვება.

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