NAT đối xứng và VPN: hãy đo ánh xạ, không đo nhãn
Ánh xạ phụ thuộc điểm cuối ảnh hưởng đến việc tìm ra các đầu cuối ngang hàng, không phải một đường hầm máy khách-máy chủ thông thường. Hãy đo cổng, rồi dùng bộ chuyển tiếp nếu đường trực tiếp thất bại.
Một luồng hỗ trợ kết thúc bằng phán quyết “NAT đối xứng, VPN sẽ không hoạt động ở đây”, rồi máy khách bị cài lại ba lần mà không có lý do. Nhãn này gây hại vì nó trả lời một câu hỏi mà không ai đặt ra. Máy khách kết nối ra ngoài tới một máy chủ cố định tạo ánh xạ ngay khi gửi gói đầu tiên, và phản hồi được cho phép quay lại theo những quy tắc mà gần như mọi mạng đều triển khai. Điều mà ánh xạ phụ thuộc điểm cuối thực sự làm phức tạp là hai đầu cuối ngang hàng cùng cố gắng đến với nhau một lúc, và đó là một phép thử khác.
Hai câu hỏi ẩn sau một nhãn
Câu hỏi thứ nhất là liệu một máy chủ sau mạng này có mở được phiên tới một địa chỉ công khai và cổng đã biết hay không. Với máy khách đường hầm thì đó là trường hợp bình thường, và câu trả lời gần như luôn là có. Bộ định tuyến ghi lại nguồn bên trong, cấp một cổng bên ngoài và cho phản hồi đi qua vì nó thuộc về một phiên bắt đầu từ bên trong.
Câu hỏi thứ hai là liệu hai máy chủ sau các mạng khác nhau có tìm được một đường chung và gửi cho nhau mà không cần máy chủ ở giữa hay không. Điều đó phụ thuộc vào cách mỗi mạng cấp các cổng bên ngoài đó, và đó là nơi duy nhất hành vi ánh xạ có ý nghĩa.
Trộn lẫn hai điều này tạo ra chẩn đoán sai kinh điển: một tính năng ngang hàng thất bại, ai đó chạy thử nghiệm loại NAT, thấy hạng tệ nhất và kết luận rằng đường hầm thông thường cũng không thể hoạt động. Đường hầm chưa bao giờ là thứ đã thất bại.
Ánh xạ và lọc là hai thuộc tính riêng
Thuật ngữ của RFC chính xác hơn các tên mà nhà cung cấp dùng, và đáng đưa vào phiếu vì nó giải quyết tranh cãi. Ánh xạ là cách cổng bên ngoài được cấp. Lọc là việc những gói đi vào nào được phép đi qua. Một mạng có thể nghiêm ngặt ở mặt này và thoáng ở mặt kia, và chính sự kết hợp đó là thứ mà một giao thức ngang hàng phải chịu đựng.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
Hàng thứ ba là điều mà hầu hết bộ định tuyến tiêu dùng và nhà mạng di động hiểu khi nói đối xứng. Lưu ý rằng nhãn chỉ mô tả việc cấp cổng. Một mạng có ánh xạ đó và lọc thoáng vẫn có thể nhận các gói đi vào cổng vừa được cấp, vì thế đục lỗ thành công ở một số mạng và thất bại ở những mạng khác.
Việc lọc có ba trường hợp riêng và tên riêng cho từng trường hợp. Viết “NAT đối xứng” vào phiếu khi muốn nói “lọc phụ thuộc địa chỉ và cổng” sẽ gửi người tiếp theo đến chương sai của tài liệu. Hai thứ hành xử khác nhau khi thử nghiệm, nên lỗi này không chỉ là học thuật.
Hãy đo ánh xạ thay vì đặt tên cho nó
Bạn có thể quan sát cổng được cấp trực tiếp từ phía máy chủ của bất kỳ dịch vụ UDP nào bạn kiểm soát. Bắt đầu bắt gói trên máy chủ công khai, gửi từ máy khách và đọc cổng nguồn mà gói đến:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820Dòng điểm cuối hữu ích nhất trong ba, vì WireGuard ghi lại địa chỉ và cổng cuối cùng nhận được từ mỗi đầu cuối ngang hàng. So sánh cổng đó với cổng mà máy khách nghĩ là mình đang dùng. Chúng sẽ khác nhau mỗi khi có bất kỳ chuyển dịch nào, và câu hỏi quan trọng là giá trị có giữ ổn định không.
Lặp lại quan sát với cổng đích thứ hai hoặc máy chủ thứ hai và so sánh lại. Nếu cổng bên ngoài thay đổi theo đích, ánh xạ phụ thuộc địa chỉ và cổng. Nếu nó giữ nguyên, mạng cho bạn một ánh xạ và việc khám phá có cơ hội.
Các công cụ dựa trên STUN báo cùng phân loại trong một bước, và dùng được khi mạng cho phép UDP đi ra tới một máy chủ STUN công khai. Khi không cho phép, phương pháp bắt gói ở trên vẫn hoạt động và không đòi hỏi gì ngoài một máy chủ bạn đã kiểm soát.
Chọn cách khắc phục phù hợp với sự cố
Nếu tính năng thất bại là ngang hàng, các câu trả lời được hỗ trợ là bộ chuyển tiếp, dịch vụ gặp gỡ mà cả hai đầu cuối đều đến được, hoặc một cấu trúc khác. TURN tồn tại chính vì điều này, và một sản phẩm kèm bộ chuyển tiếp riêng đang nói với bạn rằng nó mong một số mạng có tính đối nghịch.
Nếu tính năng thất bại là đường hầm thông thường, hành vi ánh xạ không phải vấn đề của bạn và không điều nào ở trên áp dụng. Kiểm tra rằng máy khách thực sự gửi, máy chủ thấy gói và phản hồi quay về. Chuỗi đó là ba quan sát và nó không đòi hỏi biết gì về hạng NAT của bộ định tuyến.
Điều không hiệu quả là rải các thay đổi cổng cục bộ cho đến khi có thứ gì đó kết nối. Đổi cổng nguồn của máy khách không thay đổi cách mạng cấp ánh xạ. Thành công tình cờ ở lần thử thứ năm là dương tính giả, và nó sẽ được trích dẫn như cách khắc phục trong nhiều tháng.
Ghi lại kiến trúc, không ghi phán quyết
Một ghi chú hữu ích nói rõ giao thức nào, phiên bắt đầu theo hướng nào, có bộ chuyển tiếp trên đường hay không, và quan sát được gì trên dây. “NAT đối xứng, không hoạt động” là vô dụng, vì nó vừa sai về đường hầm vừa không cho thông tin về đường của đầu cuối ngang hàng.
Bao gồm độ ổn định của cổng đã đo và hành vi lọc nếu bạn đã thử. Hai sự thật đó cho phép người khác dự đoán liệu một tính năng mới có hoạt động trên mạng đó hay không mà không lặp lại toàn bộ cuộc điều tra. Chúng cũng lâu cũ hơn một hạng mục của nhà cung cấp vốn mang nghĩa hơi khác trên mỗi trang trợ giúp.
Cuối cùng, hãy để sẵn thuật ngữ của RFC 4787 khi bạn viết điều này. Dùng thuật ngữ chính xác chỉ tốn một câu và ngăn người đọc tiếp theo lặp lại cùng chẩn đoán sai, và đó là toàn bộ mục đích của việc viết ghi chú.