Tên máy chủ của cổng Pi có tự cập nhật các tuyến tĩnh không?

Trỏ một tuyến tĩnh tới tên cổng có vẻ như nó phải sống sót khi địa chỉ thay đổi, nhưng nó không. Cái tên sống trong DNS, còn tuyến thì ngồi trong bảng định tuyến của máy khách như một chặng kế tiếp dạng số. Khi Pi chuyển sang địa chỉ khác, mọi người dùng đã cài chặng cũ vẫn tiếp tục gửi lưu lượng tới đúng con số đó. Không có trình phân giải nào được nối vào bảng chuyển tiếp, nên không có gì ghi lại mục đó cho bạn.

Câu trả lời DNS và tuyến là hai đối tượng khác nhau

Giả sử Pi của bạn trả lời tại vpn-gw.lan và chuyển tiếp 10.44.0.0/16 vào một đường hầm. Các máy khách trong 192.168.30.0/24 tiếp cận nó qua một tuyến tĩnh. Khi địa chỉ của Pi chuyển từ 192.168.30.4 sang 192.168.30.11, bản ghi đã theo kịp trong TTL của nó còn các tuyến thì không.

Hai góc nhìn không khớp nhau theo cách dễ bị bỏ qua, vì cả hai đều có vẻ hợp lý khi bạn hỏi riêng chúng:

$ 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

Chỉ dòng đầu tiên quyết định gói tin đi đâu. Dòng thứ hai trả lời một câu hỏi mà hạt nhân chưa từng đặt ra. Một bản ghi có nhiều bản ghi A cũng không trở thành chính sách chuyển đổi khi có sự cố, vì mỗi địa chỉ vẫn phải là một chặng kế tiếp dùng được trên đoạn mạng đó.

Điều gì còn lại trong bảng sau khi lệnh kết thúc

Một tuyến Linux ghi lại hai thứ quan trọng ở đây: chặng kế tiếp như địa chỉ giao thức, và giao diện ra như số chỉ mục. Các thuộc tính tuyến của rtnetlink gọi trường đầu tiên đó là RTA_GATEWAY, và nó chứa byte. Khi mục đã vào chỗ, không có TTL nào gắn vào nó và không có tra cứu nền nào làm mới nó.

Đó là lý do ip route add 10.44.0.0/16 via vpn-gw.lan có thể trông như đang hoạt động. Công cụ phân giải tên trong khi lệnh chạy, ghi địa chỉ thu được và quên hẳn cái tên. Chạy ip route show 10.44.0.0/16 sau đó và bạn nhận lại một địa chỉ nguyên văn.

Hành vi đó đáng để biết trước khi đổ lỗi cho đường hầm.

Những công cụ phân giải tên thay bạn, và khi nào

Một số router và tường lửa thực sự chấp nhận tên máy chủ trong trường tuyến hoặc cổng. Điều quan trọng là khi nào việc phân giải xảy ra. Nếu thiết bị chỉ phân giải tên khi bạn áp dụng cấu hình, mục được lưu cũng tĩnh như một địa chỉ gõ tay, và lần thay đổi địa chỉ sau đó cần thêm một lần áp dụng nữa. Việc trường đó chấp nhận tên không nói cho bạn biết gì về việc làm mới.

Các thiết lập được quản lý thường chia việc. Một đặt trước DHCP hoặc thuê tĩnh giữ Pi ở một địa chỉ, và bản ghi DNS chỉ đi theo hợp đồng thuê. Không có gì phải theo dõi một mục tiêu đang di chuyển vì mục tiêu không di chuyển.

Một trình cập nhật được giám sát là mẫu hợp lệ còn lại, và nó cần một người sở hữu.

Ghim địa chỉ hoặc tự chạy trình cập nhật

Với một LAN nhỏ, đặt trước trên máy chủ DHCP là cách rẻ nhất. Chọn một địa chỉ ngoài nhóm động, gắn nó với địa chỉ MAC của Pi, và xác nhận bằng ip -4 addr show dev eth0 sau lần gia hạn thuê tiếp theo. Sau đó trỏ chặng kế tiếp của máy khách tới địa chỉ đó một lần. Giờ bạn có một cổng ổn định và một bản ghi mô tả nó, và đó là thứ tự mà mối quan hệ này thực sự vận hành.

Nếu Pi thực sự phải chuyển đi, hãy giữ việc sửa tuyến ở một chỗ thay vì sửa tay từng máy khách. Một đoạn script ngắn phân giải, so sánh và thay thế là đủ để bước đó lặp lại được:

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

Lệnh cuối cùng là bài kiểm tra chấp nhận, vì nó in ra cổng mà hạt nhân sẽ thực sự dùng. Nếu địa chỉ in ra vẫn là địa chỉ cũ, script đã chạy trong không gian tên mạng sai hoặc thiếu quyền, và phía DNS không liên quan.

Hãy kiểm tra cả đường về. Pi phải biết cách tới mạng con của máy khách, và tường lửa của nó phải cho phép lưu lượng đường hầm. Một tuyến mặc định được thêm vào để che sự lệch nhau thường giấu đi khoảng trống thật và làm hỏng thứ khác một tuần sau.