Internet chỉ chạy khi bật ứng dụng VPN? Hãy kiểm tra bốn lớp

Bạn dùng thử một tuần một ứng dụng VPN miễn phí hoặc một tiện ích trình duyệt, tắt nó đi, và internet dừng lại. Biểu tượng Wi-Fi vẫn hiện kết nối, các thiết bị khác trên cùng bộ định tuyến vẫn tốt, và thứ duy nhất mang lại duyệt web là bật lại ứng dụng hoặc gỡ cài đặt nó. Kiểu đó không phải là mã hóa tạo ra sự phụ thuộc. Đó là cấu hình mà ứng dụng đã ghi ở đâu đó mà đường hầm không sở hữu.

Ứng dụng sửa những thiết lập mà đường hầm không sở hữu

Một ứng dụng riêng tư trên Windows hay macOS thường chạm vào ba chỗ cùng lúc. Nó đặt proxy HTTP hệ thống, đúng trường mà Internet Options hiển thị. Nó cài một bộ điều hợp ảo, thường là trình điều khiển TAP, để bắt gói tin. Và nó viết lại danh sách bộ phân giải, trong khi khi bạn nhấn ngắt kết nối thì chỉ đường hầm biến mất.

Tiện ích trình duyệt là thứ hẹp hơn. Nó thường thay đổi hồ sơ của chính nó hoặc proxy mà một trình duyệt tuân theo. Đó là lý do một trình duyệt có thể hỏng trong khi công cụ dòng lệnh vẫn chạy, hoặc ngược lại: tiện ích chưa bao giờ có quyền chạm vào các lớp khác. Lớp nào nó đã sửa quyết định công cụ nào sẽ hỏng.

Dù thế nào, quyết định cũ kỹ đó do phần mềm đưa ra mà nó không có lý do gì để hoàn tác. Đường hầm là phần nhìn thấy được, và nó cũng là phần duy nhất có đường tắt sạch sẽ. Mọi thứ còn lại là thiết lập trong một kho lưu trữ sống lâu hơn tiến trình, nên gỡ ứng dụng là bước duy nhất đảo ngược cả ba cùng lúc. Đọc các kho đó trước khi cài lại bất cứ thứ gì chính là điều biến triệu chứng thành chẩn đoán.

Ba thứ còn sót, ba kiểu hỏng khác nhau

Thứ còn sót đầu tiên là một proxy trỏ vào hư không: ô proxy LAN vẫn được đánh dấu, hoặc URL kịch bản cấu hình nhắm vào một cổng localhost nơi không còn tiến trình nào lắng nghe. Trình duyệt chuyển mọi yêu cầu tới cổng chết đó và treo cho đến khi thời gian chờ trông giống một mạng chết. Thứ hai là một bộ điều hợp vẫn sở hữu tuyến mặc định, vì thiết bị TAP-Windows hay trình điều khiển định tuyến của nhà cung cấp vẫn là một giao diện thật sau khi gỡ cài đặt. Nó giữ tuyến đã được cấp, và lưu lượng biến mất vào một đường hầm không tồn tại. Không thứ nào tự loan báo; cả hai trông đúng như một sự cố mạng.

Thứ ba là DNS, và nó hỏng sớm hơn hai thứ kia. Nếu danh sách bộ phân giải chỉ chứa các máy chủ tiếp cận được qua đường hầm, mọi truy vấn đều hết thời gian trước khi một trang được yêu cầu, nên trình duyệt báo một trang không tới được thay vì một proxy chết. Dù bạn gặp cái nào, không cái nào là sự cố theo nghĩa mạng. Mỗi cái là một thứ còn sót mà không ai thu hồi, và mỗi cái được sửa ở một chỗ khác nhau.

Đi xuống qua bốn lớp

Hãy bắt đầu gần ứng dụng nhất và đi xuống, vì các lớp hỏng theo đúng thứ tự hiển thị đó. Đổi một lớp mỗi lần thử, và thử lại sau mỗi lần. Đặt lại mọi thứ cùng lúc thường khôi phục duyệt web và để bạn không thể nói thứ còn sót nào đã gây ra, nên lần cài sau tái tạo đúng câu đố đó. Thứ tự là proxy, bộ điều hợp, tuyến, bộ phân giải.

