SSTP บน Linux ล้มเหลวก่อนเข้าสู่ระบบ? ตรวจสอบองค์ประกอบรันไทม์
โปรแกรมแก้ไขเดสก์ท็อปวาดเพียงแบบฟอร์ม อุโมงค์ SSTP ยังต้องมีไคลเอนต์โปรโตคอล ชั้น PPP และเจ้าของความลับ และแต่ละอย่างล้มเหลวต่างกัน
คุณติดตั้งปลั๊กอิน SSTP ปุ่มวิทยุปรากฏในโปรแกรมแก้ไขเครือข่าย คุณกรอกเกตเวย์และชื่อผู้ใช้ และโปรไฟล์ล้มเหลวด้วยข้อผิดพลาดทั่วไปก่อนที่จะขอรหัสผ่านด้วยซ้ำ ไม่มีอะไรผิดปกติในลำดับนั้น และไม่มีสิ่งใดในนั้นพิสูจน์ว่าซอฟต์แวร์อุโมงค์ถูกติดตั้งไว้ การเชื่อมต่อ SSTP ประกอบขึ้นจากชิ้นส่วนที่จัดส่งแยกกัน ได้แก่ ปลั๊กอิน VPN ที่ NetworkManager เรียกใช้ได้ โปรแกรมไคลเอนต์ SSTP ที่เป็นเจ้าของเซสชัน TLS และ PPP เดมอน PPP ที่อยู่ข้างใต้ และที่เก็บความลับที่การเชื่อมต่อได้รับอนุญาตให้อ่าน
รายการเมนูเพิ่มอะไร และไม่เพิ่มอะไร
ปลั๊กอินให้คำอธิบายบริการที่บอก NetworkManager ว่าจะเริ่มต้นอย่างไร และในดิสทริบิวชันส่วนใหญ่มีโปรแกรมแก้ไขเล็ก ๆ ที่วาดแบบฟอร์ม นั่นคือขอบเขตทั้งหมดของรายการเมนู โปรแกรมไคลเอนต์มาจากแพ็กเกจต้นทางอื่น และ README ของปลั๊กอินเองก็บอกการแยกส่วนนั้นตรง ๆ ว่าเป็นปลั๊กอิน ไม่ใช่ไคลเอนต์
จากนั้นไคลเอนต์ต้องใช้ PPP เพราะ SSTP บรรทุกเซสชัน PPP ไว้ในการเชื่อมต่อ TLS หากไม่มี pppd อุโมงค์อาจจับมือ TLS เสร็จแล้วก็ยังตายที่เฟรมควบคุมแรก ซึ่งดูเหมือนปัญหาเกี่ยวกับข้อมูลรับรองแต่ไม่ใช่ บน Debian และ Ubuntu ชิ้นส่วนมาขึ้นเป็น network-manager-sstp, sstp-client และ ppp และการติดตั้งเฉพาะชิ้นแรกคือสาเหตุทั่วไปที่สุดที่แบบฟอร์มยอมรับทุกช่องแต่การเชื่อมต่อไม่เคยเสร็จสิ้น
การเลือกเดสก์ท็อปเพิ่มการแยกอีกชั้น Plasma แก้ไขโปรไฟล์ผ่าน plasma-nm ซึ่งต้องมีองค์ประกอบ SSTP ของตัวเองและอ่านคำอธิบายบริการเดียวกัน ดังนั้นโปรแกรมแก้ไขที่ไม่มีรายการ SSTP กับ CLI ที่สร้างโปรไฟล์ได้ดีจึงเป็นครึ่งหนึ่งของโปรแกรมแก้ไขที่หายไป ไม่ใช่รันไทม์ที่เสีย
อ่านขั้นตอนแรกที่ล้มเหลวก่อนติดตั้งอะไรใหม่
ความพยายาม SSTP ที่ล้มเหลวผ่านขั้นตอนตามลำดับคงที่ และขั้นตอนที่ล้มเหลวจะบอกคุณว่าต้องดูองค์ประกอบใด
การเรียกใช้ปลั๊กอินเป็นขั้นแรก และความล้มเหลวตรงนั้นให้ข้อความเกี่ยวกับบริการ VPN ไม่ใช่เกี่ยวกับเซิร์ฟเวอร์ ต่อไปคือการเชื่อมต่อ TCP ไปยังพอร์ต 443 การถูกปฏิเสธหรือหมดเวลาที่นี่เป็นปัญหาการเข้าถึง ไม่ใช่ TLS จากนั้นคือการจับมือ TLS และการตรวจสอบตัวตนของเซิร์ฟเวอร์ ตามด้วยการเจรจา PPP และการพิสูจน์ตัวตนบัญชี และสุดท้ายคือการกำหนดที่อยู่และเส้นทาง ดู journalctl -f -u NetworkManager ขณะที่คุณเปิดใช้งานโปรไฟล์หนึ่งครั้ง และอ่านบรรทัดเฉพาะเจาะจงบรรทัดแรกแทนบรรทัดทั่วไปบรรทัดสุดท้าย
ลำดับนั้นอธิบายการอ่านผิดที่พบบ่อย ข้อร้องเรียนเรื่องใบรับรองถูกรายงานก่อนที่จะส่งข้อมูลรับรองใด ๆ ดังนั้นการเปลี่ยนรหัสผ่านจึงช่วยไม่ได้ การปฏิเสธการพิสูจน์ตัวตน PPP มาหลังการจับมือที่สำเร็จ ดังนั้นการเปลี่ยนใบรับรองก็ช่วยไม่ได้เช่นกัน เก็บข้อผิดพลาดแรกและขั้นตอนของมันไว้ แล้วคุณจะมีการวินิจฉัยไม่ใช่อาการ
ความเชื่อถือในใบรับรองและการเข้าสู่ระบบบัญชีเป็นสองประตูแยกกัน
การจับมือตรวจสอบว่าเซิร์ฟเวอร์คือเครื่องที่คุณตั้งใจจะเข้าถึง โดยใช้ผู้ออกใบรับรองและชื่อที่คุณกำหนดค่าไว้ หลังจากนั้นเท่านั้นที่ชั้น PPP เสนอชื่อผู้ใช้และรหัสผ่านของคุณให้กับวิธีการพิสูจน์ตัวตนของเกตเวย์ นั่นคือการตรวจสอบอิสระสองครั้งที่ประเมินตามลำดับคงที่ โดยมีการตั้งค่าแยกกันสำหรับแต่ละครั้ง ไม่มีอะไรที่พิมพ์ในช่องรหัสผ่านสามารถมีอิทธิพลต่อครั้งแรกได้
โปรไฟล์ที่เชื่อถือผู้ออกใบรับรองผิดจะล้มเหลวที่ประตูแรกด้วยข้อผิดพลาดด้านตัวตน โปรไฟล์ที่เชื่อถือถูกต้องแต่เก็บรหัสผ่านเก่าจะล้มเหลวที่ประตูที่สองด้วยการปฏิเสธการพิสูจน์ตัวตน ทั้งสองดูเหมือน VPN ที่จะไม่เชื่อมต่อ และไม่มีอันใดได้รับการแก้ไขด้วยยาของอีกอัน
รับผู้ออกใบรับรองและชื่อเซิร์ฟเวอร์ที่คาดหวังจากผู้ที่ดูแลเกตเวย์แทนการเดาค่าเริ่มต้นของโปรแกรมแก้ไข และบันทึกวิธีการพิสูจน์ตัวตนที่พวกเขาต้องการ หากองค์กรต้องการวิธีการที่ปลั๊กอินแสดงออกไม่ได้ คำตอบที่ซื่อสัตย์คือไคลเอนต์ที่ได้รับอนุมัติซึ่งทำได้ ไม่ใช่โปรไฟล์ที่ปิดการตรวจสอบเพื่อให้ข้อผิดพลาดหายไป
ให้เจ้าของคนเดียวถือโปรไฟล์และความลับ
เมื่อโปรไฟล์มีอยู่ ให้เปิดใช้งานผ่าน NetworkManager และปล่อยให้ตัวจัดการนั้นเป็นเจ้าของเส้นทางและการเปลี่ยนแปลงตัวแก้ไขชื่อที่เกิดขึ้น การเรียกใช้ไคลเอนต์ SSTP เดี่ยวตัวที่สองขณะที่ NetworkManager กำลังจัดการการเชื่อมต่ออยู่แล้วจะทำให้คุณมีชุดเส้นทางสองชุด การกำหนดค่า DNS สองชุด และเซสชันการดีบักที่ไม่มีแหล่งความจริงเดียว
ความลับก็มีเจ้าของเช่นกัน การเชื่อมต่อที่ทำเครื่องหมายสำหรับใช้ทั่วทั้งระบบเก็บข้อมูลรับรองต่างจากการเชื่อมต่อที่จำกัดเฉพาะเซสชันผู้ใช้ของคุณ และโปรไฟล์ที่สร้างด้วยมือในไฟล์คีย์อาจไม่สามารถอ่านได้โดยเอเจนต์ความลับที่คาดว่าจะให้รหัสผ่านแบบโต้ตอบ ตรวจสอบว่าโปรไฟล์คาดหวังบริบทใดก่อนที่จะพิมพ์รหัสผ่านซ้ำซึ่งไม่เคยเป็นปัญหา การเปิดใช้งานโปรไฟล์เดียวกันจากเทอร์มินัลด้วย nmcli คือการทดสอบที่เร็วที่สุด เพราะพรอมต์ที่ไม่เคยปรากฏบอกคุณว่าเอเจนต์ไม่มีอะไรจะเสนออยู่แล้ว
ตรวจสอบอุโมงค์ เส้นทาง และตัวแก้ไขชื่อแยกกัน
ตัวบ่งชี้ว่าเชื่อมต่อแล้วอ้างเพียงว่าลิงก์ขึ้นแล้ว ตรวจสอบปลายทางที่คุณต้องการจริง ๆ เส้นทางที่บรรทุกมัน และตัวแก้ไขชื่อที่ใช้ ทีละอย่าง แต่ละอย่างอาจผิดได้ในขณะที่อีกสองอย่างปกติ
สำหรับความพยายามที่ล้มเหลว ให้บันทึกเวอร์ชันของแต่ละองค์ประกอบและข้อความข้อผิดพลาดที่ทำให้ปลอดภัย แบ่งปันสิ่งเหล่านั้น ไม่ใช่โปรไฟล์ทั้งหมด เพราะโปรไฟล์อาจมีความลับที่แบ่งปันล่วงหน้าและข้อมูลรับรองที่จัดเก็บไว้ของคุณ
สุดท้าย ตัดการเชื่อมต่อและเชื่อมต่อใหม่ จากนั้นรีบูตหนึ่งครั้ง หากโปรไฟล์ทำงานเฉพาะครั้งแรก ปัญหาอยู่ที่การจัดการความลับหรือความเป็นเจ้าของเส้นทาง และทั้งสองอย่างแก้ไขตอนนี้ถูกกว่ากลางวันทำงาน