ทำไมโปรไฟล์ OpenVPN จึงนำเข้าสู่ SoftEther ไม่ได้

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

สองไฟล์ สองสัญญา

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

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

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

อ่านเซิร์ฟเวอร์ก่อนแตะบล็อกใบรับรอง

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

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

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

พอร์ต UDP ที่หายไปจากรายการตัวรับฟังคือคุณสมบัติที่ถูกปิด ไม่ใช่ปัญหาไฟร์วอลล์

สิ่งที่ไคลเอนต์ดั้งเดิมต้องการและโปรไฟล์ให้ไม่ได้

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

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

เก็บคีย์ส่วนตัวให้ห่างจากบริการแปลงใด ๆ เพราะคีย์ที่ออกจากเครื่องต้องถือว่าถูกเปิดเผยแล้ว

สิ่งที่ตัวรับฟังที่เข้ากันได้กับ OpenVPN ยอมรับ

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

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

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

พิสูจน์เส้นทางก่อนแก้ไขคำสั่ง

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

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

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