Một máy khách VPN chuyển vùng có thể lưu trữ dịch vụ cho văn phòng không?

Laptop văn phòng của bạn có thể quay số từ nhà và vẫn cung cấp thứ mà văn phòng cần, nhưng chỉ khi ba quyết định riêng biệt khớp nhau. Đường hầm là vận chuyển, địa chỉ bên trong là đích, và chính sách quyết định ai được gõ cửa. Coi bất kỳ điều nào trong số đó là toàn bộ câu trả lời sẽ tạo ra lời phàn nàn quen thuộc: máy chủ trả lời ping nhưng ứng dụng không bao giờ kết nối. Vai trò không giống nhau, và khác biệt nằm chính xác ở nơi công việc thiết kế diễn ra.

Hướng quay số không nói gì về hướng dịch vụ

Khi một máy khách khởi động đường hầm, nó mở một đường mà cả hai hướng có thể dùng sau khi đường đó tồn tại. Việc một kết nối mới có được đi vào từ trung tâm về phía máy khách đó hay không là câu hỏi về chính sách cổng, không phải thuộc tính của người đã quay số. Ví dụ, trên một trung tâm OpenVPN có định tuyến, máy chủ cần tuyến đến địa chỉ bên trong của máy khách và chuyển tiếp cho phép quan hệ ngang hàng.

Hãy hình dung một hệ thống kiểm kê thăm dò một tác nhân trên các laptop chuyển vùng, hoặc một lập trình viên cần API thử nghiệm từ máy trạm ở nhà. Cả hai đều muốn phía văn phòng bắt đầu cuộc trò chuyện, điều này ngược với mô hình máy khách-tới-máy chủ thông thường.

Các sản phẩm truy cập từ xa được lưu trữ khác nhau ở điểm này, và sự khác biệt đó không phải lỗi. Một số VPN dịch vụ được quản lý cố ý chặn các kết nối không được yêu cầu về phía máy khách đã kết nối vì mô hình của chúng là máy khách-tới-tài nguyên, không phải tài nguyên-tới-máy khách. Hãy đọc kiến trúc được ghi chép của sản phẩm trước khi hứa với đồng nghiệp rằng laptop của họ có thể hoạt động như máy chủ.

Theo dõi đường quay lại trước khi mở cổng

Đường đi có ba phần: tuyến trên cổng trỏ đến địa chỉ bên trong của máy khách, chính sách cho phép người gọi cụ thể, và dịch vụ lắng nghe trên mục tiêu. Mỗi phần hỏng theo cách khác nhau, vì thế «VPN đang bật» gần như không nói gì.

Tin tốt là đường bên trong không cần chuyển tiếp cổng trên router tại nhà của máy khách. Đó chính là ý nghĩa của việc công bố dịch vụ trên địa chỉ đường hầm thay vì địa chỉ WAN tại nhà, nơi mức độ phơi bày và các quy tắc NAT sẽ hoàn toàn khác. Router tại nhà cũng có thể từ chối hairpin một kết nối đến từ văn phòng, nên tuyến WAN thất bại vì lý do không liên quan đến VPN của bạn. Giữ lưu lượng bên trong đường hầm tránh được cả hai vấn đề cùng lúc.

Kiểm tra cả phía mục tiêu. Một dịch vụ chỉ gắn với 127.0.0.1 không thể chấp nhận kết nối đến trên giao diện đường hầm, dù các tuyến của cổng có chính xác đến đâu. Một quy tắc tường lửa của máy chủ chỉ cho phép cổng từ mạng con cục bộ cũng sẽ bỏ lưu lượng văn phòng, và quy tắc đó độc lập với chính sách VPN bên trên.

Tên và địa chỉ là những quyết định thiết kế

Địa chỉ bên trong đường hầm không tự động là tên. Một bản ghi DNS riêng mà bạn kiểm soát rõ ràng hơn việc hy vọng một giao thức khám phá sẽ vượt qua đường hầm, vì phân giải tên bằng multicast liên kết cục bộ vẫn ở lại phân đoạn cục bộ và không trở thành DNS giữa các mạng con.

Độ ổn định của địa chỉ cũng quan trọng không kém. Nếu máy khách VPN lấy từ một nhóm có thời hạn thuê ngắn, địa chỉ bên trong của laptop thay đổi giữa các phiên và mọi dấu trang, phạm vi tường lửa và kiểm tra giám sát được xây trên đó lặng lẽ hỏng. Hãy dùng đặt trước hoặc một đường cập nhật động được ghi chép.

Hãy thống nhất tên với người sở hữu danh tính VPN, để bản ghi, việc cấp địa chỉ và chính sách truy cập thay đổi cùng nhau thay vì trong ba phiếu riêng lẻ.

Thử dịch vụ, không phải tư cách thành viên

Từ mục tiêu, xác nhận cái gì và trên địa chỉ nào đang lắng nghe, rồi xác nhận góc nhìn của cổng về đường quay lại:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Bây giờ hãy thử từ phía văn phòng bằng một yêu cầu thật thay vì tiếng dội. Một curl thành công với dịch vụ chứng minh tuyến, chính sách và trình lắng nghe cùng lúc, trong khi ping thành công chỉ chứng minh ICMP được cho phép. Nếu yêu cầu thất bại, hãy lùi lại qua ba phần thay vì mở rộng tường lửa và hy vọng.

Tính sẵn sàng thuộc cùng cuộc trò chuyện đó. Laptop ngủ, chuyển vùng giữa các mạng và ngắt kết nối vào cuối ngày. Một dịch vụ phải trả lời vào bất kỳ giờ nào thuộc về máy chủ luôn bật, còn dịch vụ nỗ lực tối đa có thể ở lại trên máy khách với giới hạn đó được ghi lại.

Hãy công bố tài nguyên một cách có chủ đích, với tên, danh sách người gọi được phép và chủ sở hữu, và thiết bị từ xa trở thành dịch vụ được hỗ trợ thay vì một máy chủ tình cờ.