DNS riêng của Pritunl thất bại? Thêm một tuyến resolver hẹp

Tên riêng được phân giải cho mọi người trên mạng doanh nghiệp và hết thời gian cho mọi người trên VPN. Resolver trả lời gateway, tuyến đến đó tồn tại, và truy vấn vẫn không bao giờ nhận được phản hồi. Thứ còn thiếu không phải một resolver công cộng khác hay một tuyến rộng hơn: đó là địa chỉ nguồn mà máy chủ DNS riêng sẵn lòng trả lời.

Xác nhận resolver đang từ chối bể máy khách của bạn

Bắt đầu bằng việc chứng minh lỗi liên quan đến nguồn, không phải khả năng tiếp cận. Từ một máy khách đã kết nối, truy vấn trực tiếp resolver riêng và quan sát xem yêu cầu hết thời gian hay trả về như một lời từ chối. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 hết thời gian trong khi cùng truy vấn từ gateway thành công cho thấy một chính sách truy cập trên resolver. Câu trả lời SERVFAIL chỉ đến một nơi hoàn toàn khác, thường là vùng hoặc bộ chuyển tiếp thượng nguồn.

Ghi lại địa chỉ của máy khách trước khi kiểm tra. ip -4 addr show tun0 trên máy khách, hoặc hợp đồng thuê hiển thị trong bảng điều khiển, cho bạn biết resolver nhìn thấy bể nào.

Sau đó xác nhận tuyến đường tồn tại. Một tuyến gửi địa chỉ resolver vào đường hầm là điều kiện tiên quyết, không phải giải pháp; nếu gói tin không bao giờ đến, chính sách nguồn thậm chí không được xem xét. Kiểm tra bằng ip route get 10.40.0.53 trên máy khách.

Thêm một tuyến host thay vì dịch mọi thứ

Hướng dẫn DNS riêng của Pritunl mô tả biện pháp hẹp: một tuyến /32 có NAT cho địa chỉ resolver, với địa chỉ đó được chọn làm máy chủ DNS của máy khách. Tuyến chỉ thay đổi nguồn mà resolver nhìn thấy đối với lưu lượng DNS. Lưu lượng ứng dụng giữ thiết kế bảo toàn nguồn mà bạn đã chọn cho nó.

Cấu hình nó thông qua chủ sở hữu tuyến được máy chủ hỗ trợ, sau khi xem xét các tuyến hiện có để tránh chồng lấn. Trong ví dụ trên, đích là 10.40.0.53/32 có NAT, và bể máy khách vẫn là 10.90.0.0/24. Đừng dịch toàn bộ dải riêng để sửa một dịch vụ, vì mọi chính sách hạ nguồn dựa vào địa chỉ thật của máy khách sẽ bắt đầu thấy gateway thay thế. Xác nhận địa chỉ mà resolver thực sự nhận được bằng cách xem nhật ký truy vấn của nó trong một lần tìm kiếm thử. Chỉ một tuyến host không chứng minh được gì về dịch hay quyền.

Resolver vẫn phải cho phép nguồn đã dịch trên UDP và TCP, và các phản hồi của nó phải có thể quay lại. Thay đổi nguồn không thể tạo ra một vùng hay bản ghi còn thiếu.

Quyết định xem máy chủ hay máy khách gửi truy vấn

Pritunl cũng ghi lại một cách bố trí proxy DNS gắn với VPN Client DNS Mapping, trong đó máy chủ chuyển tiếp truy vấn thượng nguồn cho máy khách. Trong mô hình đó, nguồn thượng nguồn thuộc ngữ cảnh mạng của chính máy chủ, và ngoại lệ phía máy khách là giải pháp sai.

Xác định mô hình nào đang hoạt động trước khi thêm bất cứ thứ gì. Ba sửa chữa chồng lấn, một proxy, một ghi đè resolver trên máy khách và một script NAT thủ công thường có nghĩa là chưa ai xác lập: thành phần nào phải gửi truy vấn. Kiểm tra cả bootstrap: resolver chỉ riêng không thể là cách duy nhất để tìm điểm cuối trước khi đường hầm tồn tại, và thay đổi resolver vĩnh viễn không nên tồn tại lâu hơn kết nối.

Kiểm tra một truy vấn riêng, không phải một trang web công cộng

Sau khi áp dụng thay đổi và kết nối lại, xem xét cấu hình resolver hiệu lực của máy khách, rồi phân giải một tên mà bạn biết chỉ tồn tại trong vùng riêng. dig intranet.example.net không có máy chủ rõ ràng cho thấy máy khách thực sự dùng gì. Tiếp theo gửi một yêu cầu đến địa chỉ mà lần tìm kiếm đó trả về, vì phân giải và truy cập dịch vụ là những bước riêng. Một trình duyệt tải các trang công cộng qua DNS-over-HTTPS không chứng minh được gì về đường resolver riêng của hệ điều hành. Một resolver thứ cấp công cộng cũng không phải thẩm quyền cho một vùng nội bộ.

Ghi lại địa chỉ resolver, tuyến /32 và thiết lập DNS của máy khách cùng nhau trong ghi chú máy chủ. Khôi phục một nửa cấu hình đó một mình sẽ tái tạo lỗi ban đầu.

Cuối cùng, xác nhận đường hầm vẫn định tuyến đích của ứng dụng sau khi DNS thành công. Tuyến, truy cập dịch vụ và xác thực vẫn độc lập với phân giải tên, và một lần tìm kiếm hoạt động không nói gì về thông lượng. Nếu trang riêng chậm nhưng vẫn phân giải được, resolver đã làm xong việc của nó và vấn đề chuyển sang tuyến.