სრული გვირაბი Access Server-ის EC2-ზე: რატომ არ არის საკმარისი ერთი მონიშვნის უჯრა

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

რას აკონტროლებს შემოწმება სინამდვილეში

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

შეამოწმეთ მიმდინარე მნიშვნელობა aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck-ით, სანამ რამეს შეცვლით. თუ კონსოლში შეცვლით, შეცვალეთ იმიტომ, რომ ინსტანსი სხვებისთვის გადასცემს, და არა იმიტომ, რომ კლიენტი ინტერნეტს ვერ აღწევს.

კლიენტის მარშრუტიზაციის პოლიტიკა Access Server-ს ეკუთვნის

Access Server 3-ში გახსენით Access Controls და იპოვეთ Internet Access and DNS განყოფილება. Internet Gateway-ის არჩევანი გთავაზობთ სრულ ან გაყოფილ გვირაბს; სრული გვირაბი კლიენტს ეუბნება, რომ ნაგულისხმევი ტრაფიკი VPN-ში გადაამისამართოს, გაყოფილი გვირაბი ინტერნეტ ტრაფიკს კლიენტის ლოკალურ გზაზე ტოვებს. შეინახეთ და გამოიყენეთ პროდუქტის სამუშაო პროცესით, შემდეგ ხელახლა დაუკავშირდით სატესტო კლიენტს, რადგან პოლიტიკა კავშირის დროს გადაეცემა.

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

თვალი ადევნეთ პაკეტს გვირაბის შემდეგ

როცა კლიენტი ინტერნეტ ტრაფიკს გვირაბში აგზავნის, სერვერმა უნდა გადასცეს და ჩვეულებრივ თარგმნოს ის. Access Server თავის NAT და მარშრუტიზაციის წესებს მართავს, ამიტომ წაიკითხეთ ეფექტური კონფიგურაცია და ნუ დაამატებთ Community OpenVPN-ის წესებს გენერირებულ ფაილებში; მართვის გარეშე დარჩენილი წესები გადაიწერება ან კონფლიქტში შევა პროდუქტის შემდეგ განახლებაზე. sudo iptables -t nat -L -n -v ან nftables-ის ეკვივალენტი აჩვენებს, რა თარგმნება სინამდვილეში.

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

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

ცალკე გეჭიროთ IP გამოსვლა და DNS

ჯერ სცადეთ მისამართის ლიტერალი, შემდეგ სახელი, იმავე კლიენტური აპლიკაციიდან. თუ curl -4 https://checkip.amazonaws.com აბრუნებს საჯარო მისამართს, მაგრამ ჰოსტის სახელები ვარდება, გვირაბი და NAT გზა მუშაობს და პრობლემა DNS-ია: გაგზავნილი რეზოლვერი, კლიენტის რეზოლვერის მდგომარეობა ან უსაფრთხოების ჯგუფი, რომელიც რეზოლვერს ბლოკავს. Access Server-ის DNS პარამეტრები იმავე Internet Access არეალშია, მაგრამ სხვა კოდის გზით მიდიან.

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

ნუ მისცემთ ერთ უჯრას გამოძიების დახურვის საშუალებას

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

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