บริการ VPN หนึ่งบริการครอบคลุมเดสก์ท็อป Windows, Mac และ Linux ได้หรือไม่

แล็ปท็อปสามเครื่องในทีมเดียว เมนู VPN สามแบบที่ต่างกัน และตั๋วที่บอกว่าการเชื่อมต่อทำงานได้ทุกที่ยกเว้นบน Mac แผนเบื้องหลังไคลเอนต์เหล่านั้นอาจเหมือนกันทุกประการแม้เมนูจะไม่เหมือน สิ่งที่ต้องตรงกันนั้นแคบกว่าที่การติดตั้งส่วนใหญ่คิดไว้: ตัวตนเกตเวย์หนึ่ง ชนิดข้อมูลรับรองหนึ่ง ชุดเส้นทางหนึ่ง และนโยบายตัวแปลงชื่อหนึ่ง เขียนสี่ข้อนี้ลงก่อนที่ใครจะส่งออกโปรไฟล์ แล้วงานฝั่งแพลตฟอร์มจะกลายเป็นรายการตรวจสอบแทนการสอบสวน

เริ่มจากสัญญาการเข้าถึง ไม่ใช่ไฟล์ไคลเอนต์

สัญญาการเข้าถึงคือห้าบรรทัดที่ผู้ตรวจสอบสามารถตรวจได้โดยไม่ต้องเปิดคอนโซลของผู้จำหน่าย สัญญาระบุ คำนำหน้าแบบส่วนตัวที่ต้องเข้าถึงได้ ชื่อภายในที่ต้องแปลงได้ ตัวแปลงชื่อที่ตอบคำเหล่านั้น ทราฟฟิกที่อนุญาตให้อยู่บนเส้นทางท้องถิ่น และใบรับรองเกตเวย์ที่ไคลเอนต์ควรคาดว่าจะเห็น ส่วนที่เหลือทั้งหมดในการติดตั้งคือการแปลบรรทัดเหล่านั้นเป็นรูปแบบไฟล์

ตัวอย่างในออฟฟิศทำให้รูปแบบชัดเจน: เซิร์ฟเวอร์แอปพลิเคชันอยู่ใน 10.60.0.0/16 ชื่อส่วนตัวอย่าง corp.example ตัวแปลงชื่อภายในที่ 10.61.0.53 และการท่องเว็บปกติยังอยู่บนเส้นทางที่อุปกรณ์ใช้อยู่แล้ว ข้อสุดท้ายเป็นการตัดสินใจเชิงนโยบาย ไม่ใช่ค่าเริ่มต้นของไคลเอนต์ และไคลเอนต์หลายตัวจะส่งทุกอย่างผ่านอุโมงค์หากไม่มีใครบอกเป็นอย่างอื่น บันทึกสัญญาพร้อมวันที่และผู้รับผิดชอบ เพราะบันทึกนั้นคือสิ่งที่ภายหลังจะบอกคุณว่าอุโมงค์เปลี่ยนหรือนโยบายเปลี่ยน

เลือกโปรโตคอลหนึ่งและคู่การพิสูจน์ตัวตนหนึ่งที่คุณปกป้องได้

IKEv2 ที่มีการพิสูจน์ตัวตนเกตเวย์ด้วยใบรับรองและ EAP สำหรับผู้ใช้เป็นตัวเลือกปกติเมื่อทั้งสามแพลตฟอร์มต้องทำงานโดยไม่ต้องติดตั้งซอฟต์แวร์เพิ่ม เพราะ Windows, macOS และ NetworkManager ต่างมีไคลเอนต์ IKEv2 มาด้วย ปัญหาคือการรองรับ IKEv2 บอกเพียงป้ายชื่อ ไม่ใช่ชุดความสามารถ วิธีการ EAP กุญแจที่หนุนด้วยฮาร์ดแวร์ การแมปใบรับรองเป็นบัญชี และการเชื่อมต่อใหม่แบบอัตโนมัติล้วนถูกทำแยกตามแพลตฟอร์ม การผสมที่ทำงานได้บนสองในสามเป็นเรื่องปกติพอที่คุณควรถือว่าเป็นเช่นนั้นจนกว่าจะทดสอบ

