AWS Client VPN დაკავშირებულია, მაგრამ ინტერნეტი არ მუშაობს: მარშრუტების შემოწმება

AWS Client VPN დაკავშირებულია, მაგრამ ინტერნეტზე წვდომა არ არის? შეამოწმეთ კლიენტის მარშრუტები, ენდპოინტის ავტორიზაცია, ქვექსელის გასასვლელი და DNS სწორედ ამ თანმიმდევრობით.

თქვენ დაკავშირებული ხართ AWS Client VPN ენდპოინტთან, კერძო ქვექსელი პასუხობს, და მაინც ყველა საჯარო გვერდი დროის ამოწურვით მთავრდება. ეს კომბინაცია პრობლემას ამცირებს მართული მხარის სამი ობიექტიდან ერთზე: კლიენტის მიერ დაყენებულ მარშრუტზე, ენდპოინტის მარშრუტზე მისი ავტორიზაციის წესით, ან დაკავშირებული ქვექსელის შემდეგ ნახტომზე. მე მათ სწორედ ამ თანმიმდევრობით ვამოწმებ, რადგან ყოველი ხარვეზი კლიენტის მხრიდან სხვაგვარად ჩანს. ეს სახელმძღვანელო ეხება VPC-ზე დაკავშირებულ მართულ ენდპოინტს, და არა OpenVPN სერვერს EC2 ინსტანსზე და არა Cloud WAN ან Transit Gateway კავშირს.

დაიწყეთ იმით, თუ რას მარშრუტიზებს კლიენტი სინამდვილეში

დაკავშირებული მდგომარეობა ამტკიცებს TLS სესიას და კლიენტისთვის CIDR-ის მინიჭებას, მეტს არაფერს. ჰკითხეთ ოპერაციულ სისტემას, სად წავიდოდა საჯარო მისამართი, სანამ გვირაბი აწეულია. Linux-ზე ip route get 1.1.1.1 უნდა დაასახელოს გვირაბის ინტერფეისი; macOS-ზე netstat -rn -f inet | head -5 აჩვენებს ნაგულისხმევ ჩანაწერს; Windows-ზე Find-NetRoute -RemoteIPAddress 1.1.1.1 ბეჭდავს არჩეულ ინტერფეისს და შემდეგ ნახტომს.

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

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

როდესაც SplitTunnel true არის, საჯარო დანიშნულება გვირაბს მხოლოდ მაშინ იყენებს, როცა ენდპოინტი აქვეყნებს მის დამფარავ მარშრუტს, ამიტომ არსებული 0.0.0.0/0 ამ ტრაფიკს ლოკალურ ინტერფეისზე ტოვებს. თუ false არის, კლიენტი ტრაფიკს იჭერს, მაგრამ ენდპოინტმა მაინც უნდა დაამარშრუტოს და ავტორიზაცია მოახდინოს; წინააღმდეგ შემთხვევაში პაკეტები გვირაბში შედის და იქ ჩერდება. ორივე პარამეტრიდან რომელიმეს შეცვლის შემდეგ ხელახლა დაუკავშირეთ კლიენტი, რადგან მარშრუტები და DNS სერვერები კავშირის დროს გაიცემა და მომუშავე კლიენტმა შეიძლება ძველი ნაკრები შეინარჩუნოს.

წაიკითხეთ ენდპოინტის მარშრუტი და ავტორიზაციის წესი ცალ-ცალკე

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

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

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

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC-ის CIDR-ის წესი არაფერს ამბობს 0.0.0.0/0-ზე. სრული გვირაბისთვის დაკარგული ნაწილების დამატება ნიშნავს ერთ მარშრუტს ყოველ დაკავშირებულ ქვექსელზე, პლუს ავტორიზაციის წესი, რომლის აუდიტიც მოგვიანებით შეგიძლიათ:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

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

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

ენდპოინტის მარშრუტი წყვეტს, რომ AWS პაკეტს ამ ქვექსელს გადასცემს. ის არ წყვეტს შემდეგ ნახტომს მის შემდეგ, რომელიც თავად ქვექსელის VPC მარშრუტების ცხრილში ცხოვრობს:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

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

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

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

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

გამოყავით DNS ხარვეზი მკვდარი მარშრუტისგან

სახელების გარჩევა სხვაგვარად ფარდება, ვიდრე გადაგზავნა, და სრული გვირაბი ამ განსხვავებას მნიშვნელოვანს ხდის, რადგან გაძევებულ რეზოლვერთან ახლა გვირაბის გავლით მიდიან. თუ ენდპოინტი VPC-ის DNS სერვერებს განსაზღვრავს, მათ მისამართებს სჭირდება მარშრუტის დაფარვა და ავტორიზაცია, როგორც ნებისმიერ სხვა დანიშნულებას. ჰკითხეთ რეზოლვერს პირდაპირ, რომ ნახოთ რომელი ხარვეზი გაქვთ: dig +short example.com @10.0.0.2, ან nslookup example.com 10.0.0.2 Windows-ზე.

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

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

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

ორივე ობიექტი დამატებითი იყო, ამიტომ დაბრუნება წაშლაა და არა შეკეთება:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

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

დაასრულეთ მოკლე სიით და ბოლო პუნქტს ცვლილების ნაწილად მოეპყარით და არა დოკუმენტაციად:

  • ერთი 0.0.0.0/0 ენდპოინტის მარშრუტი ყოველ დაკავშირებულ ქვექსელზე.
  • ავტორიზაციის წესი, რომელიც ფარავს 0.0.0.0/0-ს იმ კლიენტებისთვის, რომელთაც გსურთ მოემსახუროთ.
  • VPC-ის ნაგულისხმევი მარშრუტი, რომელიც blackhole მდგომარეობაში არ არის, ყოველ დაკავშირებულ ქვექსელზე.
  • დაკავშირების უსაფრთხოების ჯგუფის გასასვლელი, პლუს ACL-ის დაბრუნების ტრაფიკი.
  • რეზოლვერის მისამართები დამარშრუტებული და ავტორიზებული, შემოწმებული სახელობითი მოთხოვნით.
  • ჩაწერილი დაბრუნება მარშრუტისა და წესისთვის.

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

დაკავშირებული სტატიები