Vì sao DNS của chính router lại đi vòng qua đường hầm VPN?

Các truy vấn của máy khách đi theo đường hầm, trong khi truy vấn của chính router đi ra qua WAN, và quy tắc tường lửa điều khiển cái này không có tác dụng gì với cái kia. Lý do không phải là lỗi: một yêu cầu được chuyển tiếp và một yêu cầu do router tự tạo là hai luồng riêng biệt, và mỗi luồng được đối chiếu với một phần khác của cấu hình. Chỉ bắt nửa phía máy khách sẽ cho một câu trả lời chắc chắn về con đường mà nửa kia không bao giờ dùng. Cách sửa là chủ động chỉ định bộ phân giải của router, rồi kiểm tra riêng hai con đường.

Bản bắt gói tin thực sự thuộc luồng nào

Một truy vấn gồm hai lần trao đổi. Một máy khách trong LAN gửi truy vấn tới bộ phân giải của router, và truy vấn đó đến dưới dạng lưu lượng được chuyển tiếp trên giao diện LAN, nên một tuyến chính sách hoặc quy tắc NAT viết cho gói được chuyển tiếp có thể khớp với nó. Sau đó router trả lời từ bộ nhớ đệm hoặc, khi không có bản ghi, mở truy vấn của chính nó tới một máy chủ thượng nguồn.

Truy vấn thứ hai đó lấy router làm nguồn và làm đích của chính nó, và nền tảng chọn đường đi của nó từ một khối cấu hình khác. Cả hai lần trao đổi mang cùng một tên, và không cái nào là bản sao của cái kia. Vì vậy một bản bắt gói tin lấy ở phía LAN chứng minh gói của máy khách đã đi đâu và không nói gì về gói đi ra.

Kiểm tra thực tế là quan sát cả hai phía cùng lúc. Trên router, liệt kê socket của bộ phân giải, truy vấn nó cục bộ và bắt giao diện WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Nếu danh sách socket cho thấy một trình lắng nghe gắn với địa chỉ loopback hoặc LAN, router đang trả lời cục bộ thay vì chuyển tiếp tới một máy chủ khác. Khi đó bản bắt sẽ cho biết truy vấn thượng nguồn phát sinh đi ra qua giao diện đường hầm hay qua WAN, và đó là câu trả lời mà quy tắc tuyến chính sách sẽ không bao giờ đưa ra.

Vì sao tuyến chính sách không bao giờ thấy truy vấn thứ hai

Các quy tắc tường lửa được viết theo giao diện, nguồn, đích và cổng, và chúng được đánh giá cho các gói đi qua thiết bị. Một truy vấn do router tạo ra không đi qua gì cả, vì một tiến trình cục bộ chuyển thẳng nó cho bảng định tuyến. Định tuyến theo chính sách và NAT do đó chỉ áp dụng cho con đường được chuyển tiếp, và chính vì thế một bộ quy tắc có thể trông đầy đủ mà vẫn để DNS của router ở ngoài đường hầm.

Sự phân biệt này tồn tại qua mỗi lần viết lại phần mềm nhúng vì nó xuất phát từ đường đi của gói chứ không từ một tính năng. Mọi thứ thiết bị tạo ra cho chính nó, dù là truy vấn của bộ phân giải, đồng bộ thời gian, kiểm tra cập nhật hay truy cập gương gói, đều có nguồn gốc cục bộ và rơi vào cùng một điểm mù. Đó cũng là lý do một bài kiểm tra từ máy tính xách tay không chứng minh được gì về router.

Bộ phân giải của pfSense quyết định con đường thượng nguồn của nó ở đâu

pfSense làm cho sự tách biệt đó trở nên hữu hình. Lưu lượng của máy khách có thể được định tuyến theo chính sách qua một cổng VPN trong khi lưu lượng của chính tường lửa đi theo thiết lập lối ra của bộ phân giải thay vì các quy tắc LAN. Trong giao diện web, thiết lập đó nằm dưới Services > DNS Resolver > Outgoing Network Interfaces, và giá trị của nó là danh sách các giao diện mà bộ phân giải có thể dùng cho truy vấn thượng nguồn.

Nêu tên giao diện đường hầm ở đó, và chỉ giao diện đó, là điều khiến truy vấn của chính router đi theo đường hầm. Nếu để mặc định, bộ phân giải chọn lối ra từ bảng định tuyến, mà trên một máy chủ có hai WAN hoặc VPN thì thường là WAN.

Các phần mềm nhúng khác cũng bộc lộ quyết định đó dưới một nhãn khác: danh sách máy chủ thượng nguồn gắn với một địa chỉ nguồn, chế độ chỉ chuyển tiếp, hoặc một chính sách tuyến được ghi lại. Thiết lập cần tìm luôn là thiết lập chọn lối ra hoặc nguồn cho các truy vấn được tạo cục bộ. Tài liệu tham chiếu cấu hình bộ phân giải ghi lại tùy chọn đó cho pfSense và đáng đọc trước khi thay đổi.

Chọn hành vi khi có sự cố trước khi chọn thiết lập

Khi đường hầm sụp, hai hành vi là biện hộ được: dừng truy vấn thượng nguồn để không rò rỉ gì, hoặc quay về một bộ phân giải đã được phê duyệt trên một con đường đã biết. Cả hai đều là chính sách, và không cái nào là thứ mặc định có được. Hãy quyết định mạng cần cái nào trước khi chạm vào danh sách giao diện.

Đóng lại khi sự cố dễ biện hộ hơn, nhưng nó biến việc đường hầm đứt thành việc phân giải tên bị đứt cho mọi thiết bị phía sau router. Phương án dự phòng giữ văn phòng dùng được, với cái giá là một lần trao đổi thượng nguồn ngoài đường hầm phải được chấp nhận có chủ đích chứ không phải tình cờ. Hãy ghi lựa chọn ra, vì người tiếp theo nhìn thấy một địa chỉ bộ phân giải ngoài VPN sẽ đọc đó là rò rỉ trừ khi một ghi chú nói khác. Chính ghi chú đó tách một phương án dự phòng được ghi lại khỏi một phát hiện không giải thích trong buổi rà soát quý sau.

Hai trường hợp làm phức tạp quyết định. Tên riêng có thể cần một bộ phân giải nội bộ mà đường hầm tiếp cận được, và một trình duyệt hoặc ứng dụng có DNS mã hóa riêng có thể đi vòng hoàn toàn qua router, nên bộ phân giải bạn đã cấu hình không phải lúc nào cũng là cái một ứng dụng nhất định dùng.

Kiểm tra cả hai con đường và giữ kết quả riêng

Một bài kiểm tra DNS trên trình duyệt trả lời một câu hỏi hẹp: trong điều kiện của bài kiểm tra đó, trình duyệt ấy đã dùng những bộ phân giải nào. Nó không kiểm kê thiết bị trong mạng và không thể thấy một truy vấn do router tạo cho chính nó. Hãy coi đầu ra của nó là một điểm dữ liệu chứ không phải một cuộc kiểm toán.

Từ một máy khách trong LAN, hỏi router một tên công khai rồi một tên riêng mà chỉ vùng nội bộ của bạn mới phải trả lời. Chỉ thất bại ở truy vấn thứ hai là dấu hiệu của việc chuyển tiếp tên chứ không phải đường hầm:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Sau đó hạ đường hầm xuống và lặp lại cả hai truy vấn. Câu trả lời bị từ chối nghĩa là bộ phân giải đóng lại khi có sự cố; một câu trả lời thành công chỉ ra một bộ phân giải dự phòng và con đường nó đã dùng. So sánh điều đó với ghi chú bạn đã viết và với một bản bắt trên giao diện WAN lấy trong cùng phút.

Giữ riêng các quan sát trong biên bản: lần trao đổi giữa máy khách và router, lần trao đổi giữa router và máy chủ thượng nguồn, và cấu hình đã quyết định lần thứ hai. Một thay đổi định tuyến sau này sẽ thực thi lần trao đổi thứ hai đó mà không báo trước. Một câu trả lời đến từ nơi khác điểm cuối VPN không tự nó là rò rỉ; nó chỉ trở thành rò rỉ khi cấu hình đã chọn con đường đó một cách tình cờ.