სამუშაო VPN Raspberry Pi-ზე: ჯერ ეს კითხვები დასვით

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

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

კარიბჭის პროტოკოლი წყვეტს კლიენტს

კარიბჭე ერთ ან რამდენიმე პროტოკოლზე საუბრობს და კლიენტმა უნდა განახორციელოს ის, რომელსაც თქვენი ორგანიზაცია რეალურად იყენებს. OpenConnect დამოუკიდებელი იმპლემენტაციაა, რომელიც Cisco AnyConnect-თან თავსებადობით დაიწყო და ახლა რამდენიმე სხვა საწარმოო კარიბჭესაც მოიცავს; ეს არ არის მწარმოებლის ბრენდირებული კლიენტი და პროტოკოლის თავსებადობა არ იძლევა კარიბჭის ყოველი ფუნქციის, მდგომარეობის შემოწმების ან მოწყობილობის პოლიტიკის მხარდაჭერის გარანტიას. დაადასტურეთ პროტოკოლი ქსელის გუნდთან და ნუ გამოიტანთ მას პორტალის URL-იდან. შემდეგ დაადასტურეთ, რომ დამსაქმებელი ამ კლიენტს ამ განლაგებისთვის იღებს.

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

არქიტექტურა წვრილმანი არ არის

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

64-ბიტიანი მომხმარებლის სივრცე 64-ბიტიან ბირთვზე მარტივი შემთხვევაა; 64-ბიტიან დაფაზე 32-ბიტიანი მომხმარებლის სივრცე არის ის ადგილი, სადაც ხალხი არასწორ პაკეტს აყენებს. dpkg --print-architecture და uname -m ორივე ნახევარს ერთი ხაზით პასუხობს.

აუთენტიფიკაცია წყვეტს სამუშაო პროცესს

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

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

შეინარჩუნეთ დამსაქმებლის საზღვარი

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

დამტკიცებული რეგისტრაციის შემდეგ დაადასტურეთ კერძო DNS, განკუთვნილი რესურსები, უარყოფილი რესურსი და ხელახალი დაკავშირება, ყველაფერი თავად Pi-დან. შესული გვირაბი მაინც შეიძლება არასწორად მარშრუტიზდეს ან ავტორიზაცია აკლდეს.

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