DNS ของ VPN ใช้งานได้ แต่ชื่อ .local ยังล้มเหลว: ใครเป็นคนแก้

เครื่องสองเครื่องบน VPN เดียวกัน มีชื่อโฮสต์เดียวกัน แต่มีเพียงเครื่องเดียวที่แก้ชื่อได้: ความต่างมักไม่ใช่อุโมงค์ แต่เป็นตัวแก้ไขชื่อใดที่ตอบ คำขอนั้นอาจผ่านสวิตช์บริการชื่อ ผ่านสตับของ systemd-resolved หรือผ่านตัวแก้ไขที่แอปพลิเคชันพกมาเอง และแต่ละตัวใช้กฎของตนกับส่วนต่อท้ายเดียวกัน จุดที่กฎแยกจากกันคือส่วนต่อท้าย เพราะ .local ไม่ใช่ป้ายที่เป็นกลาง หาให้ได้ว่าโปรแกรมที่ล้มเหลวใช้เส้นทางใดจริง ๆ ก่อนจะเปลี่ยนลำดับการทำงานของสิ่งใด

ตัวแก้ไขสองตัว สองคำตอบที่ต่างกัน

การค้นหาแบบ glibc ดั้งเดิมไล่ตามบรรทัด hosts: ใน nsswitch.conf และถามแต่ละโมดูลตามลำดับจนกว่าตัวหนึ่งจะตอบ ไคลเอนต์ที่คุยกับ systemd-resolved ผ่านสตับลิสเทนเนอร์จะถามโปรเซสเดียวแทน และโปรเซสนั้นใช้นโยบายต่อลิงก์บวกกับกรณีพิเศษของตัวเอง แอปพลิเคชันที่พกตัวแก้ไขของตัวเองมาหรือลิงก์ไลบรารีที่ทำเช่นนั้นสามารถข้ามทั้งสองทางได้ ดังนั้นชื่อโฮสต์หนึ่งชื่อจึงมีเจ้าของได้สามรายบนเครื่องเดียว และมีเพียงรายเดียวที่รู้ว่า VPN ตั้งใจอะไร

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

คำสั่งใดที่ถามตัวแก้ไขชื่อของคุณจริง ๆ

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

ทำไม .local จึงข้ามโซน unicast ของคุณ

เอกสารอ้างอิงของ systemd-resolved ระบุว่าชื่อที่มีหลายป้ายซึ่งลงท้ายด้วย .local มักไปยัง DNS แบบ multicast เมื่อเปิด mDNS แทนที่จะไปยัง DNS แบบ unicast ปกติ RFC 6762 กันพื้นที่ชื่อนั้นไว้สำหรับ multicast แบบลิงก์โลคอล โซนองค์กรจึงมีบันทึกที่ถูกต้องซึ่งไม่เคยถูกถามสำหรับส่วนต่อท้ายนั้นได้ อุโมงค์อาจกำหนดเส้นทางให้ตัวแก้ไขได้อย่างสมบูรณ์แบบแต่ยังแพ้การแข่งก็ได้ ping ที่สำเร็จจากแคชไม่ได้บอกอะไรเกี่ยวกับการค้นหาที่เพิ่งเกิดขึ้น

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

ข้อยกเว้นแคบ ๆ ชนะการจัดลำดับใหม่ทั้งระบบ

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

มันยังอยู่รอดหลังการตัดการเชื่อมต่อ เพราะนโยบายของลิงก์ถูกนำมาใช้อีกครั้งเมื่อลิงก์กลับมา การแก้ไข nsswitch.conf ที่ใช้ร่วมกันเป็นทางเลือกที่ล่อใจและแพงกว่า เพราะมันเปลี่ยนพฤติกรรมการค้นหาของทุกชื่อบนเครื่อง รวมถึงการค้นหาภายในเครื่อง การปิดเดมอน multicast ก็ไม่เทียบเท่า: มันลบพฤติกรรมภายในเครื่องโดยไม่สอนโซนองค์กรให้ตัวแก้ไขใดเลย ถ้าบริการเป็นของใหม่ไม่ใช่ของที่สืบทอดมา ให้วางไว้ใต้โดเมนย่อยที่องค์กรของคุณควบคุมและข้ามการแข่งขันไปเลย เลือกข้อยกเว้นแคบ ๆ เมื่อชื่อถูกตรึงในเฟิร์มแวร์หรือพิมพ์บนฉลาก และเลือกโดเมนย่อยใหม่เมื่อคุณยังควบคุมไคลเอนต์อยู่

ต้องพิสูจน์อะไรหลังการเปลี่ยนแปลง

พิสูจน์การแก้ไขด้วยการค้นหาของแอปพลิเคชันเอง ไม่ใช่เครื่องมือที่คุณติดตั้งไว้ทดสอบ และล้างแคชใดก็ตามที่อาจตอบแทนมัน จากนั้นยืนยันเส้นทางของตัวแก้ไขและลิงก์ที่ให้คำตอบ สุดท้ายตรวจสอบว่าการค้นหาภายในเครื่องยังทำงานเหมือนก่อนการเปลี่ยนแปลง เพราะเครื่องพิมพ์ที่หยุดปรากฏคือส่วนที่ผู้คนสังเกตเห็นเป็นที่สุดท้าย คำสั่งทั้งสามนี้ตรวจสอบชื่อ เส้นทาง และอัตลักษณ์ TLS ตามลำดับนั้น:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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