Hai điểm cuối sau NAT của nhà mạng và một router văn phòng bị khóa không để lại cổng vào nào để chuyển tiếp, và phản xạ là vẫn xin một cổng. Câu hỏi tốt hơn là bên nào có thể gọi ra ngoài và dịch vụ nào có thể tiếp cận được phép mang lưu lượng. Bốn thiết kế trả lời câu hỏi đó theo cách khác nhau, và chúng thất bại theo cách khác nhau khi một đường bị chặn. Chọn giữa chúng là so sánh các bảo đảm, không phải tên giao thức.

Bốn thiết kế, bốn lời hứa khác nhau

Bảng dưới đây là bản rút gọn. Đọc cột giữa như lời hứa bạn có thể kiểm tra, và cột phải như lời hứa mà không ai đưa ra.

DesignWho initiatesPromise you getPromise you do not get
Routed VPN hubBoth ends, outbound to the hubA routed path to permitted prefixesAccess to services no policy allows
Peer traversal with ICEBoth peers to a rendezvous serviceA path tested between the two peersA direct path through every NAT
TURN relayClient outbound to a relayTransport that survives symmetric NATPeer discovery or a usable directory
Application brokerWorkstation outbound to a brokerOne audited application sessionSubnet-wide reachability

Hàng nào áp dụng phụ thuộc vào công việc chứ không phải sở thích. Một phiên máy tính để bàn từ xa, một shell quản trị và quyền truy cập vào toàn bộ một mạng con riêng là ba yêu cầu không cần cùng một điểm vào, kể cả khi chúng tình cờ liên quan đến cùng một máy.

Hub thay đổi ai gọi ra ngoài, không phải điều gì được phép

Trong thiết kế hub có định tuyến, máy tính xách tay từ xa và máy trạm, hoặc cổng của site phía trước nó, mỗi bên mở một đường hầm đi ra tới dịch vụ mà cả hai đều tiếp cận được. Không có gì chấp nhận kết nối không được yêu cầu tại router của máy trạm, và đó chính là lý do thiết kế này vượt qua NAT và vẫn hoạt động khi site không có địa chỉ tĩnh. Sau đó hub định tuyến lưu lượng giữa hai địa chỉ bên trong theo chính sách của nó.

Cái giá là hub phải tồn tại, phải tiếp cận được từ hai phía và phải có người vận hành. Bộ lọc ra phải cho phép vận chuyển, và một mạng chặn nó sẽ đánh bại thiết kế dù không cần chuyển tiếp cổng.

Phần tinh tế là khả năng tiếp cận và ủy quyền là hai quyết định riêng được đưa ra ở những nơi khác nhau. Một tuyến vào một tiền tố không nói gì về việc danh tính được dùng dịch vụ nào trên máy trạm, và một quy tắc tường lửa cho phép đường hầm không nói gì về việc tài khoản có đăng nhập được hay không. Cấu hình cả hai, kiểm tra cả hai, và giữ quyết định ủy quyền ở hệ thống sở hữu tài nguyên chứ không phải ở bảng định tuyến.

Việc xuyên qua chỉ hoạt động khi cả hai ngăn xếp triển khai nó

Việc xuyên qua giữa các máy ngang hàng là khả năng của một hệ thống cụ thể, không phải một cài đặt cải thiện VPN. Interactive Connectivity Establishment thu thập nhiều địa chỉ ứng viên và kiểm tra các cặp cho đến khi một cặp hoạt động: ứng viên máy chủ trên các giao diện cục bộ, ứng viên phản xạ máy chủ được xây từ những gì NAT tiết lộ, và ứng viên được chuyển tiếp cấp phát trên một relay. Chỉ một địa chỉ riêng không phải là đường, vì phía bên kia không thể định tuyến tới đó.

Trường hợp chuyển tiếp đáng được hiểu trước khi gạt bỏ. RFC 8656 mô tả TURN như một giao thức trong đó máy khách yêu cầu máy chủ cấp một địa chỉ vận chuyển được chuyển tiếp và máy chủ chuyển tiếp lưu lượng giữa máy khách đó và các máy ngang hàng của nó. Vì vậy relay mang dữ liệu, điều này khác về bản chất so với một thư mục chỉ giúp các điểm cuối gặp nhau. Trao đổi địa chỉ relay với phía bên kia là một bước phối hợp mà ứng dụng phải thực hiện.

Điều bạn không thể hứa là một đường trực tiếp. NAT đối xứng và một số tường lửa doanh nghiệp đánh bại việc đục lỗ, và khi điều đó xảy ra hệ thống hoặc quay về relay hoặc thất bại. Bạn cũng không thể kết luận rằng hai điểm cuối đã dịch sẽ không bao giờ nói chuyện được; một ngăn xếp được hỗ trợ có dự phòng relay tồn tại chính vì chúng thường có thể. Hãy quyết định khả năng sẵn sàng hay tính trực tiếp quan trọng hơn, rồi kiểm tra xem triển khai thực tế đã chọn đường nào thay vì giả định trường hợp thuận lợi.

Broker hẹp hơn một mạng

Khi yêu cầu là một ứng dụng duy nhất, broker ứng dụng hoặc kết nối ngược do máy trạm khởi tạo có thể là câu trả lời nhỏ nhất. Máy trạm gọi ra ngoài tới broker, broker xác thực người dùng từ xa, và chỉ phiên ứng dụng đó được mang theo. Không có tuyến nào tới mạng con của máy trạm được tạo, nên việc phiên từ xa bị xâm phạm không thừa hưởng đường tới mọi thiết bị bên cạnh.

Sự hẹp đó có giá: mỗi ứng dụng thêm cần tích hợp riêng, và bất cứ điều gì ứng dụng giả định về mạng cục bộ, như chia sẻ tệp mà nó mở trên một máy chủ gần đó, có thể không tiếp cận được. Broker cũng tập trung chính sách và ghi nhật ký ở một nơi, điều này hữu ích cho đến khi nơi đó trở thành sự cố.

So sánh ranh giới tin cậy, rồi kiểm tra đường đi

Một hub kết thúc đường hầm có thể đọc lưu lượng mà nó định tuyến. Một relay có thể mang một trao đổi được bảo vệ độc lập khi ứng dụng mã hóa đầu cuối, và broker thường kết thúc phiên mà nó trình bày. Hãy xác định nơi bảo vệ thực sự kết thúc trước khi kết luận hai thiết kế tương đương vì cả hai đều được mã hóa.

Sau đó kiểm tra máy trạm thực sự tiếp cận được gì khi đi ra ngoài, vì mọi thiết kế ở trên phụ thuộc vào điều đó. Chạy lệnh này trên máy trạm, thay tên máy chủ mà bạn định dùng.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Chỉ chấp nhận thiết kế sau khi thao tác từ xa dự kiến thành công dưới danh tính được phép, một danh tính không được phê duyệt bị từ chối, và hành vi khi đường trực tiếp hoặc đường chuyển tiếp không khả dụng được biết và ghi lại. Bao gồm việc kết nối lại và bối cảnh khởi động bình thường của máy trạm, vì một phiên bắt đầu trong văn phòng qua LAN không kiểm tra bất cứ điều gì mà truy cập từ xa phụ thuộc vào.

Bài viết liên quan