Tên nội bộ hỏng khi dùng VPN còn trang công khai vẫn phân giải bình thường

Một người dùng báo rằng tên máy chủ nội bộ không phân giải được qua VPN. Báo cáo thứ hai, từ chính chiếc laptop đó, nói rằng bài kiểm tra rò rỉ vẫn cho thấy các truy vấn được bộ phân giải cục bộ trả lời. Chúng nghe như một vấn đề nhưng là hai vấn đề, với bằng chứng khác nhau, và cách sửa thông thường cho vấn đề thứ nhất lại làm vấn đề thứ hai tệ hơn. Hãy tách chúng ra trước khi chạm vào bất kỳ cài đặt nào.

Hai triệu chứng không phải một lỗi

Không phân giải được một tên nội bộ nghĩa là câu hỏi đã đi tới nơi không có câu trả lời cho nó. Truy vấn thoát khỏi đường hầm nghĩa là câu hỏi đã đi sai chỗ ngay cả khi câu trả lời vẫn sẵn có. Đó là hai lỗi ngược nhau: một bên thiếu câu trả lời, bên kia thừa một đích đến.

Cái bẫy là thêm bộ phân giải văn phòng ở mọi nơi sẽ sửa lỗi thứ nhất và bảo đảm lỗi thứ hai. Thêm bộ phân giải công cộng ở mọi nơi thì làm ngược lại.

Hãy ghi lại cả hai quan sát kèm dấu thời gian, rồi làm bốn bước kiểm tra dưới đây theo thứ tự.

Bộ phân giải của adapter nào nhận câu hỏi

Trên Windows, máy khách DNS chọn máy chủ theo thứ tự ràng buộc của adapter, và adapter đường hầm không tự động đứng đầu. Mở phần cài đặt nâng cao của adapter, chuyển kết nối truy cập từ xa lên trên adapter vật lý, rồi kết nối lại để thay đổi áp dụng cho một phiên mới.

Thứ tự ràng buộc chỉ là nửa đầu. Máy khách còn phải biết những tên nào thuộc adapter đó, và đây là câu hỏi về hậu tố chứ không phải về thứ tự.

Đặt ipconfig /all của máy đang chạy tốt cạnh kết quả của laptop, cả hai đều lấy khi đường hầm đã lên. Máy chạy tốt sẽ hiển thị một hậu tố DNS riêng cho kết nối trên adapter văn phòng, còn laptop có thể không hiển thị gì trên đường hầm. Khác biệt đó giải thích cả một nhóm báo cáo kiểu “máy chủ ở ngay đó mà tên vẫn hỏng”, vì nếu không có hậu tố thì tên ngắn không bao giờ được hoàn thành thành vùng mà bộ phân giải văn phòng phục vụ.

Tên ngắn cần hậu tố trước khi cần tuyến đường

Gõ một tên máy chủ không đủ điều kiện là yêu cầu bộ phân giải đoán một miền. Phỏng đoán đến từ danh sách hậu tố gắn với kết nối, và nếu danh sách đó trống thì truy vấn đi ra như một nhãn duy nhất mà không vùng riêng nào khớp được.

Sao chép hậu tố của máy chạy tốt vào thuộc tính IPv4 của adapter VPN trên tab DNS, rồi kết nối lại. Trên Linux, tương đương là miền tìm kiếm trên liên kết đường hầm, thứ mà systemd-resolved hiển thị theo từng liên kết chứ không phải toàn cục.

Giữ hai cài đặt tách biệt trong ghi chú của bạn. Hậu tố thay đổi cái được hỏi; địa chỉ bộ phân giải thay đổi người được hỏi. Sửa cái này khi cái kia sai sẽ tạo ra kết quả trông có vẻ ngẫu nhiên.

Hỏi thẳng bộ phân giải, rồi hỏi tên

Truy vấn trực tiếp tới bộ phân giải văn phòng tách vấn đề tên khỏi vấn đề đường đi, vì nó bỏ qua hoàn toàn việc máy khách chọn bộ phân giải.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Lệnh thứ nhất hỏi một máy chủ cụ thể về một tên đầy đủ. Nếu nó trả lời, bộ phân giải và tuyến tới nó đều ổn và lỗi nằm ở việc chọn hoặc ở hậu tố. Nếu hết thời gian chờ, địa chỉ sai hoặc không tới được và vấn đề là định tuyến chứ không phải DNS. Lệnh thứ hai cho thấy điều gì xảy ra với tên ngắn, còn lệnh thứ ba in cấu hình bộ phân giải theo từng liên kết trên máy chủ dùng systemd.

Để ý các câu trả lời đại diện, thứ mà một số mạng trả về cho những tên không tồn tại. Một câu trả lời trông hợp lý không phải bằng chứng rằng máy chủ định gửi đã trả lời, nên hãy so sánh địa chỉ nhận được với địa chỉ mà dịch vụ nội bộ thực sự dùng. Nếu địa chỉ thuộc về một trang đỗ hoặc một proxy, bộ phân giải đã trả lời nhưng câu trả lời chưa bao giờ là của bạn. Sự phân biệt đó tiết kiệm một giờ đồng hồ đuổi theo một đường hầm vốn vẫn chạy tốt suốt thời gian qua.

Trên Linux, một máy khách VPN ghi lại /etc/resolv.conf sẽ thay thế hoàn toàn các bộ phân giải cục bộ. vpnc cung cấp DNSUpdate no để chặn việc đó, và systemd-resolved có thể chỉ định tuyến các miền được liệt kê tới liên kết đường hầm. Cả hai cách đều giữ tên công cộng trên bộ phân giải cục bộ trong khi gửi tên nội bộ tới văn phòng.

Rò rỉ là một quy tắc, không phải một ô đánh dấu

Phân giải tên là một trao đổi UDP tới cổng 53, nên một đường hầm chở lưu lượng web mà không chở UDP sẽ để truy vấn trên đường vật lý. Hãy chứng minh bằng cách bắt gói trên card mạng vật lý trong khi một tên công cộng đang được phân giải. Một truy vấn hiện ra trên giao diện đó ở dạng đọc được nghĩa là đường hầm không chở nó.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Nếu truy vấn xuất hiện trên giao diện đó ở dạng đọc được thì đường hầm không chở nó. Cách sửa là một quy tắc chỉ cho phép cổng 53 tới bộ phân giải mà VPN đẩy xuống và loại bỏ các đích khác, cộng với cấu hình máy khách không âm thầm bỏ qua tùy chọn được đẩy.

Phần cuối đó quan trọng hơn vẻ ngoài của nó. Khởi động OpenVPN với route-nopull thì tùy chọn DNS được đẩy sẽ biến mất cùng các tuyến, trừ khi bộ lọc kéo được mở rộng để giữ nó. Và một máy khách bỏ qua dhcp-option DNS sẽ tiếp tục dùng bất cứ thứ gì nó có trước đó. Mọi thay đổi phía máy chủ cần một phiên mới mới có hiệu lực, vì danh sách bộ phân giải được giao khi đường hầm lên và một phiên cũ vẫn tiếp tục hiển thị trạng thái cũ.

Ghi lại lỗi nào bạn thực sự quan sát được trước khi đóng phiếu. Thiếu một câu trả lời nội bộ và một truy vấn thoát khỏi đường hầm đòi hỏi cách sửa khác nhau, và một thay đổi hậu tố sửa lỗi thứ nhất có thể lặng lẽ làm lỗi thứ hai nặng hơn. Người nhận phiếu tiếp theo sẽ tin vào nhãn, nên hãy làm nhãn chính xác.