ทดสอบคู่นั้นบนทุกแพลตฟอร์มเป้าหมายก่อนเขียนคู่มือการติดตั้ง ไม่ใช่หลัง เกตเวย์ที่ให้ทั้ง EAP-MSCHAPv2 และ EAP-TLS ให้ที่ว่างสำหรับเส้นทางสำรอง โดยมีเงื่อนไขว่าเส้นทางสำรองนั้นถูกบันทึกว่าได้รับการรองรับ ไม่ใช่ถูกค้นพบระหว่างเหตุขัดข้อง เส้นทางที่รองรับสองเส้นเป็นประกันราคาถูก ส่วนเส้นที่สามที่ไม่มีเอกสารคือตั๋วในอนาคต

เมื่อไม่มีคู่ใดครอบคลุมไคลเอนต์ทั้งสาม ทางเลือกที่ซื่อสัตย์คือเพิ่มไคลเอนต์ เพิ่มโปรไฟล์บนเกตเวย์ หรือจำกัดรายการแพลตฟอร์มที่รองรับ การปิดการตรวจสอบใบรับรองบนแพลตฟอร์มที่บ่นดังที่สุดไม่ใช่หนึ่งในนั้น การเปลี่ยนแปลงนั้นเปลี่ยนช่องว่างความเข้ากันได้ให้เป็นความเสี่ยงจากการดักจับ และไม่มีขั้นตอนใดในภายหลังของการติดตั้งที่จะแก้ไขได้

สร้างสิ่งส่งมอบหนึ่งชิ้นต่อแพลตฟอร์มจากสัญญา

Windows ใช้โปรไฟล์ VPNv2 ซึ่งส่งผ่าน MDM หรือสร้างในเครื่องด้วย Add-VpnConnection พร้อมเพย์โหลด XML ส่วนที่กัดคือขอบเขตและความไว้วางใจ โปรไฟล์ขอบเขตอุปกรณ์และโปรไฟล์ขอบเขตผู้ใช้ถูกติดตั้งในที่เก็บต่างกัน ใบรับรองที่ไคลเอนต์ต้องการจึงต้องอยู่ในที่เก็บที่ตรงกับขอบเขตที่คุณเลือก จับคู่ผิดจะได้โปรไฟล์ที่นำเข้าได้เรียบร้อยแล้วล้มเหลวในการเชื่อมต่อครั้งแรก

macOS ใช้โปรไฟล์การกำหนดค่าที่มีเพย์โหลด VPN แบบจัดการ ลงนามและเผยแพร่ผ่าน MDM หรือติดตั้งด้วยมือสำหรับโครงการนำร่อง ตัวตนและห่วงโซ่ CA เดินทางเป็นเพย์โหลดแยกกัน นี่คือเหตุผลที่โปรไฟล์ติดตั้งได้โดยไม่มีปัญหากล่าวหาแล้วยังล้มเหลวตอนเชื่อมต่อ ตรวจรายการเพย์โหลด ไม่ใช่แค่ผลการติดตั้ง

Linux ขึ้นอยู่กับแบ็กเอนด์เบื้องหลัง NetworkManager และ strongSwan กับปลั๊กอิน NetworkManager เป็นแพ็กเกจแยกกัน คุณสมบัติการเชื่อมต่อเฉพาะของปลั๊กอิน ไม่ใช่คีย์ VPN ทั่วไป คีย์ที่คัดลอกจากปลั๊กอินอื่นจึงมักบันทึกได้โดยไม่ผิดพลาดแล้วล้มเหลวตอนเปิดใช้งาน สร้างการเชื่อมต่อบนอิมเมจสะอาดเพื่อยืนยันว่าปลั๊กอินอยู่ตรงที่มันจะทำงานจริง

