openfortivpn liên tục ghi đè DNS? Tìm chủ sở hữu thực sự

Theo dõi kết nối từ thời điểm nó khởi lên: máy khách xác thực, pppd thương lượng, rồi sau đó một thứ gì đó ghi cài đặt DNS vào hệ điều hành. Nếu bạn chỉ biết rằng VPN đã thay đổi bộ phân giải của mình, bạn vẫn chưa biết giai đoạn nào trong số đó đã làm điều này. Hai trong số chúng có thể, và trên một máy khách dùng tích hợp pppd được tài liệu hóa, chúng chạy đủ gần nhau để trông như một tác nhân duy nhất. Gọi tên trình ghi là bước thứ nhất; chọn thứ thay thế nó là bước thứ hai, và đó là một quyết định riêng với các kiểu hỏng của riêng nó.

Trình tự dưới đây theo dõi máy khách hướng ra ngoài: kết nối đã thay đổi điều gì, công tắc nào làm im lặng trình ghi nào, ai nên tiếp nhận và làm sao xác nhận rằng kết quả sống sót qua lần kết nối lại. Mỗi giai đoạn để lại một dấu vết khác nhau, và chính dấu vết cho bạn biết quá trình bàn giao có thực sự diễn ra hay không.

Bắt đầu từ điều kết nối thực sự đã thay đổi

Kết nối một lần bằng lệnh thường dùng của bạn và so sánh phân giải trước và sau. Trên một máy chủ Linux chạy systemd-resolved, resolvectl status in ra các máy chủ DNS và miền tìm kiếm cho từng liên kết, và một liên kết tun hoặc ppp mới mang máy chủ riêng của nó là dấu vân tay của một bản cập nhật từ phía máy khách. Trên macOS, scutil --dns hiển thị cấu hình bộ phân giải theo thứ tự mà ứng dụng tham vấn nó.

So sánh điều đó với tệp mà bạn mong sẽ thay đổi. Một mục gắn với kết nối trong chế độ xem theo từng liên kết và một /etc/resolv.conf bị ghi lại là hai kết quả khác nhau, và kết quả thứ hai có thể là một liên kết tượng trưng do một thứ hoàn toàn khác quản lý. Ghi lại địa chỉ bộ phân giải, các miền tìm kiếm và tên giao diện trong cùng một thời điểm; một thay đổi ở bất kỳ mục nào trong số đó chỉ ra một trình ghi khác. Không có đường cơ sở đó, mọi bản sửa sau này chỉ là phỏng đoán xem thành phần nào trong ba thành phần đã dịch chuyển.

Hai công tắc và trình ghi mà mỗi cái làm im lặng

openfortivpn tài liệu hóa một đoạn tùy chọn tắt cả hai trình ghi mà nó có thể điều khiển, và mỗi công tắc có một dạng tương đương được viết đầy đủ mà sách hướng dẫn coi là cùng một thiết lập.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ngăn máy khách áp dụng các máy chủ DNS mà nó đã học từ cổng, trong khi --pppd-no-peerdns ngăn pppd đẩy DNS của đối tác vào hệ thống. Sách hướng dẫn của upstream cảnh báo rằng các bản cập nhật DNS qua PPP có thể chạy đua với các bản cập nhật DNS của chính máy khách, vì thế cả hai công tắc đều thuộc về đoạn đó thay vì coi một trong hai là đủ.

Không công tắc nào nêu tên một bộ phân giải thay thế, và không cái nào ngăn một trình quản lý mạng, một máy khách DHCP hay một tích hợp VPN riêng ghi phân giải sau đó. Làm im lặng hai trình ghi để lại khoảng trống mở chứ không phải được sở hữu. Nếu một thành phần thứ ba đã quản lý DNS, đoạn đó không thay đổi gì bạn có thể quan sát; nếu không gì quản lý nó, bạn vừa gỡ bỏ nguồn duy nhất của phân giải tên riêng tư. Đó là một cách sắp xếp hợp lệ chỉ khi chủ sở hữu thay thế được chọn trước và thử nghiệm riêng.

