VPN służbowy na Raspberry Pi: najpierw zadaj te pytania

Cztery odpowiedzi od pracodawcy decydują, czy Pi może dołączyć do służbowego VPN: jakiego protokołu bramy używa, jakie systemy operacyjne i architektury obsługuje, jak ma przebiegać uwierzytelnianie i czy dozwolony jest klient inny niż oficjalny. Adres URL portalu i słowo Linux nie rozstrzygają żadnej z nich. Zapytaj, zanim cokolwiek pobierzesz, bo odpowiedzi zmieniają to, który pakiet zainstalujesz i czy konfiguracja bez ekranu jest w ogóle możliwa.

Zapisz cztery odpowiedzi. Reszta tekstu to to, co każda z nich zmienia.

Protokół bramy decyduje o kliencie

Brama mówi jednym lub kilkoma protokołami, a klient musi implementować ten, którego twoja organizacja faktycznie używa. OpenConnect to niezależna implementacja, która zaczęła się od zgodności z Cisco AnyConnect, a teraz obejmuje kilka innych bram korporacyjnych; nie jest to markowy klient producenta, a zgodność protokołu nie gwarantuje obsługi każdej funkcji bramy, sprawdzania postury ani polityki urządzenia. Potwierdź protokół z zespołem sieciowym, zamiast wnioskować go z adresu URL portalu. Następnie potwierdź, że pracodawca akceptuje tego klienta w tym wdrożeniu.

Dowody zgodności muszą pochodzić z dokumentacji pracodawcy lub od kolegi, który zrobił to na tym samym modelu, a nie z tego, że pakiet istnieje w repozytorium.

Architektura to nie detal

Zapisz wersję systemu operacyjnego i architekturę przestrzeni użytkownika Pi, wersję klienta, której zamierzasz użyć, oraz skąd pochodzi ten pakiet. Instalator x86 nie staje się odpowiedni dla innej architektury dlatego, że zmieniła się nazwa pliku, a klient producenta, który dostarcza tylko kompilacje x86, w ogóle nie może działać na Pi. Ten jeden fakt może rozstrzygnąć całą kwestię, zanim w ogóle omówi się uwierzytelnianie. Sprawdź utrzymanie źródła pakietu, zamiast instalować zabłąkany plik binarny z wątku na forum.

64-bitowa przestrzeń użytkownika na 64-bitowym jądrze to prosty przypadek; 32-bitowa przestrzeń użytkownika na 64-bitowej płytce to miejsce, w którym ludzie instalują niewłaściwy pakiet. dpkg --print-architecture i uname -m odpowiadają na obie połowy po jednej linii.

Uwierzytelnianie decyduje o przepływie pracy

Hasła, MFA i logowanie przez przeglądarkę narzucają każdy własny przepływ pracy. Certyfikat na tokenie sprzętowym może wymagać sterownika, którego Pi nie ma, podczas gdy przepływ SSO może otworzyć okno przeglądarki, którego sesja bez ekranu nie może pokazać. Niektóre bramy oferują ścieżkę z kodem urządzenia lub ręcznym kopiowaniem właśnie dla takiego przypadku, a inne nie. Zapytaj, którą metodę organizacja obsługuje dla hosta Linux bez ekranu, a potem przetestuj ją, zanim zaczniesz na niej polegać.

Integracja frontendu to wybór odrębny od uwierzytelniania. Wtyczka NetworkManager może zorganizować połączenie i zapisać jego sekrety, ale nie może uczynić nieobsługiwanej metody uwierzytelniania zgodną. Trzymaj te dwa pytania osobno.

Zachowaj granicę pracodawcy

Jeśli organizacja wymaga swojego oficjalnego klienta, zarządzanego urządzenia lub obsługiwanej dystrybucji, postępuj zgodnie z tym wymogiem lub poproś o zatwierdzoną alternatywę. Wyłączanie kontroli certyfikatów, imitowanie wyników postury lub wyłączanie kontroli punktów końcowych, aby inny klient wydawał się akceptowany, zamienia problem zgodności w naruszenie polityki. Trzymaj hasła, ciasteczka sesji i klucze prywatne poza historią powłoki i transkrypcjami czatu. Działające wyzwanie-odpowiedź nie jest pozwoleniem na publikowanie materiału sesji.

Po zatwierdzonej rejestracji potwierdź prywatny DNS, zamierzone zasoby, odrzucony zasób i ponowne połączenie, wszystko z samego Pi. Zalogowany tunel nadal może trasować niepoprawnie lub nie mieć autoryzacji.

Rezultatem jest możliwa do utrzymania umowa z nazwanym właścicielem: który klient, która wersja, która ścieżka rejestracji. To lepsze niż instalowanie klienta bliskiego producentowi i liczenie na to, że pozostałe wymagania okażą się opcjonalne.