Tại sao DNS ngừng hoạt động sau khi OpenVPN kết nối trên Windows

Ping tới trình phân giải của văn phòng vẫn được trả lời sau khi "OpenVPN" kết nối, và mọi tìm kiếm tên vẫn thất bại. Địa chỉ truy cập được còn cổng thì không, một sự kết hợp có lý khi biết rằng Windows có thể lọc DNS theo bộ điều hợp. Khi hồ sơ có block-outside-dns, bộ lọc đó là nghi phạm đầu tiên và bảng định tuyến là nơi sai để tìm. Hai thử nghiệm dưới đây tách các lớp trong vài giây.

Địa chỉ tới được, cổng chết

Một ping thành công chứng minh máy chủ đang chạy và có đường đi. Nó không nói gì về quyền tới cổng 53, vì bộ lọc đang bàn làm việc ở lớp khác và phụ thuộc vào bộ điều hợp. Vì thế cùng một máy có thể trả lời ICMP và từ chối mọi truy vấn gửi tới cùng địa chỉ đó. Hãy chạy cả hai thử nghiệm trong cùng một phiên trước khi thay đổi bất kỳ cấu hình nào.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Cặp đôi đó chính là chẩn đoán. Lưu lượng thường tới mạng con vẫn chạy trong khi phân giải tên chết, và người ta kết luận máy chủ hỏng hoặc DNS chưa bao giờ được gửi. Cả hai cách giải thích đều tốn kém để theo đuổi, và bằng chứng chỉ về một chỗ hẹp hơn. Hãy xác nhận cặp đôi trước khi chạm vào một thiết lập.

Tùy chọn này là một quy tắc của nền tảng lọc

Tài liệu OpenVPN mô tả block-outside-dns là một hạn chế của Windows Filtering Platform ngăn ứng dụng tới DNS trên các bộ điều hợp nằm ngoài đường hầm. Nó bao gồm TCP và UDP cổng 53. Vì bộ lọc sống trong WFP chứ không nằm trong danh sách quy tắc tường lửa thông thường, thêm một quy tắc cho phép ở nơi khác không nhất thiết đổi kết quả. Đó là lý do lời khuyên phổ biến là cho phép DNS vẫn thất bại.

Thiết lập có thể đến từ hồ sơ đã nhập hoặc từ máy chủ, và tệp bạn sửa lần cuối "không phải bằng chứng về những gì ứng dụng khách đã tải". Hãy đọc cấu hình hiệu lực và nhật ký kết nối cùng nhau. Tùy chọn này cũng riêng cho Windows, và coi nó là di động sẽ tạo ra lời khuyên không áp dụng được.

Hãy tìm thành phần ứng dụng khách sở hữu hạn chế đó thay vì thêm quy tắc. Chủ sở hữu chính là thứ thực sự gỡ bỏ được nó.

Bộ lọc không phải trình phân giải

Chặn lưu lượng bên ngoài đường hầm không cài đặt một trình phân giải hoạt động bên trong nó. Tùy chọn này gỡ một đường đi và để cấu hình DNS của đường hầm cho người đã lập hồ sơ. Một hồ sơ chưa bao giờ gửi trình phân giải nay không có cái nào.

Hãy làm ba bước kiểm tra theo thứ tự. Thứ nhất, ứng dụng đang thất bại thực sự dùng trình phân giải nào. Thứ hai, ứng dụng khách đã áp dụng thiết lập DNS của VPN chưa. Thứ ba, giao diện nào mang lưu lượng tới trình phân giải đó.

1. Trình phân giải đang dùng: so sánh Resolve-DnsName -Server <resolver-ip> <name> với các máy chủ DNS mà ipconfig /all liệt kê.
2. DNS của VPN đã áp dụng: xem các mục DNS của bộ điều hợp đường hầm trong cùng đầu ra của ipconfig /all.
3. Giao diện đã dùng: Find-NetRoute -RemoteIPAddress <resolver-ip> nêu tên giao diện ra cho đích đó.

Một trình phân giải LAN trở nên không tới được theo thiết kế dưới chính sách này, ngay cả khi lưu lượng LAN khác vẫn chạy. Đó là tùy chọn đang làm đúng việc của nó. Nếu thiết kế cần DNS qua VPN, hãy sửa đăng ký trình phân giải và đường đi của đường hầm; nếu cần split DNS với ngoại lệ cục bộ, chủ sở hữu cấu hình phải diễn đạt các ngoại lệ đó theo cách được hỗ trợ.

Những gì tùy chọn không bao quát

Cổng 53 không phải toàn bộ việc phân giải tên. DNS over HTTPS và DNS over TLS dùng phương thức vận chuyển khác, và một số ứng dụng chạy logic trình phân giải riêng bất kể thiết lập hệ thống. Vì thế trình duyệt có thể phân giải tên trong khi dòng lệnh thì không.

Hãy coi khác biệt đó là chẩn đoán chứ không phải mâu thuẫn. So sánh cả hai trước khi kết luận trình phân giải của hệ thống hỏng.

Giữ kết luận hẹp khi viết ra. Tùy chọn này giới hạn một phương thức vận chuyển trên một nền tảng, và phần còn lại của đường phân giải là một câu hỏi thiết kế riêng có chủ sở hữu của nó.

Kiểm tra trạng thái trước và sau khi ngắt kết nối

Chạy cùng tìm kiếm đó trong lúc kết nối và chạy lại sau khi ứng dụng khách sở hữu ngắt kết nối. Lần đầu phải thất bại với trình phân giải bên ngoài khi đường hầm đang lên, và lần thứ hai phải thành công khi bộ lọc được gỡ. Nếu vẫn thất bại sau khi ngắt kết nối, bộ lọc chưa được dọn.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Khởi động lại dịch vụ ứng dụng khách hoặc máy thường dọn một bộ lọc cũ. Điều đó xác nhận chẩn đoán mà không chứng minh một bản sửa lâu dài. Ghi lại những gì bạn thấy, vì một bộ lọc sống sót qua lần ngắt kết nối sẽ làm lại, và chính bản ghi đó biện minh cho báo cáo lỗi.

Chỉ sau những kiểm tra đó mới hợp lý khi thay trình phân giải hoặc dựng lại chính sách tường lửa. Cả hai đều là thay đổi lớn hơn bằng chứng ủng hộ.