AWS Client VPN დაკავშირებულია, მაგრამ EC2 მაინც არ პასუხობს
დაკავშირებული მხოლოდ იმას ნიშნავს, რომ სერტიფიკატმა ან SAML შესვლამ იმუშავა. ავტორიზაციის წესები, endpoint-ის მარშრუტები და უსაფრთხოების ჯგუფები თითოეული კერძო ჰოსტამდე მიმავალი გზის ერთ მონაკვეთს იცავს.
ჩემი ლეპტოპი აჩვენებდა დაკავშირებულს. AWS Client VPN კლიენტი თავის მწვანე მდგომარეობას აჩვენებდა, endpoint-მა სესია ჩაწერა და მაინც ვერ გავხსენი MongoDB პორტი EC2 ინსტანსზე კერძო ქვექსელში. აშკარად არაფერი იყო გატეხილი: სერტიფიკატი ვალიდური იყო, პროფილი კონსოლიდან მოდიოდა და გვირაბი ტრაფიკს გადიოდა. შეცდომა ჩემი იყო, რადგან დაკავშირებულს უფლებამოსილებად ვკითხულობდი.
შესვლა ზუსტად ერთ კითხვას პასუხობს: შეიძლება ამ იდენტობამ სესია დაამყაროს? ყველაფერს ამის შემდეგ ცალკეული წესები წყვეტს, რომლებიც თქვენს სერტიფიკატს არასოდეს ხედავენ. სესია, რომელიც ავთენტიფიცირდება, და პაკეტი, რომელიც აღწევს, ორი განსხვავებული წარმატებაა და მათ შორის არსებული უფსკრული არის ის ადგილი, სადაც VPN ჩართულია, მაგრამ ჰოსტი მიუწვდომელია ტიპის ჩივილების უმეტესობა ცხოვრობს.
ქვემოთ მოცემული შემოწმებები არის ის თანმიმდევრობა, რომელსაც ახლა ვიყენებ.
რას ამტკიცებს სინამდვილეში დაკავშირებული სესია
handshake-ის დროს endpoint ამოწმებს კლიენტის სერტიფიკატს საკუთარი trust store-ის წინააღმდეგ, ან SAML-ის კონფიგურაციისას ბრაუზერს თქვენს იდენტობის მომწოდებელთან გადაამისამართებს. თუ ეს გაივლის, კლიენტი endpoint-ის კლიენტის CIDR-იდან მისამართს იღებს და კონსოლი აქტიურ კავშირს აჩვენებს. ამ გაცვლის არც ერთ მომენტში არავინ არ კითხულობს, შეგიძლიათ თუ არა 10.0.4.17-ზე 27017 პორტით მისვლა.
დანიშნულების ნებართვა endpoint-ზე ცალკე ობიექტია. ყოველი ნაკადი ავტორიზაციის წესებს შედარება, და თითოეული დანიშნულების CIDR-ს აკავშირებს იმ ჯგუფთან, რომელსაც წესი ენიჭება. როცა არც ერთი წესი არ ფარავს დანიშნულებას, endpoint სესიას იღებს და ტრაფიკს უგდებს. არც ბანერია, არც ხელახალი დაკავშირების ციკლი და არც არაფერი კლიენტის ინტერფეისში, რაც უარყოფილს იტყვის.
შეადარეთ ავტორიზაციის წესი რესურსს და არა VPC-ს
ჩამოთვალეთ წესები და დადეთ ისინი იმ მისამართის გვერდით, რომელიც ინსტანსს რეალურად აქვს:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8გამოსავალი თითო წესზე დანიშნულების CIDR-ს და ჯგუფის ID-ს აჩვენებს. მასში ორი უკმარისობა იმალება. წესი შეიძლება 10.0.0.0/16-ს ავტორიზებდეს, მაშინ როცა ინსტანსი 10.1.0.0/16-ზე peer-ული VPC-ში ზის; peering მარშრუტი არსებობს, მაგრამ მეორე დიაპაზონისთვის არავის დაუწერია ავტორიზაციის წესი. ან წესი მიუთითებს დირექტორიის ჯგუფზე, რომელშიც მომხმარებელი დირექტორიაშია, მაგრამ არა იმ ჯგუფში, რომელსაც endpoint აფასებს.
დაწერეთ ყველაზე ვიწრო წესი, რომელიც დანიშნულებას ფარავს, და მეორე დაამატეთ მხოლოდ მაშინ, როცა მეორე CIDR ნამდვილად საჭიროა. სწრაფი დაწყებიდან მოსული ფართო 0.0.0.0/0 წესი მუშაობს და სწორედ ამიტომ გადარჩება წარმოებამდე და მალავს მოდელს.
პაკეტის გადაადგილებას ორი მარშრუტების ცხრილი წყვეტს
endpoint-ის მარშრუტი დანიშნულების CIDR-ს endpoint-თან დაკავშირებული ქვექსელიდან ერთ-ერთზე ასახავს. ეს გზის ნახევარია. ქვექსელის საკუთარ მარშრუტების ცხრილმა მაინც უნდა იცოდეს, როგორ გადაამისამართოს პაკეტი, და ეს მნიშვნელოვანია იმ მომენტში, როცა დანიშნულება peering კავშირის, transit gateway-ის ან site-to-site გვირაბით მისაწვდომი ლოკალური დიაპაზონის მიღმაა.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8მოძებნეთ მარშრუტი, რომლის დანიშნულება რესურსის CIDR-ს ემთხვევა და რომლის სამიზნე დაკავშირებული ქვექსელია. თუ მარშრუტი არ არის, დაამატეთ. თუ არის და ჰოსტი მაინც დუმს, უფსკრული VPC-ის მხარესაა, ამიტომ შეადარეთ ასოციაციის ქვექსელის მარშრუტების ცხრილს.
კლიენტის მხარეს ერთი პარამეტრი ამტვრევს მარშრუტიზაციას გვირაბის გატეხვის გარეშე: პროფილი, რომელიც route-nopull-ს შეიცავს. ინსტრუქცია ეუბნება OpenVPN-ზე დაფუძნებულ კლიენტს, რომ უგულებელყოს სერვერის მიერ გაგზავნილი მარშრუტები, ამიტომ ინტერფეისი მხოლოდ endpoint-ის საკუთარი მისამართით ადის და დანიშნულებას უბრალოდ მარშრუტი არ აქვს. შეამოწმეთ ip route show-ით Linux-ზე ან netstat -rn-ით macOS-ზე, არის თუ არა მარშრუტი tun ინტერფეისით. თუ არ არის, წაშალეთ route-nopull ექსპორტირებული პროფილიდან და ხელახლა დაუკავშირდით, რომ გაგზავნილი მარშრუტები გამოყენებულ იქნას.
უსაფრთხოების ჯგუფები თქვენი კლიენტის მისამართს ვერ ხედავენ
ეს ის ნაწილია, რომელშიც მთელი ნაშუადღევი ვცდებოდი. ქვექსელთან დაკავშირებული IPv4 endpoint-ისთვის სერვისი კლიენტის წყაროს მისამართს endpoint-ის ქსელური ინტერფეისის მისამართად თარგმნის იმ ქვექსელში. ინსტანსამდე მისული პაკეტი არ ატარებს იმ მისამართს, რომელსაც თქვენი კლიენტი აჩვენებდა, ამიტომ კლიენტების აუზის, ვთქვათ 172.16.0.0/22, დაშვების უსაფრთხოების ჯგუფის წესი არაფერს არ ემთხვევა.
ნებართვა მიეცით პორტს endpoint-ის უსაფრთხოების ჯგუფიდან, რომელიც ასოციაციის ინტერფეისზეა მიმაგრებული და არა კლიენტის CIDR-იდან. ჯგუფზე მითითება უფრო მდგრადია, ვიდრე მისამართის ხისტად ჩაწერა, რადგან ინტერფეისის მისამართი თქვენს კონტროლში არ არის. ქსელური ACL-ები მდგომარეობის გარეშეა, ამიტომ სადაც მორგებული ჩანაწერებია, შემომავალი და გამავალი მიმართულებებიც უნდა უშვებდეს ნაკადს.
დაუკავშირდით ინსტანსის კერძო მისამართსაც. საჯარო IP პაკეტს VPC-იდან გააქვს და სხვა წესების მქონე სხვა გზით აბრუნებს, ამიტომ საჯარო მისამართზე ტესტი კერძო გზაზე არაფერს ამბობს.
იზოლაციის რიგი, რომელიც პირველ წარუმატებლობაზე ჩერდება
გაიარეთ ესენი რიგრიგობით და გაჩერდით იქ, სადაც ერთი ვერ გაივლის. ყოველი ნაბიჯი გამორიცხავს ერთ ფენას და არა ყველას.
- დაადასტურეთ, რომელი იდენტობა გამოიყენა სესიამ და რომელ ჯგუფს აფასებს endpoint. ერთი trust store-ის სერტიფიკატი არ არის იგივე სუბიექტი, რაც დირექტორიიდან მოსული SAML მტკიცება.
- დაადასტურეთ, რომ ავტორიზაციის წესი ფარავს რესურსის CIDR-ს ამ ჯგუფისთვის.
- დაადასტურეთ, რომ endpoint-ის მარშრუტი არსებობს და დაკავშირებულ ქვექსელზეა მიმართული, შემდეგ რომ ქვექსელის მარშრუტების ცხრილს შეუძლია შემდგომ გადაცემა.
- დაადასტურეთ, რომ უსაფრთხოების ჯგუფი პორტს endpoint-ის ინტერფეისიდან უშვებს და არა კლიენტების აუზიდან.
- სცადეთ VPC-ის შიგნიდან, SSM სესიით იმავე ქვექსელის სხვა ინსტანსზე, რომ გამოყოთ აპლიკაციის პრობლემა კლიენტის გზის პრობლემისგან.
როცა ნაბიჯები გადამწყვეტი არ არის, ამ ცხრილს ვეყრდნობი:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
ანგარიშის ორი დეტალი იწვევს სიმპტომებს, რომლებიც ნებართვის უკმარისობას ჰგავს. ყოველ მომხმარებელს ცალკე კლიენტის სერტიფიკატი სჭირდება; ერთის ორ მანქანაზე გაზიარება სესიებს ერთმანეთის განდევნას აიძულებს და შედეგი უარყოფის ნაცვლად ხელახალი დაკავშირების ციკლია. როცა ახალი endpoint იქმნება, კონსოლი DNS სახელს აჩვენებს, რომელსაც კლიენტის ზოგიერთი ვერსია მხოლოდ endpoint-ის გვერდზე ნაჩვენები შემთხვევითი პრეფიქსით იღებს, ამიტომ დააკოპირეთ სრული სახელი და ნუ აღადგენთ მას.
თუ მეხუთე ნაბიჯი გაჩერებთ, ამოიღეთ endpoint-ის კავშირების ჟურნალი და წაიკითხეთ ავტორიზაციის ჩანაწერები, სანამ რამეს შეცვლით. ჟურნალი ასახელებს შემოწმებულ დანიშნულებას და წესს, რომელიც დაემთხვა ან არ დაემთხვა, და ეს ოთხშრიან კითხვას ერთ პასუხამდე ამცირებს.