Vì sao mục /etc/hosts của bạn không đến được DNS của VPN

Bạn đã thêm một tên vào /etc/hosts, kết nối VPN và mong đợi bản ghi sẽ hiện ra với mọi người. Điều đó không xảy ra, và bất ngờ thường đi kèm triệu chứng thứ hai: tên phân giải được trên máy bạn và thất bại trên máy đồng nghiệp, trông như dịch vụ DNS của VPN bị hỏng và thực ra là tệp hosts đang làm đúng việc nó được thiết kế để làm. Tệp hosts là cấu hình phân giải tên cục bộ, không phải cập nhật vùng, và không có gì trong một kết nối VPN bình thường tải nó lên.

Hosts là ghi đè cục bộ, không phải cập nhật vùng

Tệp là danh sách ánh xạ mà các thư viện dịch vụ tên tham chiếu trước khi, hoặc thay vì, hỏi một máy chủ DNS. Một dòng như 10.40.0.20 build.corp.example thay đổi điều mà ứng dụng trên đúng một máy đó kết luận. Nó không tạo bản ghi, không đi qua đường hầm, và máy chủ DNS mà đường hầm trỏ tới không hề biết nó tồn tại.

Vì thế lỗi là bất đối xứng. Máy khách của bạn nhận câu trả lời từ tệp. Máy khách khác hỏi máy chủ DNS của VPN, máy chủ này không trả về gì, và ứng dụng báo rằng tên không tồn tại. Cả hai máy đều hành xử đúng; chỉ một máy có ghi đè mà máy kia chưa bao giờ thấy.

Hai lệnh, hai thành phần khác nhau

Cách nhanh nhất để chấm dứt tranh cãi là làm cho khác biệt hiện rõ trong hai lệnh, cả hai chạy trên máy khách có mục hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Lệnh thứ nhất hỏi đường dẫn tra cứu của chính hệ thống, trên một hệ glibc điển hình đường này đọc tệp cục bộ trước DNS. Lệnh thứ hai gửi truy vấn DNS trực tiếp đến máy chủ tại địa chỉ đó và hoàn toàn không xem tệp cục bộ. Khi lệnh thứ nhất trả về mục của bạn và lệnh thứ hai trả về NXDOMAIN, bạn đã chứng minh bản ghi không tồn tại trong DNS và máy bạn đang trả lời từ một ghi đè cục bộ.

Thứ tự có thể cấu hình, và đáng để kiểm tra trước khi kết luận bất cứ điều gì về một bản phân phối cụ thể. Hãy xem dòng hosts: trong /etc/nsswitch.conf; hosts: files dns xem tệp trước. Đừng sao chép ví dụ đó lên một cấu hình đang hoạt động chỉ để đổi thứ tự, vì hệ thống thực thường liệt kê thêm nguồn và mục dịch vụ có điều kiện mà ví dụ không có.

systemd-resolved làm mờ bài kiểm tra

Trên một hệ dùng systemd-resolved, stub cục bộ cũng phục vụ tên từ cơ sở dữ liệu hosts. Vì thế truy vấn 127.0.0.53 không phải bài kiểm tra độc lập đối với máy chủ từ xa, dù nó trông như truy vấn DNS và hành xử như vậy. Bạn có thể xác nhận trình phân giải biết gì và sẽ hỏi những máy chủ nào bằng:

resolvectl query build.corp.example
resolvectl status

Đầu ra status nêu tên các máy chủ DNS theo từng liên kết, và đó là cách bạn biết liên kết VPN có nhận được trình phân giải hay không. Câu hỏi đó tách khỏi mục hosts và là câu đáng hỏi khi một tên riêng thất bại với mọi người dùng chứ không phải một người.

Ứng dụng có thể thêm một lớp nữa. Trình duyệt có thiết lập DNS-over-HTTPS riêng, vùng chứa có cấu hình trình phân giải riêng, hoặc môi trường chạy lưu đệm tra cứu trong suốt vòng đời tiến trình đều có thể trả lời khác hệ thống. Hãy kiểm tra ứng dụng mà bạn quan tâm thay vì cho rằng một lệnh mô tả mọi chương trình trên máy.

Điều gì thực sự chia sẻ một tên qua VPN

Nếu một tên riêng phải hoạt động với mọi người, nó cần một chủ sở hữu mà trình phân giải của mọi người có thể đến được. Câu trả lời sạch sẽ là công bố bản ghi trong một vùng được quản lý và làm cho vùng đó phân giải được qua đường DNS dự định của VPN. Khi đó bản ghi có một nguồn sự thật duy nhất, một dấu vết kiểm toán và một vòng đời, và không ai phải nhớ máy tính xách tay nào mang ghi đè cục bộ.

Phân phối tệp hosts là một lựa chọn thay thế hợp lệ, và đó là quản lý điểm cuối chứ không phải dịch vụ tên. Nếu bạn chọn nó, tệp phải được triển khai, đánh phiên bản và gỡ bỏ bởi thứ quản lý đội máy, và phải được mô tả như vậy trong thiết kế. «VPN lo việc đó» không phải mô tả của quá trình đó.

Đăng ký DNS động là cơ chế thứ ba, với quyền, xác thực cập nhật và thời hạn bản ghi riêng. Nó không xuất phát từ một mục hosts, và cũng không xuất phát từ việc máy khách chỉ kết nối, trừ khi cả máy chủ và máy khách đều được cấu hình để làm vậy. Một bản ghi tự xuất hiện là dấu hiệu ai đó đã bật cập nhật an toàn và một máy khách tự đăng ký, và cấu hình đó thuộc hồ sơ thiết kế chứ không thuộc một luồng xử lý sự cố. Nếu không ai nói được ai sở hữu thiết lập đó, hãy coi bản ghi tự động là chưa được xác minh và giữ vùng được quản lý làm nguồn sự thật.

Một tên đã phân giải không phải là tuyến đường

Phân giải tên và khả năng tiếp cận là hai việc khác nhau, và ánh xạ cục bộ cũ là cách kinh điển để nhầm lẫn chúng. Một mục hosts trỏ tới địa chỉ đã chuyển đi sẽ tiếp tục chọn máy chủ cũ rất lâu sau khi DNS được sửa, và triệu chứng trông như lỗi định tuyến trên một tên phân giải tốt.

Vì thế khi báo cáo là «tên phân giải được nhưng dịch vụ không tiếp cận được», hãy so sánh tra cứu hệ thống với một truy vấn rõ ràng đến máy chủ DNS của VPN, rồi kiểm tra địa chỉ bạn nhận được với địa chỉ mà dịch vụ thực sự dùng. Tài liệu tham chiếu systemd-resolved ghi lại các nguồn cục bộ mà nó tham chiếu, và đó là bản đồ bạn cần cho việc so sánh đó.

Sau đó sửa ghi đè thông qua chủ sở hữu của nó. Xóa một dòng khỏi tệp hosts của chính bạn không làm gì cho mười hai máy tính xách tay đã nhận cùng dòng đó từ một tập lệnh triển khai, và đó là phiên bản của vấn đề này mà người ta thực sự gặp.