Bạn có cần DNS động cho máy chủ VPN tại nhà không?

Phần lớn sự cố VPN tại nhà mà người ta hỏi tôi không phải sự cố DNS, vậy mà họ vẫn mua gói DNS động trước tiên. Trước khi cấu hình bất cứ thứ gì, hãy quyết định xem tên máy có phải là phần thực sự hỏng không. Trình cập nhật ghi lại bản ghi khi địa chỉ mà ISP cấp cho bạn thay đổi; nó không thể mở cổng, xuyên qua NAT của nhà mạng hay khiến một phiên WireGuard đang chạy nhận ra điểm cuối của nó đã đổi. Ba điều kiện quyết định DNS động là toàn bộ giải pháp hay chỉ một dòng của nó.

Điều kiện một: địa chỉ của bạn thực sự thay đổi

Địa chỉ nhà thay đổi vì những lý do tầm thường: modem đồng bộ lại sau khi mất điện, ISP cân bằng lại một nhóm, một hợp đồng thuê mới đến sau đợt gián đoạn dài. Ở một số đường truyền chúng cũng hiếm khi thay đổi, và tôi đã thấy cùng một địa chỉ tồn tại cả năm; gói doanh nghiệp thường có địa chỉ tĩnh. Nếu mười hai tháng không có gì thay đổi, một bản ghi A sửa tay là một tiến trình nền ít phải giữ sống hơn.

Đo thay vì đoán. Đọc địa chỉ WAN trên trang trạng thái của router, rồi so với thứ thế giới bên ngoài nhìn thấy. Chạy lệnh này từ một máy trong LAN:

curl -fsS https://api.ipify.org; echo

Nếu hai giá trị khác nhau, có thứ gì đó đang dịch phía trước router và không bản cập nhật tên máy nào sửa được. Địa chỉ trong 100.64.0.0/10 là dải dùng chung cho NAT cấp nhà mạng, và đó là lý do thường gặp khiến một tên được cập nhật đúng vẫn hết thời gian chờ từ bên ngoài.

Điều kiện hai: máy khách phân giải lại tên

TTL ngắn là phần người ta bỏ qua. Trình phân giải đệ quy tôn trọng TTL của bản ghi, nhưng các chồng giao thức máy khách lưu đệm riêng, và một đường hầm đã dựng không phân giải lại gì cả. Khi gỡ lỗi, đặt bản ghi ở 60-300 giây; điều đó rút ngắn khoảng thời gian phục vụ câu trả lời cũ và không di trú một phiên đang kết nối.

OpenVPN phân giải lại dòng remote vpn.example.net 1194 mỗi lần kết nối lại, và resolv-retry infinite khiến nó tiếp tục thử lại thay vì thoát khi tra cứu thất bại. Trên máy chủ, float cho phép một phiên đã thiết lập đi theo một máy ngang hàng có địa chỉ nguồn đã đổi. WireGuard thẳng thắn hơn: wg-quick up phân giải Endpoint khi cấu hình được áp dụng, và máy khách phân giải lại khi dựng lại đường hầm, nên một lần bắt tay vẫn thành công với địa chỉ cũ tiếp tục thành công cho tới khi dừng.

Sự khác biệt đó định hình kế hoạch. Nếu máy khách kết nối theo nhu cầu, một lần đổi địa chỉ tốn một lần kết nối lại. Nếu chúng giữ phiên mở nhiều ngày, hãy chờ đường hầm chết ở lần bắt tay kế tiếp, và để máy khách thử lại thay vì giả định nó vẫn đứng.

Điều kiện ba: đường vào vẫn mở

DNS động chỉ thay đổi nơi tên trỏ tới và không gì khác. Chuyển tiếp cổng trên router, quy tắc tường lửa trên máy chủ VPN và việc ISP cho phép gói tin vào đều phải tồn tại trước khi bản ghi có ý nghĩa. Hãy xem chuyển tiếp nhắm vào đâu: nếu nó gắn vào địa chỉ WAN thay vì giao diện, một lần đổi địa chỉ sẽ phá chuyển tiếp một cách âm thầm và bản ghi chịu tiếng xấu.

