โปรไฟล์การเชื่อมต่อ SoftEther: ตรวจสอบหกฟิลด์ก่อนนำเข้า

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

การตรวจสอบ 1: ชื่อโฮสต์และพอร์ต

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

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

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

การตรวจสอบ 2: โปรโตคอลกำหนดไคลเอนต์

เซิร์ฟเวอร์ที่เสนอวิธีเข้าถึงหลายวิธีไม่ได้เปลี่ยนไฟล์ที่ส่งออกหนึ่งไฟล์ให้เป็นโปรไฟล์ที่ทุกไคลเอนต์เปิดได้ Each method has its own format, its own client and its own failure modeและการผสมกันทำให้เกิดข้อผิดพลาดที่ฟังดูเหมือนปัญหาข้อมูลรับรอง ตัดสินว่าไฟล์ประกาศวิธีใดก่อนตัดสินว่าไคลเอนต์ใดจะเปิดมัน

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

อ่านคำประกาศภายในไฟล์ ไม่ใช่นามสกุล ไฟล์ที่ตั้งชื่อตาม OpenVPN ย่อมเป็นโปรไฟล์ OpenVPN ตามนิยาม ขณะที่โปรไฟล์ SoftEther เป็นการกำหนดค่าขนาดเล็กที่ไคลเอนต์ SoftEther นำเข้า และทั้งสองใช้แทนกันไม่ได้ หากวิธีที่ประกาศเป็นวิธีที่คุณให้บริการไม่ได้ นั่นตอบคำถามเรื่องการนำเข้า

การตรวจสอบ 3: ฮับ ผู้ใช้ และบทบาทผู้ดูแลระบบ

สำหรับการเข้าถึงแบบเนทีฟ โปรไฟล์ระบุ Virtual Hub และผู้ใช้ภายใน A hub is a logical VPN server instance with its own users and its own settingsและผู้ใช้เป็นสมาชิกของฮับนั้นด้วยการรับรองความถูกต้องของตนเอง ไม่มีสิ่งใดเป็นผู้ดูแลเซิร์ฟเวอร์ซึ่งควบคุมผู้ฟัง ฮับ และผู้ใช้ทุกคนในการติดตั้ง โปรไฟล์ไคลเอนต์ไม่ควรมาพร้อมการควบคุมนั้นติดมาด้วย เมื่อมีคนส่งข้อมูลรับรองผู้ดูแลระบบให้คุณเพื่อให้ไคลเอนต์ทำงาน การจัดวางนั้นผิดไม่ว่าจะเชื่อมต่อได้หรือไม่

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

การตรวจสอบ 4: ไฟล์ละเอียดอ่อนเท่ากับสิ่งที่มันบรรจุ

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

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

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

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

การตรวจสอบ 5: ทดสอบแอปพลิเคชัน ไม่ใช่ไฟสถานะ

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

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

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