SoftEther VPN Azure: เส้นทางผ่านรีเลย์ ไม่ใช่พอร์ตที่เปิด
VPN Azure คือรีเลย์ที่เซิร์ฟเวอร์ต่อออกไปหาเอง ไม่ใช่การส่งต่อพอร์ต ช่วยได้หลัง NAT พาข้อมูลเพียงบางโปรโตคอล และเพิ่มการพึ่งพาที่ต้องเฝ้าดู
เซิร์ฟเวอร์ของคุณอยู่หลังเราเตอร์ที่คุณกำหนดค่าไม่ได้ แผนที่ชัดเจนอย่างการส่งต่อพอร์ตจึงใช้ไม่ได้ VPN Azure มีอยู่เพื่อสถานการณ์นั้นโดยเฉพาะ และแก้ปัญหาด้วยการกลับทิศของการเชื่อมต่อแรก เซิร์ฟเวอร์ต่อออกไปยังรีเลย์ และไคลเอนต์ไปถึงรีเลย์แทนที่จะไปถึงเซิร์ฟเวอร์ การเข้าใจการกลับทิศนี้อธิบายทั้งสิ่งที่บริการแก้ไขและทุกขีดจำกัดที่คุณจะพบในภายหลัง
อะไรเปลี่ยนไปในเส้นทาง
ด้วยตัวรับฟังแบบเดิม ไคลเอนต์เปิดการเชื่อมต่อ TCP ไปยังที่อยู่สาธารณะที่เราเตอร์ของคุณส่งต่อไปยังเซิร์ฟเวอร์ ด้วยรีเลย์ เซิร์ฟเวอร์รักษาการเชื่อมต่อขาออกไปยังโครงสร้างพื้นฐานของรีเลย์ และรีเลย์รับการเชื่อมต่อของไคลเอนต์แล้วส่งมอบภาระให้เซิร์ฟเวอร์ที่รออยู่ ไม่มีพอร์ตขาเข้าถูกเปิด ไม่ต้องใช้ที่อยู่แบบคงที่ และเราเตอร์ไม่ถูกแตะต้อง ในมุมมองของไฟร์วอลล์ เซิร์ฟเวอร์เป็นไคลเอนต์ขาออกธรรมดา จึงเป็นเหตุให้เครือข่ายที่จำกัดอนุญาต
รีเลย์กำหนดชื่อบนโดเมนของตัวเองให้เซิร์ฟเวอร์นั้น และไคลเอนต์ถูกกำหนดค่าให้เชื่อมต่อที่นั่น
ชื่อนั้นเป็นของบริการรีเลย์ ซึ่งไม่ใช่ Microsoft Azure VPN Gateway แม้ทั้งสองจะถูกเรียกว่า Azure อะไรบางอย่าง การปฏิบัติต่อทั้งสองราวกับแทนกันได้จะให้การกำหนดค่าที่ไม่สามารถทำงานได้
โปรโตคอลใดผ่านรีเลย์ได้
รีเลย์ขนส่งโปรโตคอล SoftEther และโครงการบันทึก SSTP เป็นตัวเลือกสำหรับไคลเอนต์ ซึ่งมีประโยชน์เพราะ Windows มาพร้อมไคลเอนต์ SSTP อย่างไรก็ตามมันไม่ได้กลายเป็นตัวขนส่งทั่วไปสำหรับทุกตัวรับฟังบนโฮสต์ ตัวรับฟัง OpenVPN ตัวตอบสนอง IPsec และบริการ L2TP ต่างต้องมีจุดปลายที่เข้าถึงได้ของตัวเอง และไม่มีตัวใดถูกขนส่งผ่านรีเลย์เพียงเพราะเซิร์ฟเวอร์ SoftEther เชื่อมต่ออยู่
โปรไฟล์ไคลเอนต์จึงชี้ไปที่ชื่อรีเลย์แทนที่อยู่เซิร์ฟเวอร์ และโปรไฟล์ที่มีอยู่ซึ่งสร้างสำหรับการเชื่อมต่อโดยตรงจะไม่ทำงานโดยไม่เปลี่ยนแปลง ตรวจสอบรายการไคลเอนต์ที่รองรับสำหรับเวอร์ชันที่คุณใช้งานก่อนออกแบบรอบโปรโตคอลที่รีเลย์ไม่ขนส่ง
สิ่งที่รีเลย์ไม่ได้ทำให้คุณ
รีเลย์คือการขนส่ง มันไม่ได้สร้างผู้ใช้ ฮับเสมือน นโยบายการเข้าถึง หรือเส้นทาง และไม่รู้อะไรเกี่ยวกับเครือข่ายส่วนตัวหลังเซิร์ฟเวอร์ของคุณ ถ้าไคลเอนต์ระยะไกลต้องเข้าถึงซับเน็ต LAN เซิร์ฟเวอร์ยังต้องการการกำหนดค่าสะพานหรือเส้นทาง เส้นทางขากลับ และนโยบายไฟร์วอลล์ที่ทำให้สิ่งนั้นทำงาน แผนที่อยู่ที่ทับซ้อนกันทั้งสองด้านก็มองไม่เห็นจากรีเลย์เช่นกัน และยังเป็นปัญหาที่คุณต้องแก้
การตั้งค่าความปลอดภัยที่รองรับก็เป็นของคุณในการเลือก เอกสารของโครงการมีตัวอย่างแพลตฟอร์มเก่า และการคัดลอกการตั้งค่าการเข้ารหัสหรือใบรับรองเก่าจากภาพหน้าจอเก่าเป็นวิธีที่ดีในการสร้างอุโมงค์ที่ไม่มีใครตรวจสอบได้ ใช้คำแนะนำปัจจุบันสำหรับเวอร์ชันที่คุณใช้งาน
การตรวจสอบใบรับรองและการพิสูจน์ตัวตนผู้ใช้ยังคงเป็นความรับผิดชอบของเซิร์ฟเวอร์ และรีเลย์ไม่เคยทดแทนทั้งสองอย่าง
ดำเนินการมันในฐานะการพึ่งพา
ความพร้อมใช้งานตอนนี้รวมถึงบุคคลที่สาม เมื่อรีเลย์เข้าถึงไม่ได้ ไคลเอนต์ก็เชื่อมต่อไม่ได้ไม่ว่าเซิร์ฟเวอร์ของคุณจะแข็งแรงเพียงใด และความล้มเหลวดูเหมือนปัญหาไคลเอนต์จากภายนอก เฝ้าดูเส้นทางรีเลย์แยกจากสุขภาพของเซิร์ฟเวอร์ และเก็บแผนสำรองที่บันทึกไว้ เช่น ตัวรับฟังโดยตรงบนที่อยู่อื่น สำหรับวันที่มันสำคัญ
ความหน่วงเป็นไปตามภูมิศาสตร์ของรีเลย์ไม่ใช่ความใกล้ชิดของผู้ใช้ของคุณ ซึ่งคุ้มค่าที่จะวัดก่อนสัญญาประสิทธิภาพแบบโต้ตอบผ่านมัน
ตรวจสอบตัวตนของเซิร์ฟเวอร์แล้วจึงตรวจสอบเส้นทางแอปพลิเคชันจริง ไม่ใช่แค่แบนเนอร์การเชื่อมต่อที่สำเร็จ และตรวจสอบว่าทรัพยากรที่คุณต้องการเข้าถึงได้ผ่านตระกูลที่อยู่ที่รีเลย์ขนส่งหรือไม่ บันทึกชื่อรีเลย์ โปรโตคอลที่ใช้ และแผนสำรอง เพราะข้อเท็จจริงสามข้อนั้นตอบคำถามในอนาคตส่วนใหญ่เกี่ยวกับลิงก์นี้