Thử từ bên ngoài. Một điện thoại dùng dữ liệu di động với Wi-Fi tắt là phép thử trung thực rẻ nhất; một laptop trong cùng LAN thì không. Khi tên phân giải tới địa chỉ công cộng của bạn và router không có vòng lặp NAT, phép thử từ bên trong thất bại trong khi bản ghi hoàn toàn đúng, và điều đó khiến phần lớn người ta đi sửa một bản ghi chưa bao giờ sai.

Chạy gì khi cả ba đều đúng

ddclient là trình cập nhật ít gây bất ngờ nhất cho một máy chủ nhỏ. Cấu hình tối thiểu công bố địa chỉ mà nhà cung cấp nhìn thấy, điều này tránh lỗi NAT kép:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Chạy nó từ bộ hẹn giờ systemd vài phút một lần thay vì một vòng lặp shell, và ghi lại phản hồi của nhà cung cấp thay vì giả định thành công. Hãy đối xử với thông tin đăng nhập như một chìa khóa, vì nó quyết định mỗi máy khách được gửi đi đâu: dùng token cập nhật có phạm vi thay vì mật khẩu tài khoản, giữ tệp ở chế độ 0600 và gửi cập nhật qua HTTPS.

Xác minh trước khi cam kết

Một truy vấn cho bạn biết phần còn lại của thế giới nhìn thấy gì, và in ra TTL mà bạn phải chờ sau một thay đổi:

dig +noall +answer vpn.example.net @1.1.1.1

So địa chỉ đó với địa chỉ WAN của router. Nếu khớp, cái tên đang làm việc của nó và thứ vẫn hỏng là khả năng tiếp cận vào, một chìa khóa hoặc một máy khách chưa phân giải lại. Nếu khác, trình cập nhật đang công bố sai giao diện, thường vì nó chạy trên máy chủ VPN phía sau router thay vì trên chính router.

Giữ một cách hoàn tác mất một phút: ghi lại địa chỉ cuối cùng hoạt động và TTL trước đó, để bạn có thể công bố cả hai bằng tay trong lúc nhà cung cấp gặp một buổi chiều tồi tệ.

Khi câu trả lời là không

Nếu điều kiện một hoặc ba không đúng, cái thay đổi là quyết định chứ không phải cấu hình. Sau NAT của nhà mạng, các lựa chọn thực tế là yêu cầu ISP cấp địa chỉ công cộng, chuyển điểm vào sang một VPS nhỏ có địa chỉ ổn định, hoặc dùng một lớp phủ giữ điểm gặp riêng. Nếu địa chỉ là tĩnh, bỏ qua trình cập nhật: một bản ghi A, một bản ghi AAAA nếu bạn dùng IPv6, cùng kiểu chuyển tiếp cổng đó.

Nếu địa chỉ đổi trong khi máy khách vẫn kết nối, cách sửa trung thực nằm ở máy khách: logic kết nối lại và khoảng thử lại, không phải một trình cập nhật nhanh hơn. Thêm nhà cung cấp thứ hai chỉ che khoảng thời gian đó.

Trước khi tiếp tục, xác nhận bốn điều theo thứ tự:

• Địa chỉ mà trình cập nhật công bố khớp với địa chỉ WAN của router.
• TTL của bản ghi đủ ngắn để một thay đổi hiện ra trong vài phút.
• Chuyển tiếp cổng gắn với giao diện, không gắn với địa chỉ cố định.
• Một máy khách thật đã kết nối lại và truyền lưu lượng từ lần thay đổi cuối.

Nếu cả bốn đúng, hãy để nguyên cấu hình; sự cố tiếp theo của bạn là một chìa khóa hoặc một quy tắc tường lửa chứ không phải vấn đề đặt tên. Nếu bất kỳ điều nào sai, sửa dòng đó trước khi thêm một bộ phận chuyển động nữa. RFC 2136 mô tả chính cơ chế cập nhật, nếu bạn muốn xem tiến trình nền đặt gì lên đường truyền.