Chọn chủ sở hữu trước khi bạn vô hiệu hóa bất cứ thứ gì

Trước tiên hãy quyết định ai trả lời các truy vấn cho tên công việc, vì lựa chọn đó ràng buộc mọi thứ về sau. Giữ bộ phân giải hiện có nghĩa là vùng riêng tư đã phải tiếp cận được từ bất cứ nơi nào máy khách ngồi, và một bộ phân giải riêng trong văn phòng cần một tuyến đường sống sót khi đường hầm khởi lên. Gửi mọi truy vấn đến một dịch vụ nội bộ duy nhất là chính sách thứ ba với kiểu hỏng sắc hơn: khi dịch vụ đó không tiếp cận được, tên công khai thất bại cùng với tên riêng tư.

Quyền sở hữu tuyến đường được tách riêng có chủ đích. Các tùy chọn tuyến đường không bắt buộc chỉ vì bạn đã đổi DNS, và việc tắt cài đặt tuyến đường mà không cài một thứ thay thế có thể làm bộ phân giải bạn vừa chọn trở nên không tiếp cận được. Hãy kiểm tra bảng định tuyến cụ thể cho địa chỉ bộ phân giải, không chỉ cho mạng con ứng dụng mà bạn tình cờ thử.

Kiểm tra phân giải theo từng liên kết, không phải theo tệp

Một /etc/resolv.conf duy nhất không phải là bản kiểm kê những gì ứng dụng thực sự dùng trên một máy chủ có phân giải giới hạn phạm vi hoặc theo miền, nên hãy đọc trạng thái bộ phân giải theo cách nền tảng phơi bày nó.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Hỏi một tên riêng tư và một tên công khai sau khi kết nối khởi lên, và ghi lại liên kết nào đã trả lời mỗi tên. Ở nơi liên kết VPN mang một danh sách tìm kiếm theo miền, một tên riêng tư có thể phân giải đúng trong khi một tên công khai vẫn đi đến bộ phân giải cục bộ, và sự tách biệt đó là thiết kế đang hoạt động chứ không phải lỗi. Nếu truy vấn riêng tư thất bại, hãy kiểm tra tuyến đường đến bộ phân giải trước khi chạm lại vào DNS; nếu nó thành công trong khi một ứng dụng vẫn thất bại, ứng dụng có thể đang đọc bộ phân giải riêng đã lưu đệm hoặc được cấu hình riêng.

Kết nối lại và xác nhận trạng thái ngắt kết nối

Hạ kết nối xuống và lặp lại cả hai truy vấn. Những gì chủ sở hữu đã chọn cài đặt nên được chính chủ đó gỡ bỏ hoặc khôi phục, không phải bị máy khách mà bạn đã làm im lặng bỏ lại. Một mục theo từng liên kết đã cũ và sống lâu hơn đường hầm vẫn tiếp tục gửi truy vấn riêng tư đến một địa chỉ không còn tiếp cận được.

Sau đó kết nối lại và đọc lại đúng ba giá trị đó: địa chỉ bộ phân giải, các miền tìm kiếm, giao diện.

Nếu chúng khớp với chính sách bạn đã ghi lại, quá trình bàn giao hoàn tất và máy khách VPN không còn là một trong các trình ghi. Nếu một giá trị trôi ngược lại vài giây sau khi liên kết khởi lên, thứ gì đó khác vẫn đang áp dụng cấu hình, và bước tiếp theo là nhận diện thành phần đó thay vì thêm một cờ nữa. Trạng thái cuối cùng bạn muốn là không có sự kiện nào: một chủ sở hữu, một chính sách được tài liệu hóa và một máy chủ đã ngắt kết nối phân giải chính xác như trước khi đường hầm tồn tại.