VPN kerja di Raspberry Pi: ajukan pertanyaan ini dulu

Empat jawaban dari pemberi kerja menentukan apakah sebuah Pi dapat bergabung dengan VPN kerja: protokol gateway mana yang digunakannya, sistem operasi dan arsitektur mana yang didukungnya, bagaimana autentikasi harus dilakukan, dan apakah klien selain klien resmi diizinkan. URL portal dan kata Linux tidak menyelesaikan satu pun dari itu. Tanyakan sebelum mengunduh apa pun, karena jawabannya mengubah paket mana yang Anda pasang dan apakah penyiapan tanpa layar sama sekali layak.

Catat keempat jawaban itu. Sisa teks ini adalah apa yang diubah masing-masing.

Protokol gateway menentukan kliennya

Gateway berbicara satu atau beberapa protokol, dan klien harus mengimplementasikan protokol yang benar-benar dijalankan organisasi Anda. OpenConnect adalah implementasi independen yang dimulai dengan kompatibilitas Cisco AnyConnect dan kini mencakup beberapa gateway perusahaan lain; ini bukan klien bermerek vendor, dan kompatibilitas protokol tidak menjamin dukungan untuk setiap fitur gateway, pemeriksaan postur, atau kebijakan perangkat. Konfirmasikan protokolnya dengan tim jaringan alih-alih menyimpulkannya dari URL portal. Lalu konfirmasikan bahwa pemberi kerja menerima klien ini untuk penerapan ini.

Bukti kompatibilitas harus berasal dari dokumentasi pemberi kerja atau dari rekan yang melakukannya pada model yang sama, bukan dari adanya paket di repositori.

Arsitektur bukan detail

Catat rilis OS dan arsitektur ruang pengguna Pi, versi klien yang ingin Anda gunakan, dan dari mana paket itu berasal. Pemasang x86 tidak menjadi cocok untuk arsitektur lain karena nama berkasnya berubah, dan klien vendor yang hanya menyediakan build x86 sama sekali tidak dapat berjalan di Pi. Satu fakta itu dapat menyelesaikan seluruh pertanyaan sebelum autentikasi bahkan dibahas. Periksa pemeliharaan sumber paket alih-alih memasang biner liar dari utas forum.

Ruang pengguna 64-bit pada kernel 64-bit adalah kasus sederhana; ruang pengguna 32-bit pada papan 64-bit adalah tempat orang memasang paket yang salah. dpkg --print-architecture dan uname -m menjawab kedua bagiannya dalam satu baris masing-masing.

Autentikasi menentukan alur kerja

Kata sandi, MFA, dan masuk melalui peramban masing-masing memaksakan alur kerjanya sendiri. Sertifikat yang disimpan pada token perangkat keras mungkin memerlukan pengandar yang tidak dimiliki Pi, sementara alur SSO dapat membuka jendela peramban yang tidak dapat ditampilkan sesi tanpa layar. Sebagian gateway menawarkan jalur kode perangkat atau salin manual justru untuk kasus itu, dan sebagian tidak. Tanyakan metode mana yang didukung organisasi untuk host Linux tanpa layar, lalu ujilah sebelum bergantung padanya.

Integrasi frontend adalah pilihan terpisah dari autentikasi. Plugin NetworkManager dapat mengatur koneksi dan menyimpan rahasianya, tetapi tidak dapat membuat metode autentikasi yang tidak didukung menjadi kompatibel. Jaga agar kedua pertanyaan itu terpisah.

Jaga batas pemberi kerja tetap utuh

Jika organisasi mewajibkan klien resminya, perangkat terkelola, atau distribusi yang didukung, ikuti persyaratan itu atau minta alternatif yang disetujui. Menonaktifkan pemeriksaan sertifikat, meniru hasil postur, atau mematikan kontrol titik akhir agar klien lain tampak diterima mengubah masalah kompatibilitas menjadi pelanggaran kebijakan. Jauhkan kata sandi, cookie sesi, dan kunci privat dari riwayat shell dan transkrip obrolan. Tantangan-respons yang berfungsi bukan izin untuk menerbitkan materi sesi.

Setelah pendaftaran yang disetujui, konfirmasikan DNS privat, sumber daya yang dimaksud, sumber daya yang ditolak, dan penyambungan ulang, semuanya dari Pi itu sendiri. Terowongan yang sudah masuk tetap dapat merutekan dengan salah atau tidak memiliki otorisasi.

Hasilnya adalah kesepakatan yang dapat didukung dengan pemilik bernama: klien mana, versi mana, jalur pendaftaran mana. Itu lebih baik daripada memasang klien yang berdekatan dengan vendor dan berharap persyaratan sisanya ternyata opsional.