LAN ერთი AWS Client VPN სესიის მიღმა: რა გადაეცემა

ნოუთბუქი უკავშირდება AWS Client VPN-ის საბოლოო წერტილს, აღწევს კერძო ქვექსელს და ყველაფერი ჯანსაღად გამოიყურება. იმავე LAN-ზე მდგარი დესკტოპი ვერაფერს აღწევს, თუმცა Linux ჰოსტსაც აქვს ხიდის ინტერფეისი და ორივე მანქანა ერთსა და იმავე კაბელზეა. გვირაბში არაფერია არასწორად კონფიგურირებული; დაკარგული ნაწილი მარშრუტიზაციაა, ხიდი კი ცრუ კვალია.

Client VPN სესიის LAN-ზე გაფართოება ჭიშკრის როლია. ეს არ არის მართულ სერვისში გაწელილი Ethernet სეგმენტი.

ჰოსტი მუშაობს, LAN კი არა

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

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

ყველა კლიენტი ჭიშკარი ვერ იქნება

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

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

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

მიმართეთ LAN გვირაბისკენ და თარგმნეთ

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

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

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

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

პასუხსაც გზა სჭირდება

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

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

გახსოვდეთ, რომ საბოლოო წერტილი მართული სერვისია. არ არსებობს სერვერის კონფიგურაციის ფაილი რედაქტირებისთვის და არ არსებობს client-config დირექტივა დასამატებლად, ამიტომ თვითმართული OpenVPN სერვერისთვის, კლიენტის ქვექსელის საკუთარი მარშრუტებით, დაწერილი ინსტრუქციები არ გადადის. AWS-ზე ბერკეტებია ქვექსელის მიბმა, ავტორიზაციის წესები და VPC-ის მარშრუტიზაციის ცხრილები.

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

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

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

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

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