Liên kết nào trả lời: miền định tuyến cho DNS của VPN đường hầm chia tách
Tuyến mặc định và miền định tuyến DNS là hai cài đặt khác nhau. Thêm hậu tố của công ty bằng dấu ngã, sau đó hỏi resolvectl liên kết nào thực sự đã trả lời.
Giữ việc duyệt web thông thường trên liên kết cục bộ trong khi tên công ty được phân giải qua máy chủ DNS mà đường hầm cung cấp. Tắt tuyến mặc định của VPN cho bạn nửa đầu và để nửa sau chưa được xây dựng. Tiếp theo là cài đặt còn thiếu, dấu câu làm thay đổi ý nghĩa của nó, và lệnh duy nhất cho thấy liên kết nào thực sự đã trả lời. Toàn bộ văn bản giả định có NetworkManager và systemd-resolved, vì chính cặp này thường là nơi bắt đầu sự nhầm lẫn.
Bước một: tách tuyến khỏi bộ phân giải
ipv4.never-default trả lời một câu hỏi định tuyến và ngăn NetworkManager cài đặt kết nối này làm đường đi cho toàn bộ lưu lượng IPv4. Một miền định tuyến DNS trả lời câu hỏi khác: máy chủ tên của liên kết nào nhận truy vấn cho một hậu tố khớp. Không cái nào ngụ ý cái kia, và một hồ sơ có thể mang cái này trong nhiều năm trong khi thiếu cái kia. Chỉ tuyến nghĩa là đường hầm mang các mạng con của công ty và bộ phân giải của nó trả lời tên công ty, còn mọi thứ khác được để yên.
Chỉ đặt thuộc tính tuyến thì tên nội bộ thất bại, thường với thời gian chờ nghe như đường hầm bị hỏng. Chỉ đặt miền thì bạn đã lặng lẽ thêm hậu tố tìm kiếm vào mọi tên ngắn trên máy. Cả hai lỗi đều gửi phiếu đến máy chủ VPN, nơi hiếm khi là phần sai.
Bước hai: thêm miền chỉ định tuyến vào hồ sơ
Giả sử kết nối tên là corp-vpn, hậu tố công ty là internal.example, và bộ phân giải của đường hầm đã có thể truy cập. Hãy đọc các giá trị hiện tại trước, vì các lệnh bên dưới thay đổi những thuộc tính có thể đã có mục.
nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yesThay bằng tên kết nối và hậu tố của riêng bạn, vì các giá trị trên chỉ là ví dụ. Dấu cộng quan trọng hơn vẻ ngoài: với nó giá trị được thêm vào danh sách hiện có, còn không có nó thuộc tính bị thay thế và các miền không liên quan biến mất khỏi hồ sơ vốn hoạt động hôm qua. Dấu ngã thay đổi hành vi chứ không phải kiểu, và đoạn dưới giải thích nó chọn gì. Giữ việc đọc trước khi ghi, để dạng thay thế không bao giờ làm bạn bất ngờ.
Dấu ngã ở đầu đánh dấu miền chỉ định tuyến, nên các truy vấn khớp đi đến máy chủ của liên kết này và hậu tố không được thêm vào tên ngắn. Bỏ dấu ngã thì cùng chuỗi đó cũng trở thành hậu tố tìm kiếm, một kết quả khác mà người ta hiếm khi nhắm tới. Cả hai cài đặt trên là IPv4, nên hồ sơ hai ngăn xếp cần ipv6.never-default và cùng miền định tuyến trong ipv6.dns-search, nếu không phía IPv6 tiếp tục dùng tuyến mặc định và tên nội bộ thất bại ở đó.
Bước ba: hỏi resolvectl liên kết nào đã trả lời
Chạy resolvectl status và đọc máy chủ DNS cùng miền của từng liên kết, sau đó chạy resolvectl query host.internal.example với một tên nội bộ thật mà bạn được phép truy vấn. Lệnh thứ hai là bằng chứng trực tiếp duy nhất rằng miền định tuyến đang làm việc của nó, vì nó nêu tên liên kết đã trả lời. Chỉ danh sách trạng thái chứng minh cấu hình; truy vấn chứng minh phân giải.
systemd-resolved chọn miền định tuyến khớp tốt nhất, nên một miền cụ thể hơn trên liên kết khác vẫn có thể thắng cuộc đua. Nếu truy vấn trở về từ liên kết bạn không ngờ, hãy đọc danh sách miền trước khi chạm vào máy chủ DNS của VPN. Miền gốc ~. khớp với mọi thứ, và nếu nó đã có thì miền cụ thể của bạn vẫn thắng cho tên của nó trong khi liên kết trả lời nhiều hơn bạn yêu cầu. Hãy xóa hoặc thu hẹp mục gốc đó khi ý định chỉ là tên công ty.
Nếu liên kết VPN không liệt kê máy chủ DNS nào, máy khách chưa bao giờ đăng ký một cái. Miền định tuyến không có máy chủ phía sau thất bại khác với miền bị thiếu, nên hãy sửa đăng ký trước.
Bước bốn: khi tên phân giải được nhưng dịch vụ thì không
Một câu trả lời đúng chỉ chứng minh phân giải đã hoạt động, và ứng dụng vẫn cần tuyến đến địa chỉ nó nhận được. Tuyến đó phải sống sót qua tuyến mặc định chia tách bạn vừa cấu hình, nên hãy kiểm tra trước khi đổ lỗi cho DNS lần nữa. Sau đó kiểm tra khả năng tiếp cận trên cổng của dịch vụ, vì chia sẻ tệp hoặc dịch vụ thư mục thất bại ở phân giải, định tuyến hoặc xác thực và tạo ra thông báo rất giống nhau trong mỗi trường hợp. Giữ ba lớp đó riêng biệt khi báo cáo kết quả, nếu không người tiếp theo sẽ kiểm tra lại DNS vốn đã đúng.
Thay đổi trong Samba lưu hành bên cạnh câu hỏi này liên quan đến lớp truy cập, không phải lựa chọn DNS. Áp dụng nó cho sự cố phân giải tên là cách một vấn đề nhỏ có thêm vấn đề thứ hai.
Bước năm: đừng thay bộ phân giải để sửa một miền bị thiếu
Lời khuyên ghi đè tệp bộ phân giải hoặc cài một trình quản lý phân giải khác giải quyết vấn đề khác. Đó là những thay đổi tích hợp hệ thống với các chế độ lỗi riêng, và không cái nào thêm miền định tuyến chưa từng được cấu hình. Xác định thành phần nào sở hữu việc phân giải tên trên máy trước khi thay nó, vì trên màn hình NetworkManager với systemd-resolved quyền sở hữu đó đã được định nghĩa. Đấu tranh với nó là cách một thiết lập đang chạy trở thành thứ không ai có thể tái tạo.
Thứ tự công việc: xác nhận đường hầm cung cấp bộ phân giải, thêm miền chỉ định tuyến, kết nối lại qua các điều khiển hồ sơ, xác minh liên kết trả lời, rồi kiểm tra dịch vụ trên cổng của nó. Trình tự đó để lại kết quả bạn có thể bàn giao cho người tiếp theo mà không cần phỏng vấn lần hai.