ip netns exec và DNS: vì sao tên không phân giải được bên trong không gian tên

Một lệnh đến được 10.8.0.5 bên trong không gian tên VPN mà không hề báo lỗi, và chính lệnh đó thất bại ngay khi nó dùng một tên máy chủ. Không gian tên có giao diện, tuyến đường và socket riêng; nó không có tệp phân giải riêng. Trừ khi có thứ gì đó đặt một tệp vào đó, tiến trình bên trong đọc /etc/resolv.conf của máy chủ và hỏi một máy chủ tên có thể không đến được từ ngăn xếp mạng đó.

Đây là vấn đề chọn tệp chứ không phải vấn đề định tuyến, và chính vì thế mà địa chỉ số vẫn hoạt động.

Kiểm tra góc nhìn của bộ phân giải mà tiến trình thực sự nhận được

Đừng cho rằng shell bạn dùng tương đương với tiến trình bạn đang gỡ lỗi. Một ứng dụng đồ họa, một unit của systemd và một container đều có thể đi vào một ngữ cảnh gắn kết hoặc mạng khác. Chạy truy vấn qua đúng đường khởi chạy đó, và in tệp phân giải từ bên trong.

Với một không gian tên được tạo bằng ip netns add, bước kiểm tra chỉ đọc rất ngắn:

ip netns exec vpn cat /etc/resolv.conf

Hãy để ý xem kết quả có nêu một địa chỉ đến được, một stub loopback, hay một liên kết tượng trưng trỏ tới nơi có khả năng đến khác hay không.

Trình trợ giúp exec thực sự gắn kết những gì

Công cụ ip-netns ghi lại cấu hình theo từng không gian tên dưới /etc/netns/NAME/. Khi nó khởi chạy một tiến trình, trình trợ giúp tạo một không gian tên gắn kết và gắn các tệp đó đè lên đường dẫn thông thường của chúng, nên tiến trình thấy bản sao riêng của không gian tên. Đó là tiện ích của đúng trình khởi chạy này. Đi vào một không gian tên mạng bằng đường khác, ví dụ unshare hoặc runtime container, không tự động tái tạo điều đó.

Cái bẫy ở đây là bộ phân giải loopback: 127.0.0.53 nghĩa là loopback của chính không gian tên, không phải stub của máy chủ. Một stub chỉ lắng nghe trong không gian tên của máy chủ không trở thành dịch vụ trong không gian tên mới.

Chọn một bộ phân giải mà không gian tên có thể đến được

Dù tệp nêu máy chủ nào, nó vẫn cần một tuyến đường từ không gian tên đó. Một bộ phân giải công cộng có thể trả lời các tên công cộng mà vẫn thất bại với một vùng nội bộ, vì dịch vụ riêng chỉ đến được qua đường hầm. Hãy kiểm tra tuyến đường cùng lúc với địa chỉ, chứ không phải sau khi truy vấn đã thất bại.

Các ứng dụng có bộ phân giải riêng, như ứng dụng dùng DNS over HTTPS, có thể bỏ qua tệp hoàn toàn. Nếu công cụ có thiết lập DNS riêng, việc thay đổi resolv.conf sẽ không ảnh hưởng tới nó, và không gian tên chưa bao giờ là vấn đề.

Ghi tệp vào đúng chỗ

Tạo tệp riêng cho không gian tên dưới /etc/netns/NAME/resolv.conf và để trình khởi chạy trình bày nó. Giữ nó tối thiểu: một hoặc hai máy chủ đến được và các miền tìm kiếm mà nhiệm vụ cần. Đừng sửa tệp phân giải được tạo của máy chủ để chữa một góc nhìn dành cho một nhóm tiến trình, vì điều đó thay đổi mọi ứng dụng trên máy. Nếu máy chủ dùng trình quản lý bộ phân giải, hãy cấu hình đường dẫn không gian tên qua trình quản lý đó thay vì chống lại nó.

Ghi nội dung tệp vào runbook. Nếu không, người tiếp theo sẽ thử bộ phân giải của máy chủ, thấy một câu trả lời hoạt động và kết luận rằng không gian tên vẫn ổn.

Kiểm thử lại toàn bộ đường đi

Kiểm thử bên trong không gian tên với một địa chỉ số, một tên nội bộ và một tên công cộng. Trình tự đó tách khả năng đến khỏi việc phân giải và tách các vùng nội bộ khỏi vùng công cộng. Sau đó tạo lại không gian tên và lặp lại, vì một tệp chỉ tồn tại trong một phiên bản đang chạy sẽ biến mất cùng với nó.

Xác nhận rằng tiến trình, chứ không phải shell, là bên nhận tệp. Một truy vấn chạy được từ shell tương tác và thất bại từ một dịch vụ là một phát hiện về ngữ cảnh gắn kết, và đáng để ghi lại trước sự cố tiếp theo thay vì phát hiện lại từ đầu.