DNS do OpenVPN đẩy bị bỏ qua: thành phần nào áp dụng nó

Nhật ký cho thấy tùy chọn mà máy chủ đẩy xuống, đường hầm đang hoạt động, và các tên nội bộ vẫn thất bại. Một truy vấn trực tiếp tới bộ phân giải có trả lời, vậy máy chủ vẫn ổn, nhưng mọi ứng dụng vẫn hỏi bộ định tuyến cục bộ. Thứ đến được máy khách là một đề nghị, không phải thay đổi trong bộ phân giải, và thành phần sở hữu việc phân giải tên khác nhau trên Linux, Windows và macOS. Khi tách tùy chọn khỏi chủ sở hữu của nó, bốn lỗi bao trùm gần như mọi báo cáo: không có hook, hai hook cạnh tranh, DNS chia tách chạy đúng thiết kế, hoặc một tên ngắn cần hậu tố chứ không cần máy chủ.

Tùy chọn được đẩy là đề nghị, không phải cài đặt

Trên máy chủ, hai chỉ thị mô tả ý định chứ không phải tác động:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Máy khách không nhận được bộ phân giải đã cấu hình. Nó nhận các biến môi trường, foreign_option_1 và những biến tiếp theo, mỗi dòng được đẩy một biến, và một thứ cục bộ phải đọc chúng rồi ghi lại trạng thái bộ phân giải của hệ điều hành. Trên Linux không có gì làm việc đó theo mặc định, vì thế một máy chủ đúng và một máy khách đã kết nối vẫn có thể phân giải tên qua LAN.

Giữa hai đầu có ba giai đoạn: thao tác đẩy phải tới được, máy khách phải phơi ra nó, và một hook phải áp dụng nó. Đọc giai đoạn giữa trong nhật ký máy khách và giai đoạn cuối trong trạng thái bộ phân giải, không bao giờ ngược lại, vì một dòng nhật ký chỉ chứng minh hai giai đoạn đầu.

Xác nhận thao tác đẩy đã tới và tìm chủ sở hữu

Bắt đầu bằng việc gọi tên trình khởi chạy: một lệnh openvpn trần, một phiên systemd, NetworkManager hoặc máy khách của nhà cung cấp. Điều đó quyết định hook có thể sống ở đâu. Trên máy chủ có systemd-resolved, resolvectl status liệt kê từng liên kết cùng các máy chủ DNS và miền tìm kiếm mà nó thực sự dùng, và liên kết đường hầm không phải lúc nào cũng tên là tun0.

Nếu địa chỉ được đẩy xuất hiện trong nhật ký nhưng không có trên liên kết nào, phần tích hợp bị thiếu. Nếu nó có trên liên kết mà truy vấn vẫn thoát ra chỗ khác, vấn đề là truy vấn nào chọn liên kết đó. NetworkManager dns=dnsmasq trong tệp /etc/NetworkManager/NetworkManager.conf chạy một bộ chuyển tiếp cục bộ chủ động áp dụng DNS chia tách: các tên trong miền VPN đi tới bộ phân giải VPN, mọi thứ khác giữ đường cũ. Hành vi này trông như lỗi khi bạn chờ toàn bộ lưu lượng chuyển đi; hãy kiểm tra cài đặt theo từng kết nối với nmcli connection show "My VPN", tại đó ipv4.dns và ipv4.dns-search giữ các giá trị đằng sau những gì thiết bị báo cáo, trước khi gọi nó là hỏng. Nếu mọi truy vấn thực sự phải tới bộ phân giải VPN, hãy bỏ dns=dnsmasq khỏi NetworkManager.conf và khởi động lại NetworkManager, việc này trả việc phân giải tên về cài đặt kết nối; nếu không, hãy giữ DNS chia tách và sửa danh sách miền được đẩy.

Linux: trao các tùy chọn cho bộ phân giải

Các gói của bản phân phối cung cấp một hook cho việc này, và máy khách phải được phép chạy nó. Một cách bố trí điển hình trên máy chủ không có systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Với systemd-resolved, tập lệnh resolv.conf cũ có thể không thay đổi gì quan trọng, vì bộ phân giải stub giữ trạng thái theo từng liên kết. update-systemd-resolved trình trợ giúp ghi lại một dạng hook dùng up-restart và down-pre, điều này quan trọng khi một giao diện sống lâu hơn một lần thử kết nối. Dù bạn chọn gì, một thành phần phải sở hữu trạng thái. Thêm một hook không liên quan bên cạnh NetworkManager cho hai người ghi cùng một liên kết, và kết quả khi đó phụ thuộc vào thứ tự chứ không phụ thuộc cấu hình của bạn.

Cũng có trường hợp NetworkManager phớt lờ hoàn toàn tùy chọn được đẩy cho tới khi địa chỉ máy chủ được nhập vào cài đặt IPv4 của kết nối, sau đó trạng thái bộ phân giải cho thấy nó đang được dùng. Đáng thử trước khi viết lại các tập lệnh, vì nó chuyển vấn đề từ hook shell sang hồ sơ kết nối vốn đã mang đường hầm.

Windows và macOS áp dụng những phần khác nhau

