Minecraft qua VPN: địa chỉ nào thuộc danh sách máy chủ?

Gõ điểm cuối VPN vào danh sách máy chủ Minecraft nghe có vẻ hợp lý và lần nào cũng thất bại, vì địa chỉ đó kết thúc đường hầm chứ không lưu trữ trò chơi. Người chơi đã kết nối cùng VPN đã có sẵn đường đến máy chủ của trò chơi, nên mục nhập phải nêu tên máy chủ và cổng mà trò chơi lắng nghe. Sửa đúng hai điều này thì phần còn lại của vấn đề chỉ là khả năng tiếp cận dịch vụ thông thường, một danh sách kiểm tra ngắn hơn nhiều so với vẻ ban đầu.

Hai địa chỉ, hai vai trò

Một địa chỉ là hạ tầng công cộng: điểm cuối vận chuyển mang các gói đã mã hóa giữa các peer. Cái còn lại là địa chỉ riêng của máy chạy máy chủ chuyên dụng. Chúng không thể thay thế cho nhau, và thay cái này bằng cái kia tạo ra kết nối bị từ chối hoặc hết thời gian chờ trông như sự cố tường lửa.

Với cổng mặc định, người chơi gõ 10.60.0.20:25565 và không gì khác. Trang tải máy chủ Java của Mojang ghi 25565 là mặc định, và phải tin nhà vận hành đã đổi cổng thay vì nghi ngờ dựa trên một hướng dẫn cũ.

Biến địa chỉ đó thành dịch vụ thật

Địa chỉ tiếp cận được là cần nhưng chưa đủ. Máy chủ chuyên dụng phải đang chạy, phải tương thích với phiên bản mà ứng dụng khách của người chơi chạy, và phải lắng nghe trên địa chỉ mà đường hầm có thể chuyển tới. Một tiến trình chỉ gắn với loopback không trở nên tiếp cận được chỉ vì ai đó đã thêm một địa chỉ khác vào máy.

Xác nhận trình lắng nghe trước khi chạm vào tường lửa:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Dòng đầu cho thấy tiến trình thực sự gắn với cái gì, còn dòng thứ hai cho thấy một peer có thể hoàn tất bắt tay TCP hay không. Khi ràng buộc là 127.0.0.1, không lượng cấu hình VPN nào thay đổi kết quả, và chi tiết duy nhất đó giải thích số lượng báo cáo «VPN hỏng» đáng ngạc nhiên.

Chính sách peer, tường lửa và tuyến quay về

Hai câu hỏi về quyền nằm trên trình lắng nghe. Cấu hình peer của VPN phải cho phép lưu lượng giữa hai peer, và tường lửa của máy chủ trò chơi phải chấp nhận cổng trò chơi từ peer đó. Giữ cả hai trong phạm vi dịch vụ trò chơi và các peer được ủy quyền thay vì tắt tường lửa của máy chủ, vốn đổi một quy tắc hai dòng lấy một vấn đề lớn hơn nhiều. Quy tắc hẹp cũng là phiên bản duy nhất của việc này vượt qua đánh giá bảo mật mà không cần một đoạn biện minh.

Sau đó hãy nhớ ping thành công chứng minh điều gì. Đến được cổng VPN, hoặc nhận phản hồi từ máy chủ trò chơi, chỉ chứng minh rằng ICMP đã đi qua tuyến. Kết nối trò chơi cần cổng cụ thể mở ở cả hai chiều, và tuyến quay về quan trọng như tuyến đi ra.

Khi máy chủ nằm sau cổng

Trong ví dụ trên, máy chủ trò chơi là một peer, điều này giữ kế hoạch địa chỉ đơn giản. Nếu máy chủ nằm trong một LAN sau cổng VPN, người chơi cần địa chỉ riêng có thể định tuyến của máy chủ, cổng cần được cấu hình chuyển tiếp cho LAN đó, và máy chủ trong LAN cần tuyến quay về phía ứng dụng khách trong đường hầm. Bỏ lỡ tuyến quay về thì bắt tay chết giữa đường, đây là sự cố khó hiểu nhất trong ba.

Đừng sao chép địa chỉ peer của ví dụ sang máy khác để bắt chước cấu trúc này. Địa chỉ trong ví dụ mô tả vai trò, và dùng lại một địa chỉ cho hai vai trò tạo ra sự chồng lấn mà định tuyến không thể giải quyết.

Khám phá, tài khoản và điều không nên đổi

Khám phá LAN tự động là tiện ích dựng trên các thông báo. Một VPN có định tuyến không cần mang các gói quảng bá đó, nên việc thiếu một mục trong danh sách LAN không nói gì về việc địa chỉ riêng rõ ràng có hoạt động hay không. Hãy gõ địa chỉ rồi đánh giá. Nếu kết nối được, khoảng trống khám phá là bất tiện về khả dụng chứ không phải lỗi, và có thể ghi nhận như vậy thay vì điều tra.

Giữ nguyên cả xác thực tài khoản thông thường và chính sách tiếp nhận của trò chơi. Một tuyến riêng hoạt động cho đường đi, không phải tư cách thành viên, và việc xáo trộn ưu tiên bộ tiếp nhận không thay thế việc xác định đích mà ứng dụng khách nên dùng.