ชื่อโฮสต์ของเกตเวย์ Pi อัปเดตเส้นทางแบบคงที่ด้วยตัวเองหรือไม่

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

คำตอบ DNS กับเส้นทางเป็นวัตถุคนละอย่าง

สมมติว่า Pi ของคุณตอบที่ vpn-gw.lan และส่งต่อ 10.44.0.0/16 เข้าไปในอุโมงค์ ไคลเอนต์ใน 192.168.30.0/24 เข้าถึงได้ผ่านเส้นทางแบบคงที่ เมื่อแอดเดรสของ Pi ย้ายจาก 192.168.30.4 ไปเป็น 192.168.30.11 เรกคอร์ดติดตามภายใน TTL ของมัน ส่วนเส้นทางไม่ได้ติดตาม

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

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

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

อะไรที่ยังคงอยู่ในตารางหลังจากคำสั่งจบลง

เส้นทางของ Linux บันทึกสองสิ่งที่มีความสำคัญตรงนี้ คือฮอปถัดไปในฐานะแอดเดรสของโปรโตคอล และอินเทอร์เฟซขาออกในฐานะหมายเลขดัชนี แอตทริบิวต์เส้นทางของ rtnetlink เรียกฟิลด์แรกนั้นว่า RTA_GATEWAY และภายในมีไบต์ เมื่อรายการเข้าที่แล้ว ก็ไม่มี TTL ใดผูกอยู่กับมัน และไม่มีการค้นหาเบื้องหลังใดรีเฟรชมัน

นี่คือเหตุผลที่ ip route add 10.44.0.0/16 via vpn-gw.lan อาจดูเหมือนได้ผล เครื่องมือแก้ชื่อขณะคำสั่งทำงาน เขียนแอดเดรสที่ได้ แล้วลืมชื่อไปทั้งหมด รัน ip route show 10.44.0.0/16 หลังจากนั้นแล้วคุณจะได้แอดเดรสตามตัวอักษรกลับมา

พฤติกรรมนั้นควรค่าแก่การรู้ก่อนจะโทษอุโมงค์

เครื่องมือที่แก้ชื่อให้คุณ และเมื่อใด

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

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

ตัวอัปเดตที่มีการเฝ้าดูเป็นรูปแบบที่ชอบธรรมอีกแบบ และมันต้องมีเจ้าของ

ปักหมุดแอดเดรสหรือรันตัวอัปเดตเอง

สำหรับ LAN ขนาดเล็ก การจองบนเซิร์ฟเวอร์ DHCP เป็นวิธีที่ถูกที่สุด เลือกแอดเดรสนอกพูลไดนามิก ผูกกับแอดเดรส MAC ของ Pi และยืนยันด้วย ip -4 addr show dev eth0 หลังการต่ออายุสัญญาเช่าครั้งถัดไป จากนั้น ชี้ฮอปถัดไปของไคลเอนต์ไปที่แอดเดรสนั้นหนึ่งครั้ง. ตอนนี้คุณมีเกตเวย์ที่มั่นคงและเรกคอร์ดที่อธิบายมัน และนั่นคือลำดับที่ความสัมพันธ์นี้ทำงานจริง

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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