DNS ส่วนตัวของ Azure ผ่าน VPN: ปลายทาง resolver หรือ forwarder

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

อุโมงค์ขนคำถาม ไม่ใช่ความรู้เรื่องโซน

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

การแก้ไขมีสองครึ่งที่แยกจากกันได้ง่าย ครึ่งหนึ่งคือ resolver ภายใน VNet ที่รับคำถามที่มาทางอุโมงค์ อีกครึ่งคือ forwarder แบบมีเงื่อนไขฝั่งองค์กรที่ส่งพื้นที่ชื่อเดียวไปยัง resolver นั้น ไม่มีครึ่งใดทำงานได้ลำพัง

สมมติว่าโซนคือ cloud.corp.example สำหรับส่วนที่เหลือของคำอธิบายนี้ และถือว่าทุกที่อยู่เป็นตัวอย่าง

ตัวเลือก A: ปลายทางขาเข้าที่จัดการให้

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

จากนั้นบนเซิร์ฟเวอร์ DNS ฝั่งองค์กร คุณสร้าง forwarder แบบมีเงื่อนไขสำหรับพื้นที่ชื่อที่แน่นอนไปยังที่อยู่นั้น:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

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

ราคาที่ต้องจ่ายคือตอนนี้คุณมีทรัพยากร resolver การมอบหมายซับเน็ตและค่าใช้จ่าย ซึ่งเป็นจริงแม้ปริมาณคำถามจะน้อยมาก

ตัวเลือก B: VM forwarder ภายใน VNet

ดีไซน์เก่ารันซอฟต์แวร์ DNS บน VM ธรรมดาใน VNet เช่น Windows DNS, BIND หรือ dnsmasq โดยโซนส่วนตัวถูกโฮสต์ในเครื่องหรือส่งต่อไปยัง resolver ของ Azure ที่ 168.63.129.16 forwarder แบบมีเงื่อนไขฝั่งองค์กรชี้ไปที่ที่อยู่ส่วนตัวของ VM นั้น

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

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

แบบไหนเหมาะกับการดำเนินงานของคุณ

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

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

ตรวจสอบเส้นทางตามลำดับ

ยืนยันว่าโซนเชื่อมกับ VNet ที่มี resolver และ forwarder ฝั่งองค์กรระบุพื้นที่ชื่อไม่ใช่โดเมนแม่ forwarder สำหรับ corp.example จะไม่ตรงกับ cloud.corp.example เว้นแต่ resolver เองจะมอบหมาย และความไม่ตรงกันทำให้เกิดคำตอบปฏิเสธที่สะอาดซึ่งดูเหมือนบันทึกที่หายไป

จากนั้นตรวจสอบว่าคำถามไปถึงปลายทาง: แหล่งต้นทางฝั่งองค์กรต้องการเส้นทางไปยังที่อยู่ resolver และเส้นทางกลับ และควรอนุญาตพอร์ต 53 ทั้ง UDP และ TCP ในจุดที่นโยบายอนุญาต NSG ไม่สามารถให้บันทึกโซนที่หายไปได้ และโซนที่ถูกต้องก็ไม่สามารถตอบคำถามที่ไม่เคยมาถึงได้

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