mDNS ภายใน VPN: ทำไมชื่อ .local จึงไม่ถูกแก้ไข

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

ตรวจสอบว่าอะไรถูกแก้ไขในวันนี้ และอะไรเพียงดูเหมือนถูกแก้ไข

แยกคำถามสองข้อก่อน คำถาม unicast สำหรับชื่อโฮสต์ถามตัวแก้ไข ขณะที่การค้นหา _ipp._tcp ถามลิงก์ท้องถิ่น บน Linux avahi-browse -a แสดงสิ่งที่ multicast DNS มองเห็นได้ และ resolvectl query name.local แสดงสิ่งที่สแต็กตัวแก้ไขทำกับชื่อนั้น บน macOS dns-sd -B _ipp._tcp แสดงรายการบริการที่ค้นพบโดยไม่ต้องมีที่อยู่ก่อน

หากที่อยู่ตอบแต่ชื่อไม่ตอบ การกำหนดเส้นทางทำงานและการค้นพบไม่ทำงาน ชื่อ .local ยังสามารถตอบได้บนโฮสต์เองผ่าน nss-mdns โดยไม่ต้องติดตั้ง avahi-browse ดังนั้น getent หรือ ping ที่สำเร็จไปยังชื่อนั้นไม่ใช่หลักฐานว่าการค้นพบข้ามอุโมงค์ไปแล้ว ผลการค้นหาและผลของตัวแก้ไขเป็นหลักฐานคนละอย่าง แอปแคชสิ่งที่ค้นพบ จึงมักเกิดความล้มเหลวหลายชั่วโมงหลังเชื่อมต่อ ไม่ใช่ตอนเชื่อมต่อ ปิดและเปิดแอปอีกครั้ง แล้วตรวจว่าบันทึกในแคชมีชื่อหรือที่อยู่ เพราะที่อยู่ยังใช้งานได้อีกนานหลังจากการค้นพบหยุดลง

ทำไมคำถามจึงไม่เคยข้ามอุโมงค์

multicast DNS ส่งคำถามไปยัง 224.0.0.251 ภายในบล็อกควบคุมเครือข่ายท้องถิ่น บนพอร์ต UDP 5353 เราเตอร์ไม่ส่งต่อที่อยู่จากบล็อกนั้น คำถามจึงอยู่บนลิงก์ที่ส่งไป ผู้ส่งยังตั้งค่า TTL ของ IP หรือขีดจำกัดฮ็อปของ IPv6 เป็น 255 เพื่อให้ผู้รับปฏิเสธแพ็กเก็ตที่ข้ามเราเตอร์ไปแล้ว นี่คือวิธีที่โปรโตคอลตรวจจับการปลอมแปลงนอกลิงก์ ไม่ใช่วิธีที่มันยังคงอยู่ภายใน ความเป็นท้องถิ่นมาจากที่อยู่ปลายทาง ไม่ใช่จาก TTL หนึ่งฮ็อป

ประเภทของอุโมงค์ก็สำคัญ อินเทอร์เฟซแบบ tun ส่งเฉพาะแพ็กเก็ต IP และไม่มีอย่างอื่น กลุ่ม multicast จึงไม่รอดผ่านไปได้ สะพานแบบ tap ขยายโดเมนการออกอากาศเอง นี่คือเหตุผลที่การออกแบบเก่าบางแบบใช้สะพานแทนการกำหนดเส้นทาง และรับปัญหาทุกอย่างที่สะพานนำมา

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

เลือกการออกแบบชื่อที่คุณดูแลได้

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

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

พิสูจน์บริการ ไม่ใช่ชื่อ

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

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