สิ่งส่งมอบทั้งสามต่างกันในรูปแบบ แต่แต่ละชิ้นเข้ารหัสห้าบรรทัดสัญญาเดียวกัน นั่นคือการทดสอบว่าสิ่งส่งมอบเสร็จหรือยัง: ทุกบรรทัดถูกแสดงไว้ที่ใดที่หนึ่ง และไม่มีอะไรเกินเลยถูกคิดค้นขึ้นระหว่างทาง

ตรวจสอบเส้นทาง ตัวแปลงชื่อ และการเชื่อมต่อใหม่บนบัญชีสะอาด

การเชื่อมต่อได้ไม่ใช่การทดสอบตอบรับ บน Windows Get-VpnConnection แสดงโปรไฟล์ และ route print แสดงว่าคำนำหน้าแบบส่วนตัวลงบนอินเทอร์เฟซอุโมงค์หรือไม่ บน macOS scutil --nc list ยืนยันบริการที่ใช้งานอยู่ ขณะที่ scutil --dns แสดงลำดับตัวแปลงชื่อที่ระบบจะใช้จริง

บน Linux nmcli connection show --active พิสูจน์ว่าการเชื่อมต่อขึ้นแล้ว และ resolvectl status แสดง DNS ตามลิงก์ ตัวแปลงชื่อที่มีในไฟล์การเชื่อมต่อแต่หายไปจากผลลัพธ์ตามลิงก์หมายความว่า DNS แบบแยกไม่ถูกนำไปใช้ นั่นคือความต่างระหว่างชื่อที่แปลงได้กับชื่อที่แปลงได้ผ่านอุโมงค์ และมันเปลี่ยนว่าทีมสนับสนุนใดรับขั้นตอนถัดไป เปรียบเทียบผลลัพธ์ตามลิงก์ก่อนและหลังการเชื่อมต่อขึ้น ไม่ใช่แค่หลัง

ทำการตรวจทั้งหมดด้วยบัญชีใหม่ ไม่มีข้อมูลรับรองที่แคชไว้และไม่มีใบรับรองที่ผู้ดูแลระบบติดตั้ง จากนั้นทำซ้ำหลังระงับและกลับมาทำงาน และอีกครั้งหลังจากบังคับให้ป้อนข้อมูลรับรองใหม่ การเปลี่ยนสถานะสองครั้งนั้นเผยความล้มเหลวในการเชื่อมต่อใหม่ส่วนใหญ่ที่การเชื่อมต่อครั้งแรกไม่เคยแสดง

ใส่เวอร์ชันให้แพ็กเกจและเก็บเส้นทางย้อนกลับ

ติดป้ายแพ็กเกจแต่ละแพลตฟอร์มด้วยการแก้ไขสัญญาที่มันใช้งาน และบันทึกเวอร์ชันไคลเอนต์และเกตเวย์ที่คุณรับรองมันด้วย เมื่อพฤติกรรมเปลี่ยนหลังการอัปเดตไคลเอนต์ ป้ายนั้นชี้ไปที่สัญญาที่ต้องทดสอบใหม่ ไม่ใช่ไฟล์ที่ต้องเดา

เก็บแพ็กเกจก่อนหน้าของแต่ละแพลตฟอร์มให้เรียกคืนได้ และเขียนคำสั่งถอนออกไว้ข้าง ๆ การถอนโปรไฟล์ VPN ไม่ใช่ภาพสะท้อนของการติดตั้งบน Windows, macOS หรือ Linux และความต่างจะปรากฏในเวลาที่แย่ที่สุด ซ้อมการถอนหนึ่งครั้งบนอุปกรณ์สำรอง เพื่อให้คลังเก็บกลายเป็นแผน ไม่ใช่ความหวัง