Trên Windows mỗi kiểm tra là một lệnh duy nhất đi kèm hệ điều hành, nên không cần cài gì. Chạy chúng theo thứ tự và giữ đầu ra cùng nhau, vì bốn câu trả lời chỉ có nghĩa khi đặt cạnh nhau. Chúng báo proxy, bộ điều hợp, tuyến IPv4 và danh sách bộ phân giải, theo đúng thứ tự đó:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux và macOS cần lệnh riêng, và chúng không thể thay thế cho nhau. Trên Linux tuyến lấy từ ip route và bộ phân giải từ resolvectl status ở nơi systemd-resolved sở hữu nó, dự phòng bằng cat /etc/resolv.conf. Trên macOS tuyến lấy từ netstat -rn, bộ phân giải từ scutil --dns, và proxy hệ thống từ scutil --proxy. Một người đọc macOS chạy ip route sẽ nhận command not found, còn /etc/resolv.conf ở đó là một stub được sinh ra chứ không phải cấu hình có thẩm quyền. Hãy kiểm tra nền tảng trước khi kiểm tra lớp, nếu không lệnh đầu tiên sẽ trở thành phát hiện.

Với mỗi lớp hãy hỏi một câu: giá trị này còn trỏ vào thứ gì tồn tại khi ứng dụng đã đóng không? Một proxy ở cổng chết, một bộ điều hợp không có đường hầm, một tuyến mặc định qua giao diện đã xuống và một bộ phân giải bên trong đường hầm đều trả lời là không. Chỉ một chữ không là đủ để giải thích triệu chứng, đó là lý do một thay đổi mỗi lần thử lại quan trọng.

Proxy không phải đường hầm

Proxy nhận yêu cầu, lấy nó ở nơi khác và trả lại phản hồi, nghĩa là nó biết đích đến và thấy mọi thứ mà trang chưa tự mã hóa. Nó không mang các giao thức khác. Nó không bảo vệ đường đi trừ khi đích đến đã dùng TLS. Và nó có thể bị thay đổi bởi bất cứ thứ gì đã cài nó, không cần bạn tham gia.

Sự khác biệt đó đổi câu hỏi đáng đặt ra. Khi một proxy còn nằm lại, hãy tìm xem chương trình nào vẫn lái trình duyệt của bạn, chứ không phải đường hầm có đang lên hay không. Đường hầm có thể hoàn toàn khỏe mạnh và hoàn toàn không liên quan đến sự cố.

Nếu muốn biết ứng dụng đó thực sự đã làm gì, hãy quan sát nó thay vì đọc bảng điều khiển của nó. Process Monitor ghi lại những khóa đăng ký và tệp nó chạm vào, còn bắt gói tin cho thấy lưu lượng của nó đã đi đâu. Cả hai là công cụ bình thường, và cả hai trả lời câu hỏi về thứ còn sót tốt hơn mọi đèn trạng thái. Không cái nào cần ứng dụng còn đang chạy.

Gỡ thành phần, không gỡ bằng chứng

Cách sửa bền vững là gỡ thứ đã ghi thiết lập. Gỡ ứng dụng, xóa bộ điều hợp ảo nó đã thêm, xóa proxy và danh sách bộ phân giải, rồi khởi động lại và thử khi ứng dụng vẫn chưa được cài. Nếu lúc đó duyệt web chạy, bạn đã tìm ra nguyên nhân chứ không phải một cách lách. Ghi lại lớp nào đã cũ, vì cùng một nhà cung cấp thường tung ra cùng một lỗi hai lần.

Nếu triệu chứng quay lại sau khi bạn cài ứng dụng kế tiếp, hãy đi lại bốn lớp trước khi kết luận rằng dịch vụ đã làm hỏng thứ gì. Bằng chứng thường vẫn ở đó, tại một trong bốn chỗ. Ứng dụng thứ hai không tạo ra lớp thứ năm; nó sửa một trong bốn lớp.

Cài lại đặt lại proxy nhưng không đặt lại bộ điều hợp cũ, và nó có thể để lại hai bộ phân giải trong danh sách. Chính sự bất đối xứng đó là lý do gỡ-rồi-thử tốt hơn nút đặt lại tất cả. Nó cũng cho bạn một mức nền để so sánh lần sau khi kết nối rớt.