vpnc Check Point-ის ან Nortel-ის წინააღმდეგ: რატომ იკიდება

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

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

შეცდომა არასწორ სამოწმებო მონაცემებს ჰგავს

vpnc იწყებს IKE-ის გაგზავნას UDP 500-ზე და, თუ NAT-ის გავლა შემოთავაზებულია, UDP 4500-ზე. კარიბჭე, რომელიც IPsec-ის ნაცვლად SSL-ს ამთავრებს, არც ერთს არ პასუხობს, ამიტომ კლიენტი ხელახლა ცდილობს და საბოლოოდ ზოგადი შეცდომით ნებდება. თუ იგივე ანგარიში მუშაობს ბრაუზერის პორტალით, რომელიც პატარა დამხმარე აპლიკაციას ტვირთავს, ეს ძლიერი მინიშნებაა, რომ გვირაბი SSL-ზეა დაფუძნებული და კლიენტი არასწორ კითხვას სვამს.

აქ წარუმატებელი მცდელობა მომხმარებლის ანგარიშზე არაფერს ამბობს, რადგან კარიბჭეს არასდროს წარუდგინეს სამოწმებო მონაცემები.

შეამოწმეთ, რომელ პროტოკოლს გვთავაზობს კარიბჭე

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

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

ღია 443 შესვლის გვერდზე გადამისამართებით და სიჩუმე 500-სა და 4500-ზე მიუთითებს SSL VPN-ზე. 443-ზე მოწოდებული სერტიფიკატით ღია 500 და 4500 მიუთითებს IPsec კარიბჭეზე, რომელიც ვებ-ინტერფეისსაც უშვებს, და სწორედ ეს შემთხვევაა, რისთვისაც vpnc შეიქმნა.

Check Point-ის SSL Network Extender და Nortel-ის Aventail კლიენტი ორივე მეორე კატეგორიაშია, და არც ერთი არ იღებს IKEv1 ჯგუფურ საიდუმლოს.

რა შეუძლია და რა არ შეუძლია vpnc-ის პროფილს გამოხატოს

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

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

კარიბჭესთან შესაბამისი კლიენტის არჩევა

Check Point-ის კარიბჭისთვის გამოიყენეთ ამ კარიბჭის გამოშვებისთვის აწყობილი SNX პაკეტი, რომელსაც მომწოდებელი დისტანციური წვდომის დოკუმენტაციასთან ერთად აქვეყნებს. ძველი SNX ბილდები ხშირად ვარდება მიმდინარე დისტრიბუტივებზე, რადგან ელიან 32-bit ბიბლიოთეკებს, რომლებიც აღარ არის დაყენებული, და მიტოვებული პაკეტის გაპატჩვა ჩვეულებრივ უარესია, ვიდრე მხარდაჭერილი კლიენტის გაშვება მხარდაჭერილ პლატფორმაზე.

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

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