ระบบปฏิบัติการของคุณพูด VPN โพรโทคอลใดได้อยู่แล้ว?
Windows, macOS และ ChromeOS ต่างมาพร้อมรายการอุโมงค์สั้น ๆ ถามเกตเวย์เกี่ยวกับโพรโทคอลและวิธีการพิสูจน์ตัวตนก่อนเพิ่มไดรเวอร์อีกตัว
ก่อนดาวน์โหลดไคลเอนต์อีกตัว ให้ดูว่าระบบปฏิบัติการใช้งานอะไรอยู่แล้ว เพราะคำตอบมักเพียงพอที่จะข้ามตัวติดตั้งไปทั้งหมด Windows, macOS และ ChromeOS ต่างมาพร้อมรายการโพรโทคอลอุโมงค์ที่คงที่และสั้น และเกตเวย์ที่พูดหนึ่งในนั้นไม่ต้องใช้ไดรเวอร์ บริการ หรือเส้นทางการอัปเดตเพิ่มเติม สิ่งที่ตัดสินไม่ใช่ชื่อผู้ขายบนโบรชัวร์ แต่เป็นโพรโทคอล วิธีที่ปลายทางพิสูจน์ตัวตน และที่อยู่ที่มันคาดหวัง
ถามหาโพรโทคอล ไม่ใช่ชื่อผลิตภัณฑ์
ชื่อผลิตภัณฑ์บอกอะไรได้น้อยมากเกี่ยวกับสิ่งที่วิ่งบนสาย สองเกตเวย์ที่ขายภายใต้ป้ายเดียวกันอาจต้องการอุโมงค์ที่ต่างกันโดยสิ้นเชิง และตัวหนึ่งอาจรับไคลเอนต์ในตัวในขณะที่อีกตัวปฏิเสธทุกอย่างยกเว้นพอร์ทัลของตัวเอง ผู้ดูแลสองคนที่อธิบายกล่องเดียวกันอาจไม่เห็นด้วยและทั้งคู่ถูก เพราะพวกเขาอธิบายคนละชั้น อุโมงค์ข้างใต้คือสิ่งที่ตัดสินว่าต้องใช้ตัวติดตั้งหรือไม่
ถามสามคำถามกับคนที่ดูแลเกตเวย์: อุโมงค์โพรโทคอลใด วิธีพิสูจน์ตัวตนใด และไคลเอนต์ต้องยอมรับที่อยู่และคำต่อท้าย DNS ใด ขอโพรโทคอลตามชื่อ และเมื่อคำตอบกลับมาเป็นชื่อผลิตภัณฑ์ ให้อธิบายว่าทำไมคุณจึงต้องใช้โพรโทคอลนั้น สามคำตอบนั้นตัดสินคำถามเรื่องไคลเอนต์ก่อนจะมีการดาวน์โหลดซอฟต์แวร์ใด ๆ
มีเหตุผลที่ชื่อผลิตภัณฑ์ยังอยู่ในตั๋วจำนวนมาก ผู้ใช้เห็น URL ของพอร์ทัล และอุโมงค์มองไม่เห็นตราบใดที่ยังทำงาน การเขียนโพรโทคอลลงในบันทึกการส่งมอบใช้เวลาแค่บรรทัดเดียวและขจัดความคลุมเครือให้ทุกคนที่มาตามหลัง
จุดที่รายการในตัวสิ้นสุด
รายการที่มีมาแต่เดิมนั้นสั้น และขอบของมันสำคัญกว่าเนื้อหา L2TP บน IPsec ที่พูดด้วยคีย์ที่แชร์ไว้ล่วงหน้าจะไม่พูด SSTP และความต่างนั้นคือสิ่งที่ตัดสินไคลเอนต์ ตารางเรียงตามอุโมงค์ไม่ใช่ตามผู้ขาย คุณจึงค้นหาโพรโทคอลที่เกตเวย์ระบุได้
| Tunnel | Windows | macOS | ChromeOS | Linux |
|---|---|---|---|---|
| PPTP | built in | removed in 10.12 | no | package |
| L2TP over IPsec, pre-shared key | built in | built in | built in | package |
| L2TP over IPsec, certificate | built in | built in | built in | package |
| SSTP | built in | no | no | package |
| IKEv2 | built in | built in | no | package |
| Cisco IPsec with XAuth | no | built in | no | package |
| OpenVPN | no | no | built in | package |
อ่านตารางเทียบกับข้อกำหนดของเกตเวย์ ไม่ใช่เทียบกับโบรชัวร์ หากคำตอบคือ L2TP over IPsec ที่ใช้คีย์แชร์ล่วงหน้า สามแพลตฟอร์มแรกเชื่อมต่อได้โดยไม่ต้องติดตั้งอะไรเพิ่ม หากคำตอบคือ OpenVPN จะมีเพียง ChromeOS ที่ครอบคลุมก่อนคุณติดตั้งอะไร โพรโทคอลที่ไม่ปรากฏในคอลัมน์ในตัวใดเลยคือสัญญาณตรงไปตรงมาว่าตัวติดตั้งกำลังจะมา
Linux คือคอลัมน์ที่ต่อต้านการเหมารวม การสนับสนุนโพรโทคอลของมันอยู่ในเดมอนและปลั๊กอินที่ดิสทริบิวชันเลือกจะแพ็กเกจ ดังนั้นอิมเมจขนาดเล็กอาจไม่พูดสักตัวจนกว่าคุณจะเพิ่มเข้าไป และสองดิสทริบิวชันที่มีเดสก์ท็อปเดียวกันก็อาจต่างกันได้
สร้างโปรไฟล์จากบรรทัดคำสั่ง
ทุกสิ่งที่แผงกราฟิกเขียนถูกเก็บไว้ที่ใดที่หนึ่งซึ่งคุณเข้าถึงได้ และนั่นคือสิ่งที่ทำให้โปรไฟล์ในตัวสามารถทำให้เป็นอัตโนมัติได้ Windows เก็บรายการ VPN ไว้ใน .pbk ไฟล์ภายใต้โปรไฟล์ผู้ใช้และภายใต้ ProgramData และ rasphone สามารถแสดงและแก้ไขรายการที่รายการเครือข่ายไม่แสดง สิ่งนี้สำคัญเมื่อเครื่องถูกจัดเตรียมด้วยสคริปต์และไม่มีใครจะคลิกผ่านตัวช่วยสร้าง มันยังอธิบายว่าโปรไฟล์จะดำรงอยู่ได้อย่างไรโดยไม่เคยปรากฏในถาดระบบเลย
rasdial
rasdial "VpnName" alice
rasdial "VpnName" /disconnect
การแก้ไข .pbk ไฟล์ด้วยมือนั้นได้ผล และยังเป็นวิธีที่เร็วที่สุดในการทำให้เสียหาย ดังนั้นปล่อยให้รูปแบบเป็นของเครื่องมือ macOS เก็บบริการไว้ในการกำหนดค่าระบบ และ networksetup เข้าถึงบริการเหล่านั้นด้วยชื่อบริการ แฟล็กหลายตัวต้องการที่อยู่แทนชื่อโฮสต์ ดังนั้นแก้ไขปลายทางก่อนแล้วเก็บค่าที่ไคลเอนต์จะใช้จริง ความต่างนี้กัดตอนทำอัตโนมัติ เพราะสคริปต์ที่ทำงานกับที่อยู่อาจล้มเหลวกับชื่อ และข้อผิดพลาดดูเหมือนเกตเวย์เสียมากกว่าอาร์กิวเมนต์ที่ถูกปฏิเสธ
networksetup -listallnetworkservices
networksetup -getinfo "ServiceName"
networksetup -setmanualwithdhcprouter "ServiceName" 198.51.100.20
ชื่อบริการถูกแปลเป็นภาษาท้องถิ่นและผู้ใช้แก้ไขได้ ดังนั้นสคริปต์ที่ฝังค่า Wi-Fi แบบตายตัวจะแตกบนเครื่องแรกที่ตั้งเป็นภาษาอื่น อ่านชื่อจากคำสั่งแสดงรายการแล้วส่งต่อไปแทนการเดา
ใบรับรองโดยไม่ต้องมีไคลเอนต์เฉพาะเจ้า
บางการติดตั้งต้องการใบรับรองไคลเอนต์และไม่มีอะไรอื่นที่เป็นของเฉพาะเจ้า นี่คือกรณีกลางที่ควรทดสอบก่อนยอมรับไดรเวอร์ การวางใบรับรองในที่เก็บของแพลตฟอร์มได้รับการสนับสนุน มันไม่ใช่การกระทำเดียวกับการโยนรูทของผู้ขายเข้าไปแล้วหวังว่าไคลเอนต์จะหาเจอ อย่างแรกคือการวางโดยเจตนา อย่างที่สองคือการเดาโดยมีตั๋วสนับสนุนแนบมาด้วย
รายละเอียดที่ทำให้คนพลาดคือที่เก็บใดที่ไคลเอนต์อ่าน ใบรับรองในที่เก็บของผู้ใช้จะมองไม่เห็นสำหรับไคลเอนต์ที่กำหนดค่าไว้สำหรับที่เก็บของเครื่อง และข้อความที่คุณได้รับบอกว่าใบรับรองหายไป ไม่ได้บอกว่าอยู่ผิดที่ ตรวจสอบทั้งสองที่เก็บก่อนสรุปว่าใบรับรองผิด บันทึกว่าการกำหนดค่าที่ใช้งานได้ใช้ที่เก็บใด เพราะบันทึกนั้นอยู่ได้นานกว่าใบรับรองเมื่อเครื่องถูกสร้างใหม่
Windows แยกที่เก็บทั้งสองอย่างชัดเจน และ macOS แยกพวงกุญแจเข้าสู่ระบบออกจากพวงกุญแจระบบ ชื่อต่างกัน แต่รูปแบบความล้มเหลวเหมือนกันทุกประการ: ใบรับรองที่ถูกต้องซึ่งไคลเอนต์ไม่เคยดู
อะไรบังคับให้ต้องมีตัวติดตั้ง
เกตเวย์บางตัวผูกไคลเอนต์ไว้กับที่เก็บใบรับรองส่วนตัว ตัวแทนตรวจสภาพ หรือการแลกเปลี่ยนการลงชื่อเข้าที่ระบบปฏิบัติการไม่สามารถทำได้ การติดตั้งบนฮาร์ดแวร์ Check Point, Cisco หรือ Fortinet มักลงเอยที่นั่น และในนั้นไคลเอนต์ในตัวไม่ใช่ทางลัด ตัวแทนจากบุคคลที่สามอาจเชื่อมต่อได้และยังละเมิดนโยบาย ซึ่งทำให้เรื่องนี้เป็นการตัดสินใจด้านความปลอดภัยไม่ใช่ด้านความสะดวก ติดตั้งตามที่นโยบายกำหนดและบันทึกเหตุผลไว้ข้างเวอร์ชันตัวติดตั้ง
บันทึกนั้นคือส่วนที่ผู้คนข้ามไปและเป็นส่วนที่ประหยัดเวลาหนึ่งสัปดาห์ให้ผู้ดูแลคนถัดไป: โพรโทคอล วิธีพิสูจน์ตัวตน ตระกูลที่อยู่ และคำต่อท้ายที่จำเป็น พร้อมเหตุผลหนึ่งบรรทัดสำหรับทุกไบนารีที่ต้องเพิ่มเข้าไป วางไว้ที่ที่บันทึกของตัวติดตั้งอาศัยอยู่ ไม่ใช่ในเธรดแชต สองบรรทัดของเอกสารป้องกันการสอบสวนซ้ำ