ไคลเอนต์ดั้งเดิมของ SoftEther หรือโปรไฟล์ OpenVPN: เลือกพอร์ตที่ถูกต้อง

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

เลือกตัวรับฟังก่อน แล้วจึงเลือกไคลเอนต์

ตัวรับฟังสองตัว รูปแบบการกำหนดค่าสองแบบ

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

ความเข้ากันได้เป็นเรื่องของเวอร์ชัน ตรวจสอบว่าเวอร์ชันที่ติดตั้งยอมรับอะไร ไม่ใช่ว่าคู่มือ OpenVPN ปัจจุบันเขียนอะไร

ขั้นตอนที่ 1: ค้นหาว่าผู้ให้บริการเปิดใช้ตัวรับฟังใด

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

ถ้าคุณเข้าถึงโฮสต์ได้ ให้ทดสอบพอร์ตที่ได้รับ ไม่ใช่พอร์ตจากบทแนะนำ: openssl s_client -connect vpn.example.com:443 -brief อย่างน้อยก็บอกว่ามี TLS อยู่หรือไม่

ขั้นตอนที่ 2: ใช้ไคลเอนต์และโปรไฟล์ที่ตรงกัน

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

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

ขั้นตอนที่ 3: รักษาการเปรียบเทียบให้ซื่อตรง

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

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

ขั้นตอนที่ 4: ตรวจสอบเส้นทางหลังเชื่อมต่อ

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

บันทึกว่าตัวรับฟังใดและไคลเอนต์เวอร์ชันใดให้ผลลัพธ์ที่ใช้งานได้ มิฉะนั้นคนถัดไปจะทำการค้นพบซ้ำตั้งแต่หมายเลขพอร์ตขึ้นไป