DNS của VPN có thực sự được dùng? Bắt gói cổng 53 và xem

Hỏi phần lớn mọi người xem ứng dụng VPN làm gì với DNS và họ sẽ nói nó đặt trình phân giải, nên các truy vấn đi trong đường hầm. Việc đẩy xuống là thật; giả định rằng nó trở thành truy vấn thì không. Giữa một tùy chọn được đẩy xuống và một gói trên dây có ba giai đoạn, và mỗi giai đoạn hỏng độc lập theo cách trông đều giống một máy chủ DNS hỏng. Đó là lý do một trang kiểm tra rò rỉ và một trình duyệt hoạt động tốt có thể bất đồng về cùng một máy trong cùng một thời điểm.

Tùy chọn được đẩy xuống không phải truy vấn

Giai đoạn một là máy chủ đề nghị cấu hình, ví dụ một tùy chọn DNS được đẩy xuống nêu tên trình phân giải trong đường hầm. Giai đoạn hai là ứng dụng khách áp các cấu hình đó lên một giao diện. Giai đoạn ba là một ứng dụng thực sự gửi truy vấn tới địa chỉ đó. Hỏng ở giai đoạn hai để tùy chọn vẫn hiện trong nhật ký kết nối trong khi danh sách trình phân giải không đổi, và hỏng ở giai đoạn ba để một danh sách trình phân giải hoàn toàn đúng không được dùng.

Phần lớn việc xử lý sự cố gộp ba giai đoạn đó thành một và đổ lỗi cho máy chủ VPN, bên thường là bên duy nhất có thể chứng minh mình đã làm phần của mình. Thay vào đó hãy đọc trạng thái trình phân giải thực của ứng dụng khách, rồi quan sát một truy vấn đi ra. Hai quan sát đó tách cấu hình khỏi định tuyến và khỏi chính sách, và chúng tốn khoảng năm phút. Hãy giữ các bản bắt gói, vì kỹ sư tiếp theo muốn trước và sau chứ không phải mô tả về chúng.

Kiểm tra giao diện thực sự giữ gì

Trên Linux trình phân giải hệ thống có thể là tệp thường, NetworkManager hoặc systemd-resolved, và việc cái nào sở hữu nó quyết định máy chủ được đẩy xuống sẽ nằm ở đâu. Tiến trình OpenVPN trên dòng lệnh không tự cập nhật trình phân giải hệ thống, nên tích hợp được ghi chép là một script up/down hoặc một trình quản lý kết nối đã biết cách áp cấu hình. Chạy cả hai là cách hiệu quả để tạo ra một cuộc đua.

resolvectl status
cat /etc/resolv.conf

Trên Windows danh sách là theo từng bộ điều hợp, nên bộ điều hợp đường hầm có thể giữ các máy chủ nội bộ trong khi bộ điều hợp vật lý giữ các máy cục bộ và thắng với một số tên. Hãy so sánh cả hai bộ điều hợp thay vì cái bạn cho là đang hoạt động.

Theo một truy vấn ra khỏi máy

Bắt gói trên cả hai giao diện cùng lúc, rồi phân giải một tên lẽ ra phải dùng trình phân giải nội bộ. Cặp bản bắt gói đó trả lời điều mà không đầu ra cấu hình nào trả lời được.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Một truy vấn xuất hiện trên giao diện vật lý và không bao giờ trong đường hầm nghĩa là ứng dụng khách đã chọn sai trình phân giải. Một truy vấn không xuất hiện trên cả hai nghĩa là ứng dụng đã trả lời từ bộ nhớ đệm, hỏi một stub đang lắng nghe trên loopback, hoặc dùng trình phân giải mã hóa mà lưu lượng không bao giờ hiện ra như cổng 53. Cũng bắt cả câu trả lời chứ không chỉ truy vấn, vì một truy vấn đi ra qua đường hầm với câu trả lời từ một địa chỉ công cộng là lỗi khác với việc không có câu trả lời nào đến.

Tường lửa chỉ chấp nhận DNS của chính nó

Các ứng dụng khách thương mại đôi khi cài chuỗi lọc riêng. Một mẫu được ghi chép cho phép DNS tới trình phân giải riêng của ứng dụng khách và vứt bỏ toàn bộ lưu lượng UDP cổng 53 còn lại đang cố rời một giao diện không phải loopback, kể cả lưu lượng mà người dùng cố ý định tuyến đi nơi khác. Các truy vấn của daemon biến mất không dấu vết, điều này được đọc như lỗi trình phân giải chứ không phải bộ lọc.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Nếu một quy tắc vứt bỏ được đánh giá trước ngoại lệ của bạn, quy tắc được thêm vào sẽ không bao giờ được đạt tới, nên hãy chèn nó ở vị trí đầu tiên và giới hạn đích là trình phân giải mà bạn thực sự muốn.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Ngoại lệ đó là chẩn đoán chứ không phải chính sách. Nếu quy tắc của nhà cung cấp là có chủ ý, cách sửa được hỗ trợ là cấu hình ứng dụng khách cho phép trình phân giải đó và ghi lại quyết định, vì một quy tắc được chèn sẽ không sống qua lần nâng cấp ứng dụng khách tiếp theo.

Vì sao trang rò rỉ chứng minh ít hơn vẻ ngoài

Điều một trang kiểm tra rò rỉ hiển thị là trình phân giải đã nói chuyện với người vận hành bài kiểm tra, không phải cái mà máy bạn đã hỏi. Một bộ chuyển tiếp cục bộ đệ quy ra ngoài sẽ đặt địa chỉ ra của chính nó lên trang đó, và các truy vấn mã hóa có thể để trang trống hoàn toàn. Cả hai kết quả đều bị đọc sai, một là rò rỉ và một là bảo đảm, và không cách đọc nào suy ra từ quan sát.

Bằng chứng có thể bảo vệ là bản bắt gói: giao diện, địa chỉ đích, câu trả lời và mốc thời gian. Lấy một bản trước khi đường hầm lên và một bản sau đó, rồi so sánh chúng vào lần tới khi một tên thất bại. Cặp đó cũng cho người tiếp theo biết lỗi nằm ở phân giải, định tuyến hay ở chính sách truy cập của trình phân giải.