ทำไมการค้นหาชื่อจึงล้มเหลวผ่านอุโมงค์ OpenVPN แบบกำหนดเส้นทาง

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

ความเชื่อผิด: อุโมงค์เสียเพราะชื่อล้มเหลว

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

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

ตั้งชื่อกลไกที่ล้มเหลวก่อนตั้งชื่อวิธีแก้ การค้นหาที่ใช้ broadcast ต้องมีเซกเมนต์ ส่วนการค้นหาที่ใช้ตัวแปลงชื่อต้องมีที่อยู่ให้ถาม

สิ่งที่ TUN ส่งและไม่ส่ง

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

ทราฟฟิกการค้นพบไม่เข้ากับแบบจำลองนั้นเลย คำถามชื่อแบบเก่าของ Windows การประกาศ SSDP และคำขอ mDNS ถูกส่งถึงทุกคนในเซกเมนต์แทนที่จะส่งไปยังปลายทางเดียว ลิงก์แบบกำหนดเส้นทางไม่มี «ทุกคน» ให้ส่งไป ทุกกลไกเหล่านั้นตั้งสมมติฐานว่ามีสื่อร่วม

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

บริดจ์ทำงานโดยลบเส้นแบ่ง

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

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

สำหรับห้องแล็บเล็ก ๆ นี่คือการแลกที่ยุติธรรม สำหรับกำลังคนที่กระจายอยู่ แทบจะไม่เคย

การดัน DNS และ WINS คือการแก้ที่แคบกว่า

ให้ไคลเอนต์มีที่ให้ถามอย่างเจาะจง dhcp-option DNS และ dhcp-option DOMAIN ชี้ชื่อภายในไปยังเซิร์ฟเวอร์ที่รู้จักโซน และไคลเอนต์ Windows ที่ยังพึ่ง NetBIOS ก็รับเซิร์ฟเวอร์ WINS ได้ในลักษณะเดียวกัน อุโมงค์ยังคงกำหนดเส้นทางอยู่ และเซกเมนต์ก็อยู่ที่ของมัน

สองเงื่อนไขตัดสินว่าสิ่งนั้นจะได้ผลหรือไม่ เซิร์ฟเวอร์ที่ระบุต้องตอบสำหรับโซน และคำถามต้องได้รับอนุญาตให้ผ่านอุโมงค์

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

หาว่าชั้นใดล้มเหลว

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

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