Máy khách Windows thực sự đặt máy chủ DNS của bộ điều hợp VPN, nhưng Windows vẫn chọn giao diện theo chỉ số và vẫn cần hậu tố để mở rộng một tên ngắn. Xác nhận trạng thái bộ điều hợp chứ không phải hồ sơ:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Nếu thiếu địa chỉ, hãy đặt nó bằng Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, rồi thêm hậu tố vào thuộc tính IPv4 của bộ điều hợp để fileserver trở thành fileserver.corp.example. Một giá trị SearchList toàn máy dưới Tcpip\Parameters làm điều tương tự. Nơi tên dài phân giải được còn tên trần thì không, bộ phân giải đã đúng và danh sách tìm kiếm là thủ phạm. Các cách sửa, theo thứ tự: đẩy một DOMAIN để máy khách học hậu tố, thêm hậu tố đó vào danh sách tìm kiếm của bộ điều hợp hoặc kết nối, và như biện pháp tạm thời ghim tên vào hosts, hoặc LMHOSTS trên Windows; duyệt NetBIOS không vượt qua bộ định tuyến, nên quảng bá tìm ra tên ngắn trên LAN văn phòng không bao giờ tới được máy khách đường hầm.

block-outside-dns block-outside-dns là hành vi của máy khách Windows, không phải dòng hồ sơ di động, và sao chép nó vào hồ sơ Linux hay macOS không tái tạo nó ở đó. Nếu tên công cộng hoạt động còn tên nội bộ thất bại trên Windows, hãy so sánh thứ tự bộ điều hợp trong Cài đặt nâng cao với ipconfig /all. Trên macOS, thứ tự bộ phân giải theo dịch vụ thuộc về hệ thống, nên hãy dùng scutil --dns để xem bộ phân giải nào được hỏi cho miền nào, và coi mọi bản sửa hồ sơ đơn lẻ được báo cáo là phụ thuộc máy khách chứ không phổ quát.

Máy ảo trên cùng laptop không thừa hưởng gì từ đây. Hãy cấp cho khách một mục bộ phân giải riêng cho miền nội bộ, hoặc để NAT của trình ảo hóa chuyển tiếp truy vấn của nó qua máy chủ, điều chỉ đúng khi đường hầm của máy chủ đang hoạt động.

Lịch sử là nguyên nhân thứ ba. Máy chủ DNS hoặc cài đặt hậu tố từ hồ sơ trước có thể sống qua các lần kết nối lại, vì thế khi bộ điều hợp trông đúng mà tìm kiếm vẫn thất bại, hãy so sánh bộ điều hợp đang sống với Get-VpnConnection và xóa hoặc ghi đè mục cũ trước khi chạm vào máy chủ.

Chứng minh truy vấn đã đi đâu

Một bản chụp trong lúc tìm kiếm chấm dứt tranh luận: tcpdump -ni eth0 port 53 cho thấy truy vấn trên giao diện vật lý, nghĩa là chúng ra ngoài đường hầm và bộ phân giải chưa hề bị đổi. dig @10.8.0.1 name.corp.example sau đó tách hai trường hợp còn lại. Nếu truy vấn trực tiếp trả lời, bộ phân giải hoạt động và máy khách không dùng nó; nếu hết thời gian, bộ phân giải không thể tới qua đường hầm và không thay đổi cục bộ nào giúp được.

Nếu bộ phân giải vẫn đang dùng là cái do nhà cung cấp phát, đường hầm mã hóa lưu lượng nhưng tên vẫn hiển thị với nhà cung cấp đó. Đó là câu hỏi rò rỉ chứ không phải chức năng, và cùng bản chụp trả lời: một truy vấn trên giao diện vật lý đang đi tới ai đó ngoài đường hầm.

Khả năng tiếp cận bao gồm tường lửa trên máy chủ VPN, nơi phải cho phép UDP và TCP 53 từ nhóm. Cổng bị chặn trông đúng như một thao tác đẩy hỏng, và một bộ phân giải chỉ trả lời từ bên trong mạng đường hầm cũng vậy. Lặp lại bản chụp sau một lần ngắt và kết nối lại, vì cài đặt xuất hiện ở lần kết nối đầu và biến mất ở lần thứ hai là lỗi vòng đời trong hook, không phải tùy chọn thiếu.

Giữ một chủ sở hữu và xác minh theo thứ tự

Một tập lệnh ghi lại DNS của bộ điều hợp dựa trên trạng thái đường hầm phỏng đoán sẽ nhân đôi cấu hình mà hồ sơ vốn đã mang, và nó âm thầm thất bại lần đầu khi phỏng đoán sai. Hãy ưu tiên cài đặt DNS của chính kết nối hoặc một hook được ghi lại, và ghi lại bạn chọn cái nào để người sau không thêm cái thứ hai.

Khép vòng bằng bốn kiểm tra: địa chỉ được đẩy có trên liên kết đường hầm, tên nội bộ phân giải được như tên đầy đủ, cùng tên đó phân giải được khi không có hậu tố, và cả hai vẫn đúng sau một lần kết nối lại. Một bản chụp cho bạn biết cái nào trong bốn cái đã thất bại. Sổ tay OpenVPN 2.6 liệt kê dhcp-option và các chỉ thị tập lệnh cùng ghi chú nền tảng của chúng.