SoftEther VPN Azure: một đường truyền qua relay, không phải cổng mở

Máy chủ của bạn nằm sau một router mà bạn không thể cấu hình, nên kế hoạch hiển nhiên là chuyển tiếp một cổng không khả dụng. VPN Azure tồn tại đúng cho tình huống đó, và nó giải quyết bằng cách đảo ngược hướng của kết nối đầu tiên: máy chủ gọi ra ngoài tới một relay, và máy khách đến relay thay vì đến máy chủ. Hiểu sự đảo ngược đó giải thích cả những gì dịch vụ sửa và mọi giới hạn bạn sẽ gặp sau này.

Điều gì thay đổi trên đường truyền

Với một trình lắng nghe thông thường, máy khách mở kết nối TCP tới một địa chỉ công khai mà router của bạn chuyển tiếp đến máy chủ. Với relay, máy chủ duy trì một kết nối đi ra tới hạ tầng relay, và relay chấp nhận kết nối của máy khách rồi chuyển tải của chúng đến máy chủ đang chờ. Không có cổng vào nào được mở, không cần địa chỉ tĩnh, và router vẫn không bị đụng tới. Từ góc nhìn của tường lửa, máy chủ là một máy khách đi ra bình thường, đó là lý do các mạng hạn chế cho phép nó.

Relay gán một tên trên miền riêng của nó cho máy chủ đó, và máy khách được cấu hình để kết nối ở đó.

Tên đó thuộc về dịch vụ relay, vốn không phải Microsoft Azure VPN Gateway dù cả hai đều được gọi là Azure gì đó. Coi chúng như có thể thay thế cho nhau tạo ra một cấu hình không thể hoạt động.

Những giao thức nào đi qua relay

Relay mang giao thức SoftEther, và dự án ghi nhận SSTP như một tùy chọn máy khách, điều này hữu ích vì Windows có sẵn máy khách SSTP. Tuy nhiên nó không trở thành vật mang chung cho mọi trình lắng nghe trên máy chủ: trình lắng nghe OpenVPN, bộ trả lời IPsec và dịch vụ L2TP mỗi thứ cần điểm cuối có thể tiếp cận riêng, và không thứ nào được mang qua relay chỉ vì máy chủ SoftEther đã kết nối.

Vì vậy hồ sơ máy khách trỏ đến tên relay thay vì địa chỉ máy chủ, và một hồ sơ hiện có được tạo cho kết nối trực tiếp sẽ không hoạt động nếu không thay đổi. Hãy xem danh sách máy khách được hỗ trợ cho phiên bản bạn chạy trước khi thiết kế quanh một giao thức mà relay không mang.

Điều relay không làm cho bạn

Relay là một vật mang. Nó không tạo người dùng, hub ảo, chính sách truy cập hay tuyến đường, và nó không biết gì về các mạng riêng phía sau máy chủ của bạn. Nếu máy khách từ xa phải đến một mạng con LAN, máy chủ vẫn cần cấu hình cầu nối hoặc định tuyến, đường quay về và chính sách tường lửa làm cho điều đó hoạt động. Các kế hoạch địa chỉ chồng lấn ở hai đầu cũng vô hình với relay và vẫn là vấn đề của bạn cần giải quyết.

Các thiết lập bảo mật được hỗ trợ cũng là của bạn để chọn. Tài liệu dự án có các ví dụ về nền tảng cũ hơn, và việc sao chép thiết lập mã hóa hoặc chứng chỉ cũ từ một ảnh chụp màn hình cũ là một cách tốt để xây một đường hầm mà không ai có thể kiểm toán. Hãy dùng hướng dẫn hiện hành cho phiên bản bạn chạy.

Việc xác thực chứng chỉ và xác thực người dùng vẫn là trách nhiệm của máy chủ, và relay không bao giờ thay thế một trong hai.

Vận hành nó như một phụ thuộc

Tính sẵn sàng giờ đây bao gồm một bên thứ ba. Khi relay không thể tiếp cận, máy khách không thể kết nối bất kể máy chủ của bạn khỏe đến đâu, và sự cố trông giống vấn đề của máy khách từ bên ngoài. Hãy giám sát đường truyền qua relay tách biệt với sức khỏe của máy chủ, và giữ một phương án dự phòng được ghi lại như một trình lắng nghe trực tiếp trên địa chỉ khác cho ngày nó quan trọng.

Độ trễ theo địa lý của relay chứ không theo sự gần gũi của người dùng bạn, điều đáng đo trước khi hứa hẹn hiệu năng tương tác qua nó.

Xác minh danh tính máy chủ rồi đến một đường ứng dụng thật, không chỉ một biểu ngữ kết nối thành công, và kiểm tra xem tài nguyên bạn cần có tiếp cận được qua họ địa chỉ mà relay mang hay không. Ghi lại tên relay, giao thức đã dùng và phương án dự phòng, vì ba dữ kiện đó trả lời phần lớn câu hỏi tương lai về liên kết này.