Azure P2S DNS ล้มเหลวเมื่อ resolver อยู่ใน VNet ที่เพียร์กัน

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

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

สองโครงสร้าง หนึ่งความต่าง

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

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

ฝั่ง A: อนุญาตการส่งผ่านเกตเวย์ที่เจ้าของเกตเวย์

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

ตั้งค่า Allow gateway transit บนการเพียร์จาก VNet2 ไปยัง VNet1 คุณสมบัตินี้เป็นของออบเจ็กต์การเพียร์ ไม่ใช่ของทรัพยากรเกตเวย์ จึงอ่านและเปลี่ยนแปลงได้ในใบมีดการเพียร์ นั่นคือฝั่ง A ทั้งหมด

ฝั่ง B: ใช้เกตเวย์ระยะไกลที่คู่เพียร์

อีกครึ่งคือภาพสะท้อน บนการเพียร์จาก VNet1 กลับไปยัง VNet2 ให้เปิด Use remote gateways การเปิดแฟล็กเดียวกันที่ทั้งสองปลาย หรือเพียงปลายเดียว จะเหลือเส้นทางที่สร้างครึ่งเดียวและอาการเดิมไม่ถูกแตะต้อง เฉพาะเครือข่ายที่มีเกตเวย์ VPN เท่านั้นที่อนุญาตการส่งผ่าน และคู่เพียร์คือฝ่ายที่ใช้มัน

อ่านคุณสมบัติทั้งสองบนเครือข่ายทั้งสอง แทนที่จะเชื่อใบมีดพอร์ทัลที่เปิดล่าสุด

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

การเห็นทั้งคู่เคียงกันเป็นวิธีที่เร็วที่สุดในการจับการตั้งค่าที่กลับด้าน การเพียร์ที่รายงาน AllowGatewayTransit false ทางฝั่งเกตเวย์อธิบายความล้มเหลวทั้งหมดได้โดยไม่ต้องดักแพ็กเก็ต

สิ่งที่ไคลเอนต์ยังต้องได้รับ

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

ถามรีโซลเวอร์จากแล็ปท็อปที่เชื่อมต่อก่อนจะเปลี่ยนสิ่งอื่น

nslookup dc01.corp.example 10.1.0.4

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

เปรียบเทียบสัญญาเดียวกันทางฝั่งไซต์ถึงไซต์

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

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

ก่อนจะโทษเกตเวย์

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

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

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