VPN đã kết nối nhưng không có internet? Kiểm tra bốn lớp

Ứng dụng báo đã kết nối, trình duyệt quay vòng, và mọi trang đều kết thúc bằng hết thời gian chờ. Sự kết hợp đó là bình thường và không mâu thuẫn: đã kết nối nghĩa là đường hầm đã thương lượng, và không hơn. Phân giải tên, định tuyến và lối ra của chính máy chủ đều thất bại theo cách riêng, và mỗi thứ có người phụ trách khác nhau. Đi qua từng lớp theo thứ tự và dừng ở lớp đầu tiên thất bại.

Bắt đầu từ mạng bạn đã đi qua

Ngắt đường hầm bằng chính nút ngắt kết nối của ứng dụng, sau đó thử hai trang HTTPS không liên quan nếu chính sách cho phép. Để công việc nhạy cảm đóng trong suốt lần thử đó. Nếu truy cập thông thường cũng thất bại, VPN không phải nghi phạm đầu tiên.

Nhìn vào liên kết Wi-Fi, bộ định tuyến và bất kỳ trang cổng nào yêu cầu đăng nhập trước khi chạm vào đường hầm. Kill switch có thể chặn lưu lượng khi ngắt kết nối theo thiết kế, nên hãy làm theo quy trình thử nghiệm đã ghi lại thay vì kết luận mạng đã chết. Một mạng tin cậy khác là phép so sánh hữu ích, và lối ra VPN mới sẽ không hoàn tất đăng nhập khách sạn đã hết hạn. Nếu mạng mở hoạt động còn đường hầm không, mạng đã được minh oan và lớp tiếp theo là của bạn.

Xác định xem lỗi có phải do phân giải tên

Ghi lại nội dung lỗi, vì lỗi phân giải, hết thời gian chờ và cảnh báo chứng chỉ chỉ về những nơi khác nhau. Mẫu cần bắt sớm là một tên máy chủ chưa từng truy cập thất bại trong khi ứng dụng có phiên mở vẫn tiếp tục. Mẫu đó nói về các truy vấn mới, không phải việc đường hầm có mang gói tin hay không. Một truy vấn cho thấy bộ phân giải trả về gì, và chạy mất một giây. Thử thêm tên thứ hai, để một câu trả lời đã lưu đệm hay một bản ghi hỏng không quyết định chẩn đoán.

nslookup example.com

Một IP tùy ý trong thanh địa chỉ HTTPS không phải phép thử DNS, vì chứng chỉ và máy chủ ảo thường phụ thuộc vào tên. Tên nội bộ có thể cần bộ phân giải của tổ chức thay vì bộ thay thế công cộng, và trình duyệt có bộ phân giải bảo mật riêng có thể trả lời khác truy vấn của hệ điều hành. Khi hai bên khác nhau, bộ phân giải của trình duyệt là thứ người dùng trải nghiệm, và sự khác biệt đó thuộc về phiếu sự cố.

Đường hầm đầy đủ hay chỉ các mạng con của công ty

Một số hồ sơ chỉ tồn tại để đến một vài mạng con của công ty; số khác được xây để mang mọi thứ và cần một lối ra hoạt động phía sau. Đọc mục đích đã ghi lại trước khi cho rằng đèn báo bao phủ mọi ứng dụng và mọi họ địa chỉ. Hồ sơ mạng riêng có thể hoạt động đúng như thiết kế trong khi trình duyệt, thứ lẽ ra không bao giờ dùng nó, vẫn thất bại. Đọc bảng định tuyến mà không sửa, và bao gồm IPv6, vì một đường IPv4 hoạt động không nói gì về họ còn lại.

Một tuyến cụ thể hơn có thể thắng trong khi tuyến mặc định vẫn tồn tại, vì thế phải đọc bảng chứ không phỏng đoán. Các bộ điều hợp ảo cạnh tranh cũng có thể sở hữu lưu lượng bạn chờ ở nơi khác, đặc biệt sau khi một ứng dụng VPN thứ hai được cài và bị lãng quên. Đừng xóa tuyến mặc định như một thử nghiệm; điều đó biến chẩn đoán thành sự cố thứ hai.

Một trang duy nhất thất bại giữa các trang hoạt động là vấn đề của trang đó, và nó cũng chứng minh đường hầm đang mang lưu lượng. Tình trạng khựng chỉ xuất hiện khi truyền lớn chỉ ra kích thước gói chứ không phải khả năng đến.

Khi máy chủ không bao giờ chuyển tiếp gì

Nếu mọi đích đều thất bại trên hai thiết bị và hai mạng truy cập, đường hầm đã lên và lối ra không chuyển tiếp. Chính cặp đó tách lỗi phía máy chủ khỏi một thiết bị cấu hình sai ở một nơi. Gửi cho người vận hành các câu hỏi về chuyển tiếp, NAT và đường quay về, không phải ảnh chụp đèn báo.

Ba điều đó bao phủ phần lớn nguyên nhân phía máy chủ, và người vận hành phải trả lời. Trang khắc phục sự cố kết nối của OpenVPN đi qua đúng những câu hỏi đó từ phía máy chủ, nên hãy chuyển nó kèm phiếu. Ảnh chụp một đèn xanh không trả lời được điều nào.

Rà nhật ký ứng dụng sau khi đăng nhập để tìm lỗi khi áp dụng tuyến, cài đặt DNS hoặc bộ điều hợp ảo. Lỗi ở giai đoạn đó chỉ vào thiết bị chứ không phải máy chủ. Một lỗi không bao giờ xuất hiện trong nhật ký cũng thông tin như vậy, vì nó chuyển nghi ngờ sang phía bên kia.

Kiểm tra từng lớp một

Khi đã thay đổi điều gì, hãy kết nối lại và lặp lại đúng ứng dụng đã thất bại. Một trang tải được chứng minh ít hơn một đường lặp lại được tới các tài nguyên mà hồ sơ được xây cho. Hai lệnh tách phân giải khỏi khả năng đến, và lệnh thứ hai phụ thuộc máy chủ. Chạy dòng curl ở bất cứ đâu, rồi chạy lệnh tuyến khớp với máy chủ trước mặt bạn.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Nếu yêu cầu số hoạt động mà tên thì không, hãy ở lại DNS. Nếu cả hai đều không, so sánh bảng định tuyến với giá trị mặc định mong đợi của đường hầm và kiểm tra họ địa chỉ bạn thực sự đang thử. Nếu tuyến đúng mà yêu cầu vẫn chết ở lối ra, câu hỏi còn lại thuộc về người vận hành, và bằng chứng bạn giữ chính là phiếu sự cố.