SoftEther sau NAT: truyền trực tiếp hay chuyển tiếp VPN Azure?

Máy chủ SoftEther của bạn nằm sau bộ định tuyến của nhà cung cấp mà bạn không thể thay đổi, và máy khách vẫn kết nối được, nên bạn cho rằng một bộ chuyển tiếp đang chở mọi thứ. Điều đó có đúng hay không phụ thuộc vào cơ chế nào đã làm việc: một tên DNS, một đường UDP được phối hợp hay một đường hầm đi ra tới bộ chuyển tiếp. Cả ba đều có thể tạo ra máy khách đã kết nối, và chúng hỏng trong các điều kiện khác nhau. Hãy quyết định con đường bạn mua trước khi đụng tới người dùng hoặc hub.

Ba cơ chế, ba lời hứa khác nhau

DNS động là việc đặt tên. Nó giữ tên máy chủ trỏ tới một địa chỉ thay đổi để người ta thôi đuổi theo con số, và không làm gì khác. Truyền qua NAT gốc là phối hợp: hai điểm cuối SoftEther trao đổi thông tin và cố mở một đường UDP dùng được xuyên qua các thiết bị dịch địa chỉ giữa chúng. VPN Azure là một bộ chuyển tiếp: máy chủ quay số ra dịch vụ, và máy khách đến qua một tên máy chủ trên hạ tầng của bộ chuyển tiếp.

Ba thứ bổ sung cho nhau chứ không phải các phiên bản của một tính năng. Một triển khai có thể dùng việc đặt tên trong khi kết nối của nó thực sự phụ thuộc vào truyền qua NAT hoặc vào bộ chuyển tiếp.

Quyết định từ máy khách và mạng

Lựa chọn bắt đầu từ máy khách, vì truyền qua NAT chỉ tồn tại trong cơ chế kết nối gốc của SoftEther. OpenVPN, L2TP/IPsec và các bộ lắng nghe SSTP trên cùng máy chủ không thừa hưởng nó, dù chúng chia sẻ một máy chủ. Hãy xem người dùng sẽ chạy gì, rồi mạng cho phép gì. Một mạng doanh nghiệp chỉ cho phép TCP 443 đẩy bạn về bộ chuyển tiếp trên cổng đó, trong khi mạng cho qua các cổng UDP mà truyền qua NAT cần có thể thử một đường trực tiếp; hãy xác nhận cả hai với chính sách ra thực tế.

Một bộ lắng nghe truy cập được thủ công vẫn là thiết kế hợp lệ khi quản trị viên có thể công bố một bộ, nhưng đó là dự án riêng với việc đánh địa chỉ và tường lửa của nó.

Xác nhận phiên đã chọn phương thức truyền nào

Trạng thái kết nối là nguồn trung thực duy nhất về con đường đang dùng. Hãy đọc nó trên máy chủ, và phân giải tên máy chủ mà máy khách nhận được.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList cho biết những phiên nào đang kết nối, và SessionGet trên một trong số đó báo cáo loại kết nối, kể cả việc phiên có đến qua bộ chuyển tiếp hay không. Một bản ghi phân giải tới hạ tầng của bộ chuyển tiếp cho bạn biết phiên đi qua bên thứ ba, điều bạn có thể xác nhận bằng cách chặn tuyến đó trong một bài kiểm tra. Với máy khách gốc, tăng tốc UDP có thể đưa đường dữ liệu ra xa đường điều khiển, nên một quan sát không mô tả toàn bộ phiên. Một tên DNS động cũ sau khi đổi địa chỉ, và một bộ chuyển tiếp trả lời trong khi thiếu tuyến tới backend, là hai chế độ hỏng đáng kiểm tra riêng. Hãy ghi lại điều bạn đo được, không phải điều thiết kế định làm.

Lập kế hoạch cho những gì con đường đã chọn phụ thuộc vào

Mỗi con đường mang một phụ thuộc. Truyền trực tiếp có thể thay đổi sau khi chuyển mạng hoặc có thiết bị dịch địa chỉ mới, trong khi phiên chuyển tiếp hỏng khi dịch vụ hoặc cổng truy cập được của nó hỏng. Kết nối lại từ mạng khác và xác nhận danh tính máy chủ mà máy khách đã kiểm tra, giữ con đường từng hoạt động trong cùng bài kiểm tra. Sau đó kiểm tra tài nguyên riêng sau VPN, vì phân quyền, tư cách thành viên hub, cấp phát địa chỉ và tuyến quay về vẫn là trách nhiệm của bạn trong mọi trường hợp.

Ghi lại tên máy chủ, giao thức, cài đặt tính năng và phương thức truyền đã quan sát. Chính bản ghi bốn phần đó giúp người tiếp theo tái tạo một kết nối hoạt động.