DNS ของเกสต์ VirtualBox พังเมื่อโฮสต์เชื่อมต่อ VPN

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

ยืนยันว่าคุณกำลังตรวจสอบโหมดอะแดปเตอร์ใด

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

เครื่องเสมือนหนึ่งเครื่องสามารถมีอะแดปเตอร์สองตัวในโหมดต่างกันได้ และตัวที่ได้รับผลกระทบไม่ใช่ตัวแรกเสมอ

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

ติดตามชื่อหนึ่งชื่อผ่านรีโซลเวอร์ของเกสต์

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

ภายในเกสต์ ให้ดูว่ารีโซลเวอร์ถูกกำหนดให้ใช้อะไรจริง ๆ บนเกสต์ Ubuntu ที่รัน systemd-resolved สถานะรายลิงก์จะแสดงเซิร์ฟเวอร์ที่เข้ามา และไฟล์ resolv.conf อาจมีเพียงที่อยู่ stub ซึ่งถูกต้องไม่น่าสงสัย ไฟล์ที่แก้ด้วยมือหรือไคลเอนต์ DNS ที่เข้ารหัสแยกต่างหากอาจส่งคำค้นไปที่อื่นทั้งหมด จดสิ่งที่พบไว้ก่อนเปลี่ยนแปลง

resolvectl status
resolvectl query app.internal.example

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

ลองโหมดรีโซลเวอร์ของโฮสต์บนอะแดปเตอร์นั้น

ตัวเลือก NAT DNS ของ VirtualBox อธิบายกลไกที่ต่างกัน และความต่างนั้นสำคัญเมื่อรีโซลเวอร์ของโฮสต์เองเปลี่ยนไปพร้อมกับอุโมงค์ พร็อกซี DNS ส่งต่อคำขอของเกสต์ไปยังเซิร์ฟเวอร์ที่ได้รับมา โหมดรีโซลเวอร์ของโฮสต์ดักจับคำขอและเรียก DNS API ของโฮสต์ และนั่นคือโหมดที่ตามรีโซลเวอร์ Windows ที่ไคลเอนต์ VPN กำหนดค่าใหม่

เปิดกลไกผิดแล้วคำสั่งก็ยังสำเร็จในขณะที่พฤติกรรมไม่เปลี่ยน ซึ่งเป็นวิธีที่สับสนในการเสียเวลาช่วงบ่าย

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

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

ทำการทดสอบเดิมซ้ำตลอดการเชื่อมต่อ VPN ใหม่

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

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

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