VPN สำหรับงานบน Raspberry Pi: ถามคำถามเหล่านี้ก่อน
URL ของพอร์ทัลและคำว่า Linux ไม่ใช่สัญญากับไคลเอนต์ รับคำตอบเรื่องโปรโตคอล สถาปัตยกรรม การพิสูจน์ตัวตน และนโยบายก่อนติดตั้งสิ่งใด
คำตอบสี่ข้อจากนายจ้างเป็นตัวกำหนดว่า Pi จะเข้าร่วม VPN ของงานได้หรือไม่ ได้แก่ โปรโตคอลเกตเวย์ที่มันใช้ ระบบปฏิบัติการและสถาปัตยกรรมที่รองรับ การพิสูจน์ตัวตนต้องทำอย่างไร และอนุญาตให้ใช้ไคลเอนต์อื่นที่ไม่ใช่ตัวทางการหรือไม่ URL ของพอร์ทัลกับคำว่า Linux ไม่ได้ตัดสินข้อใดเลย ถามก่อนดาวน์โหลดสิ่งใด เพราะคำตอบเปลี่ยนแพ็กเกจที่คุณจะติดตั้งและเปลี่ยนว่าการตั้งค่าแบบไม่มีหน้าจอเป็นไปได้หรือไม่
จดคำตอบทั้งสี่ข้อไว้ ส่วนที่เหลือคือสิ่งที่แต่ละข้อเปลี่ยน
โปรโตคอลเกตเวย์เป็นตัวกำหนดไคลเอนต์
เกตเวย์พูดคุยได้หนึ่งโปรโตคอลหรือมากกว่า และไคลเอนต์ต้องใช้งานโปรโตคอลที่นายจ้างของคุณใช้จริง OpenConnect เป็นการใช้งานอิสระที่เริ่มจากความเข้ากันได้กับ Cisco AnyConnect และตอนนี้ครอบคลุมเกตเวย์องค์กรอื่นอีกหลายตัว มันไม่ใช่ไคลเอนต์แบรนด์ของผู้ขาย และความเข้ากันได้ของโปรโตคอลไม่ได้ยืนยันว่าจะรองรับทุกฟีเจอร์ของเกตเวย์ การตรวจสอบสถานะ หรือนโยบายอุปกรณ์ ยืนยันโปรโตคอลกับทีมเครือข่ายแทนการเดาจาก URL ของพอร์ทัล จากนั้นยืนยันว่านายจ้างยอมรับไคลเอนต์นี้สำหรับการติดตั้งใช้งานนี้
หลักฐานความเข้ากันได้ต้องมาจากเอกสารของนายจ้างหรือจากเพื่อนร่วมงานที่ทำบนรุ่นเดียวกัน ไม่ใช่จากการมีแพ็กเกจอยู่ในที่เก็บ
สถาปัตยกรรมไม่ใช่รายละเอียดเล็กน้อย
บันทึกเวอร์ชันระบบปฏิบัติการและสถาปัตยกรรมพื้นที่ผู้ใช้ของ Pi เวอร์ชันไคลเอนต์ที่คุณตั้งใจใช้ และที่มาของแพ็กเกจนั้น ตัวติดตั้ง x86 ไม่กลายเป็นใช้ได้กับสถาปัตยกรรมอื่นเพียงเพราะชื่อไฟล์เปลี่ยน และ ไคลเอนต์ของผู้ขายที่ให้เฉพาะบิลด์ x86 ไม่สามารถทำงานบน Pi ได้เลย ข้อเท็จจริงข้อเดียวนี้อาจตัดสินคำถามทั้งหมดก่อนจะพูดถึงการพิสูจน์ตัวตนด้วยซ้ำ ตรวจสอบการดูแลแหล่งที่มาของแพ็กเกจแทนการติดตั้งไบนารีที่หลงมาวากระทู้ฟอรัม
พื้นที่ผู้ใช้ 64 บิตบนเคอร์เนล 64 บิตเป็นกรณีง่าย ส่วนพื้นที่ผู้ใช้ 32 บิตบนบอร์ด 64 บิตคือจุดที่ผู้คนติดตั้งแพ็กเกจผิด dpkg --print-architecture และ uname -m ตอบทั้งสองครึ่งด้วยบรรทัดละหนึ่งบรรทัด
การพิสูจน์ตัวตนเป็นตัวกำหนดลำดับงาน
รหัสผ่าน MFA และการลงชื่อเข้าใช้ผ่านเบราว์เซอร์ต่างบังคับลำดับงานของตัวเอง ใบรับรองที่เก็บไว้บนโทเคนฮาร์ดแวร์อาจต้องใช้ไดรเวอร์ที่ Pi ไม่มี ขณะที่โฟลว์ SSO อาจเปิดหน้าต่างเบราว์เซอร์ซึ่งเซสชันที่ไม่มีหน้าจอไม่สามารถแสดงได้ เกตเวย์บางตัวมีเส้นทางรหัสอุปกรณ์หรือคัดลอกด้วยมือสำหรับกรณีนี้โดยเฉพาะ บางตัวไม่มี ถามว่าองค์กรรองรับวิธีใดสำหรับโฮสต์ Linux ที่ไม่มีหน้าจอ แล้วทดสอบก่อนพึ่งพา
การผสานรวมส่วนหน้าเป็นทางเลือกแยกจากการพิสูจน์ตัวตน ปลั๊กอิน NetworkManager จัดการการเชื่อมต่อและเก็บความลับของมันได้ แต่ไม่สามารถทำให้วิธีพิสูจน์ตัวตนที่ไม่รองรับเข้ากันได้ แยกคำถามสองข้อนี้ไว้
รักษาขอบเขตของนายจ้างไว้
หากองค์กรกำหนดให้ใช้ไคลเอนต์ทางการ อุปกรณ์ที่จัดการ หรือดิสทริบิวชันที่รองรับ ให้ปฏิบัติตามข้อกำหนดนั้นหรือขอทางเลือกที่ได้รับอนุมัติ การปิดการตรวจสอบใบรับรอง การเลียนแบบผลสถานะ หรือการปิดการควบคุมจุดปลายเพื่อให้ไคลเอนต์อื่นดูเหมือนได้รับอนุญาต จะเปลี่ยนปัญหาความเข้ากันได้ให้เป็นการละเมิดนโยบาย เก็บรหัสผ่าน คุกกี้เซสชัน และคีย์ส่วนตัวออกจากประวัติเชลล์และบันทึกแชต การตอบสนองแบบชาเลนจ์ที่ทำงานได้ไม่ใช่การอนุญาตให้เผยแพร่ข้อมูลเซสชัน
หลังการลงทะเบียนที่ได้รับอนุมัติ ให้ยืนยัน DNS ส่วนตัว ทรัพยากรที่ตั้งใจ ทรัพยากรที่ถูกปฏิเสธ และการเชื่อมต่อใหม่ ทั้งหมดจากตัว Pi เอง อุโมงค์ที่ลงชื่อเข้าใช้แล้วยังอาจกำหนดเส้นทางผิดหรือขาดการอนุญาตได้
ผลลัพธ์คือข้อตกลงที่สนับสนุนได้โดยมีเจ้าของระบุชื่อ ซึ่งไคลเอนต์ใด เวอร์ชันใด เส้นทางการลงทะเบียนใด นั่นดีกว่าการติดตั้งไคลเอนต์ที่ใกล้เคียงผู้ขายแล้วหวังว่าข้อกำหนดที่เหลือจะเป็นทางเลือก