როგორ აღწევს VPN-შესვლა RADIUS-მდე და თქვენს იდენტობის პროვაიდერამდე
თვალი ადევნეთ VPN-შესვლას კლიენტიდან კარიბჭის RADIUS მოთხოვნამდე, მის უკან მდგარ იდენტობის პროვაიდერამდე და მიღების შემდეგ გამოყენებულ პოლიტიკამდე.
გასულ კვირას მომხმარებელმა შეძლო VPN-ში შესვლა და მაინც ისეთ ქსელში აღმოჩნდა, სადაც არაფერი იხსნებოდა. კლიენტმა თქვა დაკავშირებულია, კარიბჭის ჟურნალმა თქვა Access-Accept, ხოლო იდენტობის გუნდმა თქვა, რომ ანგარიში რიგზეა. შესვლა მუშაობდა; მის უკან არსებული ავტორიზაცია არა. როცა VPN-შესვლა ვერ ხერხდება, მე გავდივარ იმ გზას, რომელსაც მოთხოვნა რეალურად გადის — კლიენტი, კარიბჭე, RADIUS სერვერი, იდენტობის პროვაიდერი — და ვჩერდები პირველ საფეხურზე, რომლის პასუხი შემდეგს არ ემთხვევა.
კლიენტი არასდროს ლაპარაკობს RADIUS-ზე
რასაც აჩვენებს ლეპტოპის აპლიკაცია, მისი პირველი საფეხური VPN პროტოკოლია: IKEv2, OpenVPN, WireGuard ან TLS-ზე დაფუძნებული კლიენტი. RADIUS ამ გაცვლაში არ ჩანს. კლიენტი კარიბჭის წინაშე ავთენტიფიკაციას გადის სერტიფიკატით, მომხმარებლის სახელითა და პაროლით, ან გვირაბის კონფიგურაციაში გადატანილი EAP მეთოდით.
ეს მნიშვნელოვანია ჟურნალების კითხვისას, რადგან ზოგად ავთენტიფიკაციის შეცდომას, რომელსაც მომხმარებელი ხედავს, კარიბჭე ქმნის მას შემდეგ, რაც უკვე სხვა რამეს ესაუბრა. თუ კლიენტი კარიბჭემდე საერთოდ არ აღწევს, გამართვისთვის RADIUS მოთხოვნა არ არსებობს და RADIUS სერვერზე დახარჯული ერთი საათი ფუჭდება. დაადასტურეთ, რომ გვირაბი საერთოდ ამოვიდა, სანამ backend-ს შეეხებით.
კარიბჭე RADIUS კლიენტია
როგორც კი გვირაბის კონფიგურაცია აღწევს იმ წერტილს, სადაც უფლებამონაცემები უნდა შემოწმდეს, კარიბჭე ქსელური წვდომის სერვერი ხდება. ის აგებს Access-Request-ს: User-Name, პაროლი ან EAP დატვირთვა, NAS-IP-Address ან NAS-Identifier, და Message-Authenticator, როცა მეთოდი მას მოითხოვს. მოთხოვნა ნაგულისხმევად UDP 1812-ზე მიდის, ხოლო აღრიცხვა 1813-ზე. ძველი განლაგებები კვლავ იყენებენ 1645-სა და 1646-ს, ამიტომ ერთი წყვილისთვის დაწერილი firewall წესი ბევრ ჩუმ მარცხს ხსნის.
ორივე მხარე ერთ საიდუმლოს იზიარებს და ეს მომხმარებლის უფლებამონაცემი არ არის. ის ხელს აწერს გაცვლას და ყოველი პასუხი მის მიმართ მოწმდება. დააყენეთ საიდუმლო ორივე მხარეს სხვადასხვანაირად და სერვერი ცუდი საიდუმლოთი არ პასუხობს — ის ყრის მოთხოვნას ან პასუხი ვერ გადის შემოწმებას, ამიტომ კარიბჭე დროის ამოწურვას იუწყება. არასწორი საიდუმლო და მკვდარი სერვერი კარიბჭიდან ერთნაირად გამოიყურება, ამიტომ საფეხურს კლიენტის ხელსაწყოთი ვამოწმებ, სანამ კატალოგს დავადანაშაულებ.
პროტოკოლი პატარა და ძველია — RFC 2865 განსაზღვრავს ავთენტიფიკაციის გაცვლას — მაგრამ ატრიბუტები, რომლებსაც ის ატარებს, არის საფუძველი, რომელზეც VPN პოლიტიკის უმეტესობაა აგებული.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS სერვერი შეიძლება მხოლოდ იდენტობის პროვაიდერის წინა ნაწილი იყოს
ხალხი RADIUS-ზე და იდენტობის პროვაიდერზე ისე ლაპარაკობს, თითქოს ერთი და იგივე ყუთია. ხშირად ასე არ არის. RADIUS სერვერი იღებს Access-Request-ს და შემდეგ პასუხამდე სხვა რამეს ეკითხება — Active Directory-ს LDAP-ით ან Kerberos-ით, ლოკალურ მომხმარებელთა ფაილს ან გარე სერვისს. FreeRADIUS LDAP ან krb5 მოდულით, Windows NPS და Cisco ISE ყველა ამ პოზიციაზე დგას.
განსხვავება წყვეტს, სად უნდა უყუროთ. უარყოფილი პაროლი იდენტობის პროვაიდერის პასუხია, რომელსაც RADIUS გადასცემს. დროის ამოწურვა ჩვეულებრივ RADIUS-იდან კატალოგამდე მონაკვეთია: ვადაგასული bind ანგარიში, მიუწვდომელი კატალოგი ან არასწორ backend-ზე გაგზავნილი მოთხოვნა. თუ მომხმარებლის სახელს დომენის სუფიქსი აქვს, სერვერმა შეიძლება მის მიხედვით დაამარშრუტოს, და იგივე ანგარიში, რომელიც CORP\alice და [email protected] სახით გაიგზავნა, სხვადასხვა ადგილას აღმოჩნდეს. Windows NPS-ში Security ჟურნალი იწერს 6272-ს მინიჭებისთვის და 6273-ს უარყოფისთვის, რაც გეუბნებათ, საერთოდ NPS-იდან მოვიდა თუ არა გადაწყვეტილება.
წაიკითხეთ მარცხი იმ საფეხურზე, რომელმაც ის წარმოქმნა
ერთი „ვერ ვუკავშირდები“ შეტყობინება ოთხ სხვადასხვა მარცხს მოიცავს. სანამ რამეს შეცვლით, შეუსაბამეთ სიმპტომი იმ საფეხურს, რომელმაც ის წარმოქმნა.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
ბოლო სტრიქონია ის, რომელიც ხალხს არასწორ გუნდთან აგზავნის. Access-Accept ნიშნავს, რომ უფლებამონაცემები მიღებულია; ეს არ ნიშნავს, რომ კარიბჭემ მომხმარებელი სწორ pool-ში მოათავსა ან მარშრუტები გაუშვა. ჯგუფის ატრიბუტებს მნიშვნელობა აქვს მხოლოდ მაშინ, როცა კარიბჭის პოლიტიკა კითხულობს მათ. მინახავს, როგორ ხვდება სწორი შესვლა სტუმრების pool-ში, რადგან ჯგუფების რუკა RADIUS მხარეს იყო გამართული სხვა ატრიბუტისთვის, ვიდრე ის, რომელსაც კარიბჭე ამოწმებს.
თვალი ადევნეთ ერთ შესვლას თავიდან ბოლომდე
აირჩიეთ ერთი სატესტო ანგარიში და ერთი კარიბჭე, შემდეგ დააკვირდით იმავე მცდელობას ოთხივე წერტილში. დაიწყეთ გამართვა RADIUS მხარეს — freeradius -X ბეჭდავს მოთხოვნას და ყველა მოდულს, რომელსაც ეხება — მიჰყევით კარიბჭის ავთენტიფიკაციის ჟურნალს და გაუშვით tcpdump UDP გაცვლისთვის. დაუკავშირდით ერთხელ და წაიკითხეთ ოთხი კვალი თანმიმდევრობით.
რისი ნახვაც გსურთ, შეთანხმებაა: კარიბჭემ იკითხა იმ მომხმარებელზე, რომელსაც ელოდით, RADIUS სერვერმა აირჩია ის backend, რომელსაც ელოდით, ამ backend-მა დააბრუნა გადაწყვეტილება, და პასუხის ატრიბუტები ემთხვევა იმ პოლიტიკას, რომელსაც კარიბჭე იყენებს. პირველი ადგილი, სადაც კვლები არ ემთხვევა, თქვენი ხარვეზის ხაზია. თუ პასუხს ჯგუფის ატრიბუტი არ აქვს, პრობლემა RADIUS მხარესაა და არა VPN პროფილში; თუ ატრიბუტი არსებობს და კარიბჭე უგულებელყოფს მას, პრობლემა კარიბჭის პოლიტიკაა.
ერთი უსაფრთხოების შენიშვნა, სანამ იქ ხართ. საერთო საიდუმლო იცავს გაცვლას, მაგრამ არ შიფრავს ატრიბუტების უმეტესობას. თუ კარიბჭე და RADIUS სერვერი სხვადასხვა სეგმენტშია, მოათავსეთ ეს საფეხური RADIUS-ზე TLS-ით ან კერძო გზით. დაშიფრული მომხმარებლის გვირაბი არაფერს ამბობს backend-ის კავშირზე.
სანამ ბილეთს დახურავთ, დაადასტურეთ ოთხი რამ. კარიბჭე აღწევს RADIUS სერვერამდე იმ პორტზე, რომელზეც ის რეალურად არის გამართული. საერთო საიდუმლო ორივე მხარეს ემთხვევა. RADIUS სერვერი ხსნის მომხმარებლის სახელის ზუსტ ფორმას, რომელსაც კარიბჭე აგზავნის. მიღება ატარებს იმ ატრიბუტებს, რომლებიც კარიბჭის პოლიტიკას სჭირდება. როცა ოთხივე სრულდება, შესვლა, რომელიც მაინც ვერ ხერხდება, კარიბჭის პოლიტიკის პრობლემაა და არა ავთენტიფიკაციის.