Một phản hồi STUN tiết lộ điều gì khi VPN chạy trên router
Địa chỉ đường hầm của router không phải địa chỉ cục bộ của trình duyệt. Theo dõi cách mỗi yêu cầu được định tuyến và dịch trước khi đọc những gì một bộ phản xạ báo cáo.
Khi đường hầm nằm trên router, máy chạy trình duyệt hoàn toàn không có giao diện đường hầm nào. Hỏi máy đó về các địa chỉ cục bộ của nó và bạn nhận được một địa chỉ LAN riêng và một vòng lặp, không có gì giống địa chỉ VPN. Tuy vậy, một máy chủ STUN ở phía bên kia vẫn có thể báo cáo điều gì đó có ý nghĩa về đường đi, và những gì nó báo cáo phụ thuộc hoàn toàn vào cách yêu cầu cụ thể đó được định tuyến và dịch.
Đây chính là phần đáng để chậm lại. „Trình duyệt không sở hữu địa chỉ VPN“ trả lời một câu hỏi về giao diện, trong khi một địa chỉ phản xạ là câu trả lời về một đường đi qua bản dịch. Gộp hai điều đó lại tạo ra những kết luận tự tin về việc tiết lộ mà bằng chứng không ủng hộ.
Hai thiết bị, hai bộ giao diện
Trong một thiết lập dựa trên router, đường hầm kết thúc tại router và máy khách LAN gửi lưu lượng thông thường tới cổng mặc định của nó. Danh sách giao diện của máy khách vẫn ngắn: một địa chỉ riêng, có thể thêm một địa chỉ cho mạng khác, và vòng lặp. Rủi ro không phải là một trong số đó tình cờ là địa chỉ đường hầm; mà là yêu cầu đi ra theo một đường bạn không chọn.
Hãy hỏi máy khách một đích cụ thể sẽ đi theo đường nào thay vì hỏi có những giao diện nào. Câu trả lời nêu tên một cổng và địa chỉ nguồn mà nhân sẽ dùng, và điều đó đã nhiều thông tin hơn bất kỳ bản kiểm kê địa chỉ nào.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsCác dải địa chỉ dành cho tài liệu là đích thử nghiệm tốt vì chúng không bao giờ phân giải thành một dịch vụ thật. So sánh điều máy khách nói với điều router nói, và coi mọi khác biệt là bằng chứng rằng định tuyến theo chính sách, một quy tắc đường hầm chia tách hay một tuyến mặc định thứ hai đang làm điều bạn chưa tính đến.
Điều mà một phản hồi Binding được phép nói
RFC 8489 định nghĩa yêu cầu và phản hồi Binding, trong đó máy chủ báo cáo địa chỉ vận chuyển nguồn mà nó quan sát được cho yêu cầu đó. Đây là một phát biểu về một bộ năm thành phần tại một thời điểm, không phải một cuộc kiểm tra giao diện của máy khách. Vì vậy mọi điều thú vị xảy ra giữa máy khách và điểm quan sát.
Khoảng trống đó được lấp bằng định tuyến và dịch địa chỉ. Một router thực hiện NAT nguồn trên lưu lượng đi ra sẽ thay nguồn riêng của máy khách bằng địa chỉ của chính nó trên giao diện đi ra. Nếu giao diện đó là đường hầm, bộ phản xạ thấy địa chỉ đường hầm. Nếu gói tin bị loại khỏi đường hầm, bộ phản xạ thấy những gì bản dịch WAN tạo ra. Cùng máy khách, cùng bộ phản xạ, câu trả lời khác.
Ba trường hợp trông giống nhau mà không phải vậy
Sự phân biệt hữu ích không phải công khai so với riêng tư, mà là điểm thực thi nào đã xử lý gói tin. Hãy làm từng trường hợp với bảng của chính router mở ra, vì một trình duyệt có thể tạo ra cả ba tùy theo một quy tắc bạn quên rằng mình đã viết.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Chỉ trường hợp thứ hai vi phạm yêu cầu rằng một số lưu lượng không bao giờ đi ra trực tiếp, và chỉ trường hợp thứ nhất và thứ ba tiết lộ một định danh từ phía đường hầm. Không hàng nào trong ba hàng là tuyên bố về hành vi của một nhà cung cấp cụ thể: liệu một bộ phản xạ riêng có thể tới được hay không phụ thuộc vào định tuyến, các địa chỉ IP được phép của phía bên kia và chính sách tường lửa ở cả hai đầu.
Có tài khoản ở cùng nhà cung cấp không chứng minh được điều nào trong số đó. Cũng nên nhớ rằng một yêu cầu đã định tuyến có thể giữ nguồn LAN của máy khách nếu không có gì dịch nó, nên trường nguồn phải được theo dõi thay vì suy đoán từ sơ đồ cấu trúc mạng.
Thu thập không phải lựa chọn
WebRTC thu thập các địa chỉ ứng viên để thử, và một ứng viên xuất hiện trong danh sách chẩn đoán có thể không bao giờ mang phương tiện. Đọc danh sách đó như „đây là điều phía bên kia đã học được“ là đánh giá quá cao bằng chứng. Cặp được chọn mới là cặp thực sự mang phiên, và nó nằm ở một trường khác.
Một bộ kiểm tra lối ra HTTPS trả lời một câu hỏi khác: địa chỉ nguồn mà một máy chủ web đã thấy cho yêu cầu đó. Đây là một phép kiểm tra chéo hữu ích chính vì nó dùng giao thức khác và thường dùng đích khác so với bộ phản xạ UDP, và sự khác biệt giữa hai bên thường chỉ ra một quy tắc định tuyến chứ không phải lỗi.
Quyết định chính sách, rồi đọc câu trả lời
Viết ý định ra trước khi kiểm tra: lưu lượng nào phải dùng đường hầm, lưu lượng nào có thể đi ra trực tiếp, những họ địa chỉ nào thuộc phạm vi, và điều gì nên xảy ra khi đường hầm ngừng hoạt động. Không có đường cơ sở đó, mọi quan sát đều mơ hồ, vì bạn không thể tách một sự rò rỉ khỏi một đường bạn cố ý cho phép.
Sau đó hỏi mỗi lần một câu. Đích này đi theo đường nào. Bộ phản xạ này báo cáo địa chỉ nào. Phiên đã chọn cặp ứng viên nào. Giữ các câu trả lời bên cạnh chính sách và ghi ngày, vì một bản cập nhật phần mềm có thể thay đổi hành vi mặc định theo cách âm thầm vô hiệu hóa kết luận của năm ngoái.
Router vẫn là một điểm thực thi mạnh, vì nó thấy lưu lượng mà một máy khách không thể tránh nếu không tự cấu hình lại. Đây không phải lời hứa rằng mọi trường trong mọi giao thức ứng dụng không tiết lộ gì, và cũng không thay thế việc ghi lại những đường bạn đã chọn cho phép.