DNS của VPN chiếm mọi truy vấn: sửa dns-priority trong NetworkManager

Kết nối VPN của văn phòng và đột nhiên mọi truy vấn tên đều đi tới resolver của công ty. Các tên công cộng vẫn phân giải được, nên không có gì trông hỏng cho tới khi tên một máy in nội bộ thất bại hoặc một bản ghi split-horizon trả về địa chỉ văn phòng. Ở một số bản cài Fedora thì ngược lại: resolver của nhà cung cấp vẫn tiếp tục trả lời sau khi đường hầm được bật. Cả hai đều là một câu hỏi — resolver nào sở hữu truy vấn này — và trên các hệ thống NetworkManager câu trả lời nằm trong thuộc tính DNS của từng kết nối.

Hai kết nối, một resolver thắng

Mỗi kết nối khai báo một mức ưu tiên DNS. Các kết nối thường mặc định là 50 và kết nối VPN là 0, và giá trị thấp hơn thắng. Chính mức mặc định đó khiến kết nối VPN âm thầm vượt qua kết nối có dây cho mọi tên miền mà nó đòi: số không thắng năm mươi mà không ai chọn.

Mức ưu tiên sắp xếp các ứng viên. Nó không giới hạn việc người thắng được hỏi về điều gì. Một kết nối VPN không có tên miền tìm kiếm sẽ đòi mọi thứ, nên việc ưu tiên nó cũng đẩy các truy vấn công cộng vào đường hầm và, trong thiết kế đường hầm chia tách, tới nơi resolver của công ty chuyển tiếp.

Mức ưu tiên quyết định thứ tự, danh sách tìm kiếm quyết định quyền sở hữu

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Danh sách tìm kiếm là tuyên bố sở hữu. Một tên miền trần như corp.example trở thành hậu tố tìm kiếm và tên miền định tuyến. Dạng chỉ định tuyến ~corp.example gửi các truy vấn dưới hậu tố đó tới kết nối này mà không thêm tên miền vào các tên ngắn. Dấu ngã đó là khác biệt giữa «hỏi máy chủ này» và «hỏi máy chủ này và gõ nốt cho tôi».

Dùng cả hai dạng khi người dùng gõ tên máy chủ ngắn và các bản ghi cũng được đánh địa chỉ bằng tên đủ tiêu chuẩn. Chỉ dùng dạng định tuyến khi bạn muốn chia tách mà không đổi cách resolver hoàn tất một tên trần.

Sau đó làm rõ ưu tiên và kích hoạt lại:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Mức ưu tiên âm là cách được ghi nhận để nói «ưu tiên kết nối này», và đặt cho cả hai họ địa chỉ giữ cho hành vi nhất quán trên máy có kết nối IPv6. Thay đổi thuộc tính mà không kích hoạt lại kết nối thì không thay đổi gì đang chạy, vì thế chuỗi kết thúc bằng một lệnh up rõ ràng.

Để systemd-resolved giữ việc chia tách

Plugin dnsmasq mặc định dồn các truy vấn vào một resolver cục bộ, nên việc tách theo từng liên kết vẫn thô. systemd-resolved phơi bày việc chia tách theo từng liên kết, và resolvectl query nêu tên liên kết đã trả lời.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Sau đó liên kết của công ty mang corp.example và một resolver công cộng phục vụ phần còn lại. Khi một truy vấn tới nhầm liên kết, lệnh nêu tên liên kết đã trả lời nó, và biết điều đó tốt hơn chỉ biết địa chỉ.

Khớp thiết kế DNS với loại đường hầm

Các thiết kế riêng tư gửi mọi thứ qua đường hầm không nên mang danh sách chia tách, vì nó sẽ trả các tên công cộng về resolver cục bộ và vô hiệu hóa ý định. Các thiết kế đường hầm chia tách thì cần: không có nó, resolver của công ty thấy mọi truy vấn công cộng, và cấu hình hỏng ngay khi đường hầm sụp.

Tiếp đó là kill switch chặn DNS bên ngoài đường hầm. Các tên được phân giải cho vùng của đường hầm và thất bại ở mọi nơi khác trong khi kết nối hoàn toàn khỏe mạnh. Các câu trả lời khả thi là cho phép rõ ràng với resolver của LAN hoặc một bộ nhớ đệm cục bộ chỉ chuyển tiếp vùng của công ty, và cả hai đều là ngoại lệ có người sở hữu chứ không phải khiếm khuyết trong đường hầm.

Một hồ sơ ghi lại cấu hình resolver khi giao diện khởi động cũng hành xử gần như vậy: khi resolver cục bộ không thể truy cập, chỉ những tên mà đường hầm biết mới phân giải được. Dù cơ chế nào được áp dụng, hãy ghi lại tên nào phải hoạt động trong từng trạng thái, và đưa danh sách đó cho người xử lý các báo cáo.

Kiểm tra theo từng liên kết, rồi kiểm tra lại sau khi kết nối lại

Hỏi một tên nội bộ và một tên công cộng, và xem truy vấn thực sự đi đâu. Một trang kiểm tra rò rỉ cho bạn biết resolver nào đã trả lời, không phải liên kết nào hệ thống đã chọn, nên nó không nói gì về thứ tự bạn vừa cấu hình.

Chạy lại hai truy vấn sau khi ngắt và kết nối lại. Các mức ưu tiên được áp dụng lại khi một kết nối được kích hoạt, và một liên kết tượng trưng cũ có thể sống sót qua một lần nâng cấp mà không ai nhớ. Điều bạn muốn ghi lại cuối cùng là resolver nào sở hữu hậu tố nào, kèm một phép kiểm tra vẫn đúng vào ngày mai.