Vì sao một hồ sơ OpenVPN chạy được ở nhà nhưng thất bại trong khách sạn

Wi-Fi văn phòng và một phòng khách sạn có thể cho cùng một laptop hai mạng rất khác nhau, và hồ sơ ở giữa không biết gì về điều đó. Thứ chạy được ở nhà giả định có một đường lên dễ dãi, phân giải tên hoạt động và một mạng con cục bộ không đụng độ với bất cứ thứ gì đường hầm mang theo. Mỗi giả định trong số này có thể thất bại riêng rẽ.

Cách hữu ích để gỡ lỗi việc này là coi mạng như bốn sự thật riêng biệt, rồi kiểm tra chúng theo thứ tự. Đoán về hồ sơ trước thường tạo ra một thay đổi không sửa được gì và che khuất bằng chứng.

Bốn sự thật về mạng thay đổi giữa các địa điểm

Sự thật đầu tiên là mạng cục bộ có cho bạn ra ngoài hay không. Một cổng đăng nhập đưa thiết bị vào trang đăng nhập và chặn mọi thứ khác cho đến khi trang đó hoàn tất, nghĩa là đường hầm không thể bắt đầu, dù hồ sơ có đúng đến đâu.

Sự thật thứ hai là phân giải tên. Một cổng chặn DNS sẽ trả lời mọi truy vấn bằng địa chỉ của chính nó, nên tên máy chủ VPN được phân giải về cổng và ứng dụng khách cố dựng một đường hầm tới một trang web.

Sự thật thứ ba là lọc giao vận. Các mạng chỉ muốn cho phép duyệt web sẽ chuyển TCP 443 tới các đích tùy ý và bỏ gần như mọi thứ khác, kể cả UDP.

Sự thật thứ tư là định địa chỉ. Mạng con cục bộ có thể chồng lấn với một mạng phía sau đường hầm, hoặc đường lên có thể không cung cấp bất kỳ lộ trình IPv4 nào dùng được.

Phân giải tên và cổng đăng nhập

Thay tên máy chủ trong hồ sơ bằng địa chỉ số của máy chủ rồi thử lại. Nếu IP kết nối được mà tên thì không, lỗi nằm ở phân giải tên, và bản thân hồ sơ vẫn ổn.

Mở trình duyệt và thử một trang HTTP thông thường trước khi chạm vào VPN. Chuyển hướng tới trang đăng nhập nghĩa là cổng vẫn đang chờ; hãy hoàn tất nó, rồi kết nối lại. Nhiều khách sạn cũng cho phiên hết hạn sau vài giờ, trông giống như mất kết nối giữa ngày chứ không phải lỗi đăng nhập.

Nếu địa chỉ số cũng thất bại, phân giải tên không phải lời giải thích, nên chuyển sang giao vận. Giữ lại địa chỉ bạn đã thử, vì nó cho lần kiểm tra tiếp theo biết liệu các gói tin có rời khỏi máy hay không.

Lọc giao vận: UDP trước, TCP 443 làm dự phòng

Một luồng OpenVPN trên UDP 1194 không giống bất cứ thứ gì tường lửa khách sạn nhận ra, nên nó bị bỏ đi mà không có lỗi. Ứng dụng khách thử lại cho đến khi hết thời gian chờ, và người dùng thấy một kết nối không bao giờ được thiết lập thay vì một lời từ chối. Những tường lửa hành xử như vậy hiếm khi ghi lại việc bỏ gói ở nơi bạn có thể thấy. Chính sự vắng mặt của lời từ chối là manh mối.

TCP 443 là dự phòng đáng tin cậy vì mạng không thể phân biệt nó với HTTPS thông thường. Dùng hồ sơ TCP của nhà cung cấp khi có, vì máy chủ cũng phải lắng nghe trên giao vận và cổng đó; chỉ đổi phía khách sẽ tạo ra một loại lỗi khác. Nếu không có hồ sơ TCP, hãy hỏi nhà cung cấp thay vì tự nghĩ ra một cái bằng cách sửa cổng. Phía máy chủ cũng phải đồng ý, và sự không khớp lại trông như lỗi tường lửa.

Hãy chờ một cái giá về hiệu năng. TCP trong TCP khuếch đại việc truyền lại trên một liên kết có mất mát, nên một đường hầm TCP chạy được vẫn có thể chậm trên mạng khách sạn đông đúc. Đó là đánh đổi để tới được, không phải khuyết điểm cần đuổi theo.

Xung đột địa chỉ và đường lên không có IPv4

Một đường hầm có thể được thiết lập mà vẫn không mang gì. Khi LAN cục bộ và một mạng từ xa dùng chung tiền tố như 192.168.1.0/24, ứng dụng khách coi máy chủ từ xa là kết nối trực tiếp và gửi gói tới liên kết cục bộ thay vì đường hầm. Triệu chứng là một kết nối thành công với một mạng con không tới được, dễ bị đọc nhầm thành lỗi định tuyến phía máy chủ.

Cách sửa lâu dài là chuyển LAN từ xa sang một dải riêng ít gặp. Chọn một dải không ai dùng ở nhà, như 10.42.0.0/24, ngăn được vấn đề cho mọi địa điểm sau này thay vì chỉ một. Cách lách cục bộ là tránh khách sạn, điểm phát sóng hoặc bộ định tuyến đó, mà đó không phải là sửa chữa gì cả.

Các đường lên di động thêm hai biến thể. NAT cấp nhà mạng nghĩa là các kết nối vào không tới được, điều này quan trọng nếu bạn tự lưu trữ máy chủ nhưng không với một ứng dụng khách đi ra. Một APN được cấu hình chỉ IPv6 với chuyển đổi NAT64 có thể làm ứng dụng khách đòi lộ trình IPv4 thật thất bại, và cách chữa thông thường là đổi giao thức APN sang IPv4 hoặc ngăn xếp kép.

Triệu chứng sau khi đường hầm đã lên

Một đường hầm kết nối rồi im lặng thường là vấn đề keepalive hoặc MTU, không phải cổng bị chặn. Một kết nối rơi sau số phút cố định chỉ vào bộ hẹn giờ keepalive hoặc đàm phán lại. Đặt ứng dụng khách dò đối tác của nó và khởi động lại khi phản hồi ngừng, và thử MTU đường hầm nhỏ hơn nếu ping đi qua trong khi truyền lớn bị kẹt.

Trước khi yêu cầu trợ giúp, hãy ghi ba thứ: địa chỉ bạn đã thử và liệu nó có trả lời, giao vận và cổng bạn đã dùng, và mạng con cục bộ của mạng đã hỏng. Cùng nhau chúng tách phân giải tên khỏi lọc giao vận và khỏi xung đột địa chỉ, và đó là những nguyên nhân sống sót khi tiếp xúc với bằng chứng.