Vì sao một tuyến VPN rộng phá hỏng vài trang công khai

Hầu hết các trang tải được, hai hoặc ba trang hết thời gian chờ, và trình duyệt đổ lỗi cho kết nối. Những trang thất bại có một điểm chung mà các trang hoạt động không có: địa chỉ đã phân giải của chúng nằm trong một tiền tố mà VPN đã cài. Một tuyến đủ rộng để bao phủ một dải công cộng sẽ bắt lấy lưu lượng mà đường hầm chưa bao giờ được dự định chở, và triệu chứng trông giống sự cố trang web hơn là một quyết định định tuyến.

Phân giải tên bị lỗi, rồi xem bảng định tuyến thay vì trình duyệt.

So sánh địa chỉ, không phải tên trang

Tìm địa chỉ mà máy khách thực sự đã thử, rồi kiểm tra tuyến nào khớp với nó. Một đích bên trong 45.61.20.10 nằm dưới 45.0.0.0/8 nếu tiền tố đó hiện diện, dù bản thân trang không liên quan gì đến đường hầm. So sánh địa chỉ bị lỗi với các tiền tố đã cài là một bài trừ, không phải phỏng đoán.

Windows có thể trả lời trực tiếp cả hai nửa, và một truy vấn cho thấy giao diện nào và chặng kế tiếp nào đã thắng lựa chọn. Phân giải tên hai lần nếu trang trả về nhiều địa chỉ. Ghi lại từng địa chỉ cùng tuyến khớp với nó. Các địa chỉ khác nhau có thể cho câu trả lời khác nhau, và chỉ một trong số đó có thể là trường hợp bị lỗi.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Đọc tiền tố khớp cụ thể nhất, không phải dòng đầu tiên trông quen thuộc. Một tuyến có trong bảng không chứng minh nó đã thắng truy vấn; khớp dài nhất mới làm điều đó. Hai tiền tố có thể khớp với một địa chỉ, và chỉ một trong chúng nhận gói tin. Bên thua vẫn nằm trong bảng và trông thật y như vậy trong danh sách.

Ghi lại tiền tố, giao diện của nó và địa chỉ đã phân giải. Ba giá trị đó là toàn bộ chẩn đoán.

Tìm ra ai đã cài đặt tuyến

Các tuyến đến từ bốn nơi: hồ sơ VPN gốc, chính sách quản lý, kịch bản kết nối hoặc một máy khách hoàn toàn khác. Xóa mục đang hoạt động có thể xác nhận mức liên quan của nó, nhưng kết nối tiếp theo sẽ tạo lại nó từ cấu hình đã lưu, nên nguồn mới là thứ phải thay đổi.

Kiểm tra danh sách tuyến của hồ sơ trước, rồi chính sách quản lý, rồi bất kỳ kịch bản nào chạy khi kết nối. Thứ tự đó khớp với tần suất mỗi thứ tỏ ra chịu trách nhiệm. Nó cũng giữ thay đổi trong một lớp thay vì ba.

Đọc kỹ hành vi gốc dựa trên lớp

Hồ sơ Windows gốc có một cài đặt được ghi tài liệu, NativeProfile/DisableClassBasedDefaultRoute, điều khiển một tuyến tự động suy ra từ địa chỉ giao diện. Một địa chỉ hồ sơ bắt đầu bằng 45 có thể tạo ra mục 45.0.0.0/8 dưới hành vi đó, và đó là cách một địa chỉ công cộng duy nhất bắt cả dải lớp A.

Tên thuộc tính mời gọi cách đọc sai: đặt thành true sẽ tắt suy luận, còn false bật nó. Nó cũng không phải cùng đối tượng với tuyến mặc định, và nó không điều khiển các máy khách bên thứ ba tự cài tiền tố của họ.

Nếu suy luận là nguyên nhân đã được chứng minh, hãy sửa hồ sơ thông qua chủ quản lý của nó và cung cấp rõ ràng các tiền tố riêng đã định. Nếu một kịch bản đã thêm mục, hãy sửa kịch bản. Thay một tuyến rộng không giải thích bằng tuyến khác sẽ đổi triệu chứng mà không trả lời câu hỏi.

Sửa nguồn, rồi kiểm tra lại cả hai đường

Sau thay đổi, kết nối lại và lặp lại truy vấn cho một trang công khai bị lỗi và cho một tài nguyên phải dùng đường hầm. Cái đầu giờ phải phân giải về giao diện vật lý, cái sau vẫn phải chọn VPN. Đừng dừng ở thành công đầu tiên; một bản sửa cũng phá quyền truy cập riêng đã đổi lỗi này lấy lỗi khác.

Đồng thời xem lại quy hoạch địa chỉ của máy chủ. Một nhóm địa chỉ chồng lấn không gian công cộng gây ra loại sự cố này lặp đi lặp lại. Một dải mà nhà vận hành cố ý chọn đáng được một cuộc trao đổi khác, không phải đánh số lại tự động.

Tăng MTU hay xóa DNS sẽ không sửa được một tiền tố vẫn đang đưa địa chỉ đó vào đường hầm. Hãy kiểm tra lựa chọn trước, rồi đến đường đi.