Chặn hai dịch vụ Linux tranh nhau /etc/resolv.conf

DNS cứ quay lại trạng thái cũ, việc kết nối lại VPN hủy bỏ bản sửa của bạn, và cuối cùng ai đó trong nhóm đề xuất khóa tệp. Chuỗi đó là triệu chứng, không phải giải pháp: hai thành phần đều tin rằng mình sở hữu /etc/resolv.conf, và bên ghi sau cùng sẽ thắng. Khóa tệp không giải quyết xung đột sở hữu, nó chỉ che giấu và đồng thời phá hỏng thành phần mà bạn thực sự muốn. Hãy thực hiện bốn kiểm tra dưới đây theo thứ tự và sửa cách bố trí ở cấp sở hữu nó, không phải ở tệp.

Kiểm tra 1: đó có phải liên kết tượng trưng, và trỏ tới đâu

Bắt đầu từ chính tệp, vì đường dẫn bạn đang sửa có thể không phải là tệp. Một liên kết tượng trưng vào thư mục thời gian chạy của bộ phân giải hoạt động hoàn toàn khác với một tệp thường bị script máy khách ghi đè:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Liên kết tới đường dẫn stub của systemd-resolved nghĩa là nội dung tệp được tạo ra, và việc sửa tay sẽ bị ghi đè ở sự kiện tiếp theo. Một tệp thường có các dòng nameserver thường do máy khách hoặc hook DHCP chạy khi kết nối ghi. Cả hai đều hợp lệ; điều quan trọng là biết mình có loại nào trước khi thay đổi bất cứ điều gì.

Kiểm tra 2: daemon nào đang chạy

Tìm hiểu cái gì thực sự đang hoạt động, không phải cái gì đã được cài đặt. Trên một bản phân phối hiện đại có thể có nhiều bộ phân giải, và cái giữ cổng 53 trên giao diện loopback là cái trả lời:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Kết quả trạng thái nêu tên các máy chủ DNS theo từng liên kết và các miền định tuyến, đó là bản đồ bạn cần cho split DNS. Nếu tên nội bộ phải đi tới máy chủ nội bộ và mọi thứ khác tới máy chủ công cộng, chính sách đó sống trong các miền theo liên kết, và việc san phẳng nó thành danh sách nameserver tĩnh trong tệp sẽ âm thầm đánh mất sự phân biệt đó.

Cấu hình của chính NetworkManager quyết định dùng backend nào trong số này. Thiết lập dns= trong tệp cấu hình chính chọn giữa bộ phân giải nội bộ của nó, dnsmasq, systemd-resolved và none, và bản phân phối có thể đã chọn thay bạn. Hãy đọc thiết lập đó trước khi quyết định “sửa DNS” nghĩa là gì trên máy này.

Kiểm tra 3: máy khách VPN được phép ghi gì

Xung đột thường sống ở đây. Một máy khách VPN ghi đè trực tiếp tệp bộ phân giải sẽ đấu với mọi dịch vụ cũng duy trì nó, và bên thua là bên chạy trước. Các bản phát hành OpenVPN gần đây có thể giao cài đặt DNS cho systemd-resolved thay vì ghi đè tệp, đó là hành vi hợp tác mà bạn muốn; các script cũ và hook viết tay thường gọi một công cụ trợ giúp lỗi thời hoặc chỉ đơn giản ghi đè tệp.

Tình huống của WireGuard tương tự về hình thức: bản thân cấu hình giao diện không quản lý DNS, các công cụ xung quanh làm việc đó, thông qua trình trợ giúp bộ phân giải hoặc tích hợp resolved. Nếu hai trình trợ giúp như vậy được cài đặt, cả hai sẽ cố áp đặt thế giới quan của mình khi kết nối.

Hãy đọc các hook up và down của máy khách thay vì đoán. Vài dòng shell trong /etc/openvpn/up.sh hoặc thư mục tương đương giải thích hành vi mà nếu không sẽ có vẻ ngẫu nhiên, và đó cũng là nơi bạn có thể khiến máy khách hợp tác thay vì cạnh tranh.

Kiểm tra 4: sửa ở chủ sở hữu, không phải ở tệp

Khi biết chủ sở hữu, hãy cấu hình DNS qua giao diện mà chủ sở hữu đó hỗ trợ. Với systemd-resolved, điều đó có nghĩa là thiết lập theo từng liên kết và miền định tuyến thay vì tệp tĩnh; với NetworkManager là thiết lập DNS của hồ sơ kết nối và backend đã chọn; với bản phân phối dùng tích hợp resolvconf là ghi qua trình trợ giúp đó.

Đừng làm tệp thành bất biến. Thuộc tính bất biến dừng các lần gia hạn DHCP hợp lệ và cập nhật VPN cùng với những thứ bạn đang chống lại, và để hệ thống ở trạng thái mà lần nâng cấp gói hoặc kết nối lại tiếp theo tạo ra lỗi không ai có thể giải thích từ cấu hình. Nó che giấu xung đột sở hữu, đúng thứ bạn đang cố giải quyết.

Ở nơi hai thành phần thực sự phải cùng tồn tại, hãy cho chúng những nhiệm vụ khác nhau. Để trình quản lý mạng sở hữu cấu hình ở cấp giao diện, để máy khách VPN đóng góp DNS và miền theo từng liên kết qua cùng tích hợp đó, và xóa script thứ ba ghi trực tiếp tệp. Tài liệu systemd-resolved trình bày các chế độ mà nó hỗ trợ và những gì mỗi chế độ hiển thị trong /etc/resolv.conf. Chọn chế độ phù hợp với lượng chính sách bạn cần giữ. Nếu split DNS quan trọng, cách bố trí stub với miền theo từng liên kết bảo toàn nó, trong khi chế độ sao chép máy chủ thượng nguồn vào tệp lại âm thầm san phẳng nó.

Xác minh sau khi kết nối lại, không phải sau khi sửa

Một tệp trông đúng ngay sau thay đổi của bạn không chứng minh được gì, vì sự kiện tiếp theo chưa xảy ra. Kích hoạt chuỗi từng làm hỏng nó: hạ và nâng đường hầm, gia hạn lease DHCP hoặc chuyển giao diện, rồi đọc lại các giá trị đó.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Sau đó xác nhận sự phân biệt quan trọng: tên nội bộ phân giải qua máy chủ nội bộ trong khi tên công cộng vẫn hoạt động. Cấu hình gửi mọi thứ tới máy chủ nội bộ trông ổn cho đến khi ai đó cố truy cập internet qua đường hầm, và cấu hình gửi mọi thứ tới máy chủ công cộng làm rò rỉ tên nội bộ.

Ghi lại chủ sở hữu, backend và chế độ liên kết tượng trưng trong ghi chú triển khai. Một đoạn văn đó biến lần nâng cấp gói trong tương lai từ sự cố thành mục xem xét, và ngăn người tiếp theo phát hiện lại cùng xung đột bằng lệnh chattr.