บริดจ์ภายในของ SoftEther หรือ SecureNAT: จะเปิดอันไหน

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

เริ่มจากฮับที่คุณกำลังแก้ไขอยู่จริง

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

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

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

บริดจ์ภายในทำอะไรกับที่อยู่

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

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

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

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

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

SecureNAT เพิ่มอะไรและซ่อนอะไร

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

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

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

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

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

เปิดอย่างหนึ่งโดยไม่ทำให้อีกอย่างพัง

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

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

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

ตรวจสอบเกตเวย์และตัวแปลงชื่อบนไคลเอนต์

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

บน Windows รายละเอียดอะแดปเตอร์แสดงการเช่าและตัวแปลงชื่อ และตารางเส้นทางแสดงว่าอุโมงค์เป็นเส้นทางเริ่มต้นจริงหรือไม่

ipconfig /all
route print -4
nslookup intranet.corp.internal

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