Vì sao các truy vấn dnsmasq thoát khỏi VPN sau khi chuyển hướng DNS

Máy khách trong LAN vẫn tới VPN của mình đúng cách, ấy thế mà các truy vấn DNS của nó lại xuất hiện trên đường lên sai. Đây không phải rò rỉ theo nghĩa thông thường; đó là điều xảy ra khi router thôi chuyển tiếp một truy vấn và tự trả lời nó. Việc chặn bắt ghi lại đích đến thành một socket cục bộ, rồi bộ phân giải mở một cuộc trò chuyện thứ hai, không liên quan, với địa chỉ nguồn của chính nó và quyết định định tuyến của chính nó. Các dấu áp lên luồng máy khách mô tả cuộc trò chuyện thứ nhất và hoàn toàn không nói gì về cuộc thứ hai.

Dấu không đi cùng truy vấn

Các dấu gói nằm trên một mục conntrack và trên gói đang bay. Một quy tắc REDIRECT kết thúc chuyến bay đó: tải trọng được giao cho socket cục bộ, và mục gốc đã làm xong việc của nó. Thứ rời khỏi router sau đó là một socket mới do tiến trình bộ phân giải tạo ra, với địa chỉ của chính router là nguồn.

Đó là lý do một tuyến chính sách gắn với địa chỉ của máy khách trong LAN không bao giờ khớp với truy vấn thượng nguồn. Socket mới thuộc về dnsmasq chứ không phải máy khách, và nhân đánh giá tuyến cho lưu lượng của chính router. Các quy tắc nguồn, quy tắc giao diện và quy tắc dấu đều thấy một bộ khác. Giả định rằng dấu lan truyền là lỗi phổ biến nhất trong thiết lập này, và nó vô hình trong một bản bắt gói phía máy khách.

Hai cuộc trò chuyện thực sự chia sẻ một tên và một thời điểm, và đó là điều khiến chúng trông như một luồng duy nhất khi bạn lướt nhanh qua một bản bắt gói.

Nơi việc chuyển tiếp trở thành phân giải cục bộ

Hãy bắt đầu bằng việc xác định xem cổng 53 có bị chuyển hướng, bị dịch sang máy chủ khác hay được để nguyên, vì ba trường hợp hành xử khác nhau. Chuyển hướng tới một cổng cục bộ kết thúc việc chuyển tiếp, trong khi dịch sang máy khác vẫn giữ gói di chuyển và giữ bộ của máy khách có ý nghĩa.

Hãy xem cả hai giao thức. Một bộ phân giải truy cập được qua UDP và TCP sẽ được thử trên cả hai, và một bộ quy tắc chỉ phủ UDP để lại một lỗ hổng im lặng cho các câu trả lời lớn. Các quy tắc do chính trình quản lý cấu hình của router sinh ra cũng được tính, và việc sửa một tệp được sinh ra thường thua lần nạp lại tiếp theo.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Những đầu ra đó trả lời ba câu hỏi theo thứ tự: cái gì ghi lại truy vấn, cái gì nhận nó, và tiến trình nào sở hữu socket đang lắng nghe. Khi đã biết chủ sở hữu, chính sách thượng nguồn có chỗ để ở.

Cho bộ phân giải chính sách lối ra của riêng nó

Một thượng nguồn dành riêng cho miền là công cụ sạch nhất khi chỉ một số tên cần đường hầm. dnsmasq chấp nhận dòng server giới hạn trong một miền, với giao diện hoặc địa chỉ nguồn tùy chọn để đưa truy vấn ra khỏi một thiết bị đã chọn. Chính sự dẫn hướng đó khiến cuộc trò chuyện thứ hai đi theo VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

Miền, địa chỉ và giao diện ở trên là chỗ giữ chỗ cho các giá trị của riêng bạn. Việc chọn miền và kiểm soát lối ra vẫn là hai quyết định riêng: tuyến phải tồn tại, địa chỉ nguồn phải được bộ phân giải thượng nguồn cho phép, và tường lửa phải cho phép câu trả lời. Chỉ dẫn hướng bằng giao diện thì không phải fail-closed, vì một đường hầm biến mất có thể khiến bộ phân giải rơi sang đường khác. Hãy giữ mọi phương án dự phòng công khai tránh xa một không gian tên phải ở lại riêng tư.

Đặt dòng đó ở chủ sở hữu cấu hình mà router hỗ trợ chứ không phải trong một tệp được sinh ra, nếu không lần nạp lại tiếp theo sẽ xóa bản sửa.

Điều mà bộ nhớ đệm dùng chung không thể giữ

Một bộ chuyển tiếp với một bộ nhớ đệm phục vụ mọi máy khách trong LAN, và điều đó làm sụp đổ một phân biệt mà một số mạng cần. Nếu hai máy khách phải phân giải cùng một tên theo cách khác nhau, socket dùng chung không có cách nào khôi phục máy khách nào đã hỏi. Chính sách theo từng máy khách phải sống trong các phiên bộ phân giải riêng hoặc trong một tính năng chuyển tiếp giữ lại danh tính.

Một câu trả lời được lưu đệm cũng không phải bằng chứng về tuyến mới. Câu trả lời có thể đến từ bộ nhớ trong khi tuyến thượng nguồn vẫn hỏng.

Các quy tắc cổng 53 không nói gì về những ứng dụng nói DNS qua HTTPS hoặc qua TLS. Những truy vấn đó không bao giờ tới chỗ chuyển hướng, vì vậy một chính sách chỉ dựa trên cổng 53 mô tả một tập con của lưu lượng và nên được ghi nhận là một tập con.

Hãy kiểm chứng cuộc trò chuyện thứ hai, không phải cuộc thứ nhất

Hãy thử với một tên bạn kiểm soát và quan sát cả hai phía. Bản bắt gói phía máy khách chứng minh truy vấn đã rời LAN; chỉ phía router mới chứng minh nó đi đâu tiếp theo.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Xóa bộ nhớ đệm trước mỗi lần thử, vì một câu trả lời ấm che giấu thượng nguồn hỏng. Lặp lại qua TCP, rồi lặp lại với đường hầm đã tắt để xem bộ phân giải làm gì khi tuyến ưa thích của nó không còn. Chính hành vi cuối cùng đó quyết định thiết kế là fail-closed hay chỉ may mắn.