SoftEther SecureNAT: DHCP กับ NAT เป็นสองการตัดสินใจ

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

สองบริการหลังช่องทำเครื่องหมายเดียว

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

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

การตัดสินใจที่ 1 ใครเป็นผู้ให้ที่อยู่

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

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

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

การตัดสินใจที่ 2 ใครส่งต่อเลยเกตเวย์เสมือน

เมื่อเปิด NAT เสมือน เซิร์ฟเวอร์จะแปลทราฟฟิกขาออกจากฮับและส่งผ่านตารางเส้นทางของโฮสต์ นั่นหมายความว่าห่วงโซ่การส่งต่อคือ จากไคลเอนต์ไปยังเกตเวย์เสมือน จาก NAT เสมือนไปยังสแตกของโฮสต์ จากสแตกของโฮสต์ไปยังเส้นทางเริ่มต้นของมัน แต่ละข้อต่อล้มเหลวได้โดยไม่แตะข้ออื่น และลายเซ็นของความล้มเหลวก็ต่างกัน

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

เส้นทางของโฮสต์เองเป็นเรื่องที่สาม

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

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

ตระกูลที่อยู่ควรมีการตรวจของตัวเอง ตัวอย่าง DHCP บน IPv4 ที่ใช้งานได้ไม่ได้ยืนยันว่าความสามารถ IPv6 ทุกอย่างมีอยู่ในบิลด์ของคุณ ดังนั้นอ่านคู่มือของเวอร์ชันที่คุณรันจริงก่อนสัญญาเรื่องพฤติกรรมสแตกคู่ ส่วน SecureNAT ของคู่มือ ครอบคลุมฟังก์ชัน NAT และ DHCP เสมือนสำหรับรุ่นปัจจุบัน

ตรวจสอบแต่ละการตัดสินใจด้วยการทดสอบของมันเอง

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

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

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