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

สองงานที่ใช้ข้อความชนิดเดียวกัน

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

ดังนั้น ACK จึงเป็นหลักฐานของคำตอบ ไม่ใช่หลักฐานของการจัดสรร ข้อความที่นำหน้ามันเป็นตัวกำหนดว่าถามคำถามใด อ่านบรรทัดคำขอก่อน แล้วส่วนที่เหลือของแทรซมักอธิบายตัวเอง

RRAS ได้แอดเดรสมาจากที่ใด

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

Get-Command -Module RemoteAccess *IPAddress*

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

คลาสผู้ใช้พิสูจน์ได้และพิสูจน์ไม่ได้อะไรบ้าง

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

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

เปรียบเทียบหลักฐาน ไม่ใช่ ACK

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

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

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

บทความที่เกี่ยวข้อง