VPN kết nối ở nhà nhưng hết thời gian trên Wi-Fi khách sạn

Laptop tham gia Wi-Fi ở nhà, ứng dụng khách kết nối trong ba giây, và cùng hồ sơ đó thất bại ở khách sạn một giờ sau. Giữa hai thời điểm không có gì được cập nhật. Việc cùng khách hàng ngồi trước mặt rà soát chuyện này chủ yếu là biết lỗi nào thuộc giai đoạn nào, vì thông tin hữu ích nằm trong mã mà ứng dụng khách in ra, không nằm ở việc nó thất bại. Làm bốn bước dưới đây theo thứ tự và bạn sẽ biết tên, gói, cổng hay chính sách đã từ chối bạn.

Đọc mã lỗi như một giai đoạn, không phải phán quyết

Ứng dụng khách đi qua ba cột mốc riêng biệt trước khi có đường hầm. Nó phân giải tên máy chủ, nhận câu trả lời từ một thứ gì đó trên mạng, và thương lượng một hiệp hội bảo mật. Mỗi cột mốc có thông báo thất bại riêng, và đặc biệt Windows hào phóng với các mã khác nhau khi bạn biết chúng thuộc giai đoạn nào.

Hai trong số các mã đó nghĩa là mạng không có lỗi. 789 nghĩa là các gói đang chảy và hai đầu không thống nhất về mã hóa, đây là vấn đề cấu hình bạn có thể sửa tại nhà. 868 nghĩa là không gói nào cần ra ngoài, nên thiết kế đường hầm không liên quan cho đến khi tên được phân giải. Xếp mã vào đúng giai đoạn tiết kiệm nhiều thời gian hơn mọi lần bắt gói, vì nó cho bạn biết bỏ qua bước nào trong ba bước tiếp theo.

Hãy thận trọng hợp lý nếu ứng dụng khách không phải Windows. Ứng dụng khách của bên thứ ba gộp phần lớn những thứ này thành "kết nối thất bại", đó là lý do hai bước tiếp theo hoàn toàn không dựa vào thông báo.

Kiểm tra tên trước khi đổ lỗi cho đường hầm

Mạng khách sạn và sân bay liên tục chặn DNS, và một trình phân giải trả lời bằng địa chỉ cổng thông tin tạo ra lỗi trông y hệt một máy chủ đã chết. Hãy so sánh điều trình phân giải cục bộ nói với điều một trình phân giải công cộng nói:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Nếu hai câu trả lời khác nhau, bạn đang bị chuyển hướng và phần chẩn đoán còn lại là vô ích cho đến khi điều đó được giải quyết. Đặc biệt địa chỉ cổng thông tin sẽ vui vẻ nhận kết nối TCP rồi đứng yên, đó là lý do nó có thể trông như bị tường lửa chặn khi bạn thử bằng trình duyệt.

Bây giờ hãy xác nhận địa chỉ bạn muốn đến là địa chỉ đang được dùng. Một số ứng dụng khách lưu bộ nhớ đệm kết quả phân giải trước đó suốt vòng đời hồ sơ, nên kết nối lại sau khi đổi DNS vẫn đi đến địa chỉ cũ. Đóng hẳn ứng dụng khách trước khi thử lại, thay vì nhấn ngắt kết nối rồi kết nối trong cùng cửa sổ.

Tìm ra gói bên ngoài nào biến mất

Đường hầm có một luồng bên ngoài thuộc hoàn toàn về đường đi giữa bạn và máy chủ, và chính luồng đó bị các hộp trung gian phân loại và bỏ. Hãy bắt nó trên ứng dụng khách, rồi so sánh một mạng đang hoạt động với mạng thất bại. Trên Windows, tính năng bắt gói tích hợp là đủ cho lần xem đầu:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Điều bạn muốn thấy là các gói của bạn có ra ngoài không, và có gì quay lại không. Gói ra mà không có gì trả về nghĩa là đường đi hoặc đầu xa đang bỏ chúng; nếu không có gì ra ngoài, ứng dụng khách chưa bao giờ đến bước gửi, điều này chỉ ngược về phân giải tên hoặc chính sách tường lửa cục bộ.

Lặp lại cùng bài kiểm tra trên điểm phát sóng điện thoại. Đây là phép so sánh nhiều thông tin nhất bạn có, vì nó loại mọi hộp trong khách sạn khỏi đường đi trong khi laptop, ứng dụng khách và thông tin đăng nhập giữ nguyên. Nếu đường hầm dựng lên trên điểm phát sóng, hãy thôi nhìn máy chủ. Nếu nó cũng thất bại ở đó, bạn có vấn đề về ứng dụng khách hoặc tài khoản mà mạng chưa bao giờ gây ra.

Đổi một giao thức vận chuyển và thử lại

Khi biết luồng bên ngoài bị bỏ, câu hỏi thực tế là mạng cho phép luồng nào. Hầu hết mạng bị hạn chế cho phép TCP 443 ra ngoài vì nếu không chúng không thể hoạt động, nên chuyển bộ lắng nghe đến đó là câu trả lời thường gặp. Trên OpenVPN đó là một công tắc phía ứng dụng khách cho đến khi máy chủ được thay đổi:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Ứng dụng khách IPsec có một công tắc tương đương trong bảng cài đặt của riêng chúng, thường được mô tả là IPsec trên TCP hoặc xuyên NAT. Thay đổi nó cũng là một chẩn đoán: nếu đường hầm dựng lên trên TCP và chết trên UDP, bạn đã chứng minh mạng lọc UDP, và bạn cũng đã tìm ra cài đặt bạn sẽ cần mỗi lần đến thăm địa điểm đó.

Hãy chống lại cám dỗ tắt các tính năng của router ngay lần đầu. Tắt kiểm tra trạng thái hoặc bảo vệ chống lụt trên mạng khách sạn vốn không có sẵn cho bạn, và trên thiết bị của bạn nó đánh đổi một sự bảo vệ thực sự lấy một laptop. Ghi lại cài đặt nào đã thay đổi kết quả, rồi đặt lại và tìm một giao thức vận chuyển mà mạng đã cho phép.

Xác minh cùng hồ sơ trên mạng thứ hai

Trước khi đóng phiếu, hãy chứng minh thay đổi sống sót sau khi rời tòa nhà. Kết nối lại trên mạng ban đầu với cài đặt ban đầu, bắt ba mươi giây đầu, và xác nhận ứng dụng khách đạt cùng trạng thái như trên điểm phát sóng:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Sự phân biệt mà lệnh cuối phơi ra đáng để giữ: hồ sơ có thể báo cáo một đường hầm đã kết nối trong khi định tuyến bên trong sai, và điều đó tạo ra "VPN đang bật nhưng không có gì hoạt động", đây là một bài viết khác. Nếu loại đường hầm thay đổi sau khi bạn sửa, hồ sơ không phải là cái bạn đã kiểm tra.

Sau đó viết phát hiện ở nơi người tiếp theo sẽ nhìn. "Hồ sơ công ty cần TCP 443 tại địa điểm này; UDP 500 bị khách sạn lọc" là câu mà đồng nghiệp có thể hành động. "VPN không ổn định ở khách sạn" thì không, và nó bảo đảm rằng đúng một giờ đó sẽ lại bị tiêu vào tháng sau.