VPN-ში შესვლა იჭედება RADIUS Access-Challenge-ის შემდეგ

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

ერთი შესვლა, ორი RADIUS გაცვლა

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

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

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

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

RADIUS-ის სპეციფიკაცია აღწერს კოდს 11 4.4 თავში და უშვებს ორ ატრიბუტს, რომლებიც აქ მნიშვნელოვანია. Reply-Message ინახავს მომხმარებლისთვის განკუთვნილ ტექსტს, ხოლო State ინახავს გაუმჭვირვალე მნიშვნელობას, რომლის უკან დაბრუნებაც სერვერს სურს. NAS-მა State არ უნდა განმარტოს, მხოლოდ უცვლელად დააბრუნოს.

გაგრძელების მოთხოვნა იყენებს ახალ Identifier-ს და ახალ Request Authenticator-ს და უნდა ატაროს იგივე State მნიშვნელობა მომხმარებლის პასუხთან ერთად. სერვერი მას მოლოდინში მყოფ გამოწვევას ამ State-ის მეშვეობით უკავშირებს, ამიტომ ატრიბუტის ხელახლა შემქმნელი ან გადამგდები კარიბჭე ცერემონიას ვერ დაასრულებს. თითოეული პასუხის response authenticator-იც უნდა დამოწმდეს, თორემ NAS-მა პაკეტი უნდა გადააგდოს.

4.4 თავი ამატებს დეტალს, რომელიც ხსნის უმეტეს ჩუმ ჩავარდნას: NAS, რომელსაც გამოწვევების მხარდაჭერა არ შეუძლია, Access-Challenge-ს უარად თვლის. თუ თქვენი კარიბჭის VPN სერვისი ამ მხარდაჭერაზე ძველია ან გამოტოვებს მას, backend-ის მოთხოვნა მეორე ფაქტორზე მყისიერ «ავთენტიფიკაცია ვერ მოხერხდა» ხდება ყოველგვარი მოთხოვნის გარეშე.

სად იკარგება ჯაჭვური მოთხოვნა

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

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

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

თვალი ადევნეთ ერთ ცდას თავიდან ბოლომდე

გაამეორეთ ერთხელ, სერვერის მხარეს გამართვის ჩართვით, და ყველა სხვა სესია დაიტოვეთ ჩაწერის ფანჯრის გარეთ:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

გამოსავალში ეძებეთ საუბრის ფორმა და არა ერთი ხაზი. პირველი Access-Request Identifier 3-ით, State-ის მატარებელი Access-Challenge, შემდეგ მეორე Access-Request Identifier 4-ით, რომელიც იმეორებს ამ State-ს და მოიცავს მომხმარებლის პასუხს. თუ მეორე მოთხოვნა აკლია, კარიბჭეს გაგრძელება არასდროს მოუხდენია. თუ ის State-ის გარეშე მოდის, სერვერი ვერ დაუკავშირებს მას მოლოდინში მყოფ გამოწვევას და ჩვეულებრივ უარყოფს.

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

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