ddclient công bố lối ra VPN: sửa nguồn phát hiện

Tên DNS của bạn giờ phân giải thành địa chỉ của nhà cung cấp VPN, và nhật ký cập nhật trông hoàn toàn khỏe mạnh. Sự kết hợp đó là bình thường. Một đầu dò phát hiện dựa trên web hỏi dịch vụ bên ngoài xem nó thấy nguồn nào, và khi yêu cầu đi ra qua VPN đường hầm đầy đủ, câu trả lời là lối ra VPN chứ không phải địa chỉ WAN tại nhà của bạn. Trình cập nhật đã làm việc của nó; công việc đã bị hướng vào quan sát sai.

Xác nhận tên phải tiếp cận điều gì

Một tên công khai cho dịch vụ tại nhà hướng vào cần một địa chỉ mà qua đó các kết nối đến đã được phê duyệt có thể tiếp cận dịch vụ đó. Công bố một lối ra dùng chung của nhà cung cấp không thiết lập chuyển tiếp vào tại đó, và không cấu hình DNS nào tạo ra chuyển tiếp đó. Hãy quyết định điều này trước khi chạm vào trình cập nhật, vì nó xác định địa chỉ nào là đúng.

Một tên riêng cho địa chỉ đường hầm của máy khách VPN là vấn đề khác với câu trả lời khác: nó thuộc DNS riêng, và hoàn toàn không cần dịch vụ phát hiện công khai. Trộn hai yêu cầu với nhau chính là cách một cấu hình đang chạy bắt đầu công bố địa chỉ mà không ai yêu cầu.

Địa chỉ giao diện cũng cần được diễn giải. Địa chỉ máy tính xách tay sau bộ định tuyến tại nhà không phải địa chỉ WAN công khai, và ngay cả địa chỉ WAN của bộ định tuyến cũng có thể nằm sau NAT cấp nhà mạng, nơi công bố nó không thể tạo ra khả năng tiếp cận vào.

Tái tạo giá trị trước khi thay đổi bất cứ điều gì

Quan sát hai đường đi riêng biệt. Khi đường hầm bật, đầu dò báo lối ra; khi đường hầm tắt, hoặc khi đầu dò được gắn vào giao diện vật lý, nó báo địa chỉ tại nhà: curl --interface eth0 https://ifconfig.me. Nếu hai câu trả lời đó khác nhau, bạn đã tái tạo lỗi mà không chạm vào trình cập nhật.

Sau đó chạy máy khách ở chế độ kiểm tra cấu hình mà không thực hiện cập nhật, ví dụ ddclient -verbose -noexec, và đọc xem nó chọn phương pháp phát hiện nào. Đầu ra chi tiết nêu tên phương pháp và giá trị nhận được, và đó là dữ kiện bạn cần trước khi sửa bất cứ điều gì.

Hướng phát hiện vào đường đi đã chọn

Nếu tên phải công bố địa chỉ WAN tại nhà, phát hiện phải quan sát đúng địa chỉ đó. Ba lựa chọn hoạt động, theo thứ tự ưu tiên gần đúng: để bộ định tuyến công bố qua trình cập nhật được hỗ trợ của chính nó; dùng phát hiện trạng thái bộ định tuyến của ddclient đối với một trang mà bộ định tuyến thực sự phục vụ; hoặc giữ đầu dò web nhưng gắn nó vào giao diện vật lý để nó đi ra ngoài đường hầm.

Với đường trạng thái bộ định tuyến, các bản phát hành ddclient mới hơn dùng họ tùy chọn usev4 và fwv4, với mẫu bỏ qua tùy chọn cho văn bản xung quanh trang. Kiểm tra README cho phiên bản đã cài, vì các bản cũ viết cùng ý tưởng bằng use và fw, và tên tùy chọn sao chép từ bản sai sẽ thất bại khi khởi động.

Nếu bạn giữ phát hiện web, hãy nhớ rằng định tuyến đầu dò và định tuyến lệnh gọi API cập nhật là hai quyết định riêng. Lệnh gọi cập nhật phân phối bản ghi; đầu dò quyết định giá trị sẽ được phân phối.

Giữ bí mật và phiên bản gọn gàng

Thông tin đăng nhập của bộ định tuyến và token của nhà cung cấp thuộc về một tệp cấu hình được bảo vệ, không phải trên dòng lệnh để rồi vào lịch sử shell. Dấu vết chi tiết có thể chứa cả hai, nên hãy che chúng trước khi dán vào phiếu. Một phương pháp phát hiện đòi hỏi phải cào một trang bộ định tuyến đã xác thực cũng đòi hỏi bạn giữ thông tin đăng nhập đó hoạt động qua các lần cập nhật firmware. Lưu giữ chúng cẩn thận như token của nhà cung cấp.

ddclient README ghi lại các cách tiếp cận phát hiện và tên tùy chọn của chúng. Đừng trộn kết quả IPv4 và IPv6 trong một bản ghi, và đừng cho rằng một tùy chọn có trong bản này thì có trong bản khác.

Xác minh giá trị, rồi đến khả năng tiếp cận

So sánh địa chỉ được đề xuất với điểm cuối dự định trước khi cho phép cập nhật trực tiếp, sau đó kiểm tra DNS có thẩm quyền sau một lần cập nhật được ủy quyền và tính đến bộ nhớ đệm của trình phân giải. TTL thấp rút ngắn thời gian chờ; nó không làm cho một giá trị sai trở nên đúng.

Chỉ khi bản ghi đúng, bạn mới nên kiểm tra dịch vụ hướng vào từ một mạng độc lập, với tường lửa và chuyển tiếp cần thiết đã được phê duyệt. Một bản ghi A đúng không chứng minh dịch vụ tiếp cận được, và thuê VPN tĩnh có thể đơn giản hóa việc đặt tên riêng mà không sửa được tên máy chủ công khai trỏ tới WAN sai.