169.254 ผ่าน VPN: ที่อยู่นี้ไม่เคยถูกส่งต่อตามเส้นทางได้เลย
ปลายทางแบบ link-local ถูกทิ้งก่อนถึงอุโมงค์ การเพิ่มเส้นทางจึงเพียงขยายความล้มเหลว ให้เลือกแก้ซับเน็ตหรือสร้างบริดจ์
คุณเพิ่มเส้นทาง อุโมงค์ขึ้นมา แต่ ping ไปยังอีกฝั่งก็ยังตายด้วยการสูญหายทั้งหมด ไม่ใช่ «network unreachable» ความต่างนี้สำคัญ เพราะมันหันสายตาจากตารางเส้นทางมาที่ตัวที่อยู่เอง ปลายทาง 169.254 เป็น link-local และขอบเขตของมันสิ้นสุดที่ hop แรกตามการออกแบบ
การตัดสินใจถัดมาแคบ: แก้ซับเน็ตฝั่งเซิร์ฟเวอร์ หรือขยายส่วนของเลเยอร์ 2 เส้นทางที่กว้างกว่าก็เพียงแพร่ความล้มเหลวเดิมไปยังปลายทางมากขึ้น
ที่อยู่ไม่ได้ขาดเส้นทาง แต่มันถูกส่งต่อตามเส้นทางไม่ได้
ที่อยู่ IPv4 แบบ link-local กำหนดให้ตัวเองเมื่อไม่มีอะไรที่ดีกว่าตอบกลับ การกำหนดที่อยู่ส่วนตัวอัตโนมัติใน Windows มาจากตรงนี้ ช่วงนี้ถูกใช้บนทุกการเชื่อมต่อพร้อมกัน และนั่นคือเหตุผลที่มันทำงานได้ โฮสต์สองเครื่องในส่วนเดียวกันคุยกันได้โดยไม่ต้องประสานงาน
คุณสมบัติเดียวกันนี้ทำให้เราเตอร์ต้องไม่ส่งแพ็กเก็ตเหล่านี้ข้ามเครือข่าย การรับแพ็กเก็ตที่ส่งไปยังปลายทาง link-local แล้วส่งออกทางอินเทอร์เฟซอื่นจะสร้างความกำกวม เพราะ «ท้องถิ่น» ของผู้ส่งและของผู้รับเป็นคนละที่ ไม่มีการค้นหาที่ตัดสินได้ว่าหมายถึงอันไหน การส่งต่อตรงนี้ไม่ใช่ตัวเลือกนโยบายที่ผู้ดูแลเปิดได้
ดังนั้นเกตเวย์ที่ตั้ง 169.254.1.10 ว่าเข้าถึงได้ผ่านอุโมงค์กำลังขอให้เคอร์เนลทำสิ่งที่รูปแบบที่อยู่ห้ามไว้ แพ็กเก็ตถูกทิ้งก่อนถึงโฮสต์ปลายทางไกลมาก
ทำไมอุโมงค์จึงทำให้ปัญหาเรื่องขอบเขตมองเห็นได้
อินเทอร์เฟซ TUN ขนแพ็กเก็ต IP ระหว่างสองฝ่ายและไม่มีส่วนที่ใช้ร่วมกันอยู่ข้างหลัง ไม่มีการกระจายสัญญาณ ไม่มี ARP สำหรับอีกฝั่ง และไม่มีการค้นหาเพื่อนบ้าน
อาการตรงกันพอดีเมื่อรู้ว่าต้องหาอะไร เส้นทางอยู่ในตาราง ping รายงานการสูญหายทั้งหมด ตารางเพื่อนบ้านแสดงรายการที่ไม่สมบูรณ์ การบันทึกบนอุโมงค์แสดงแพ็กเก็ตออกไป ซึ่งทำให้คนไปดูปลายทางไกลแทนที่จะดูชั้นของที่อยู่
ใน Windows มีอาการที่สองที่ดูไม่เกี่ยวข้องแต่มีรากเดียวกัน อะแดปเตอร์ที่เหลือเพียงที่อยู่ link-local ไม่มีเกตเวย์ที่ใช้ได้ โปรไฟล์ไฟร์วอลล์จึงตกไปที่ public อุโมงค์ไม่ใช่สาเหตุ ที่อยู่คือสาเหตุ
ตัดสินด้วยสามคำถาม
การเลือกว่าจะแก้ซับเน็ตหรือทำบริดจ์ขึ้นกับสภาพสามอย่าง
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
กรณีส่วนใหญ่หยุดที่คำถามแรก โฮสต์ที่แสดงที่อยู่ link-local มักหมายความว่า DHCP ไม่ตอบ สายหรือ VLAN ผิด หรือมีคนพิมพ์ที่อยู่เอง การแก้ไขถูกกว่าการทำงานกับอุโมงค์ใด ๆ และเอาปัญหาออกจากไคลเอนต์ในอนาคตทุกเครื่อง
ตรวจฝั่งเซิร์ฟเวอร์ก่อนสันนิษฐานอะไร รัน ip addr show และ ip route บนโฮสต์ และ arp -n หรือ route print -4 บนไคลเอนต์
บริดจ์มีค่าใช้จ่ายอะไรเมื่อมันคือคำตอบที่ถูก
การทำบริดจ์ระหว่างอะแดปเตอร์จริงกับอะแดปเตอร์ TAP ทำให้ไคลเอนต์ระยะไกลเป็นส่วนหนึ่งของโดเมนกระจายสัญญาณท้องถิ่น
ค่าใช้จ่ายเป็นจริงและควรบอกก่อนใครตกลง ทราฟฟิกกระจายสัญญาณข้ามอุโมงค์ ไคลเอนต์เปิดรับส่วนท้องถิ่นทุกจุดประสงค์ ไม่ใช่เฉพาะบริการที่ต้องการ และเซิร์ฟเวอร์ต้องส่งต่อเฟรมแทนการหาเส้นทางให้แพ็กเก็ต เหมาะกับโต๊ะทดลองและเป็นค่าตั้งต้นที่ไม่ดีสำหรับการเข้าถึงระยะไกล
เมื่อทำบริดจ์ต้องมีทั้งสองส่วน บริดจ์บนเซิร์ฟเวอร์และเส้นทางในโปรไฟล์ไคลเอนต์ บริดจ์อย่างเดียวทำให้ไคลเอนต์เดา และเส้นทางอย่างเดียวแก้ชั้นของที่อยู่ไม่ได้