Cách kiểm tra VPN trên Windows thực sự định tuyến những gì trong PowerShell
Ô VPN đã kết nối không chứng minh vùng phủ. Hãy đọc cờ hồ sơ đã lưu, bảng định tuyến trực tiếp và các quy tắc NRPT theo thứ tự này.
Tôi kết nối ứng dụng VPN trên laptop Windows 11, ô chuyển sang Connected, một thư mục chia sẻ nội bộ mở ra, và một trang công khai vẫn tải trực tiếp từ Wi-Fi của văn phòng. Sự pha trộn đó trông như một đường hầm hỏng. Nhưng đó là kết quả bình thường của một hồ sơ gửi một phần lưu lượng qua VPN và để phần còn lại trên card mạng vật lý. Định tuyến cưỡng bức thay đổi tuyến mặc định mà Windows ưu tiên; nó không xóa các tuyến cụ thể hơn và không hứa lưu lượng sẽ dừng khi kết nối rớt. Dưới đây là thứ tự tôi đi qua khi một khách hàng tuyên bố có vùng phủ: trạng thái ứng dụng, hồ sơ đã lưu, tuyến đã áp dụng, bộ phân giải, rồi các luồng thực tế.
Bắt đầu từ ứng dụng, rồi ngừng tin nó
Ứng dụng là điểm bắt đầu đúng chỉ vì nó cho biết hồ sơ nào đang hoạt động. Mở thuộc tính kết nối và ghi lại tên hồ sơ chính xác, việc nó được tạo cho người dùng hiện tại hay cho mọi người trên máy, và card mạng nào xuất hiện trong ncpa.cpl sau khi kết nối. Trên laptop thử nghiệm của tôi, card mạng mang tên hồ sơ, điều đó giúp đọc đầu ra tuyến dễ dàng. Trên máy khác, nó hiện như một mục WAN Miniport và cái tên không cho bạn biết gì.
Điều ứng dụng không thể nói là vùng phủ. Một ô đã kết nối mô tả trạng thái của đường hầm, không phải danh mục đích đến. Các ứng dụng bên thứ ba cũng giữ cấu hình riêng, nên hồ sơ Windows gốc, và mọi thuộc tính bạn đọc từ nó, có thể không liên quan gì đến thứ ứng dụng đó đã cài. Nếu VPN đến qua AnyConnect, OpenVPN GUI, WireGuard hoặc một tác nhân của nhà cung cấp, các kiểm tra PowerShell bên dưới phần lớn không áp dụng và thay vào đó bạn nên đọc cài đặt split-tunnel và định tuyến riêng của ứng dụng đó.
Đọc hồ sơ đã lưu, không đọc ô
Với hồ sơ Windows gốc (IKEv2, L2TP, SSTP hoặc hồ sơ do MDM đẩy xuống), quyết định split-tunnel đã lưu là một thuộc tính duy nhất:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixThêm -AllUserConnection khi hồ sơ được tạo cho mọi người trên thiết bị. Không có nó, bạn đang đọc danh sách của người dùng hiện tại, danh sách này có thể trống hoặc chứa mục khác có tên tương tự. Giá trị False trong SplitTunneling nghĩa là hồ sơ được lưu dưới dạng đường hầm đầy đủ: Windows cài một tuyến mặc định qua card mạng VPN. True nghĩa là split tunnel, và vùng phủ khi đó phụ thuộc hoàn toàn vào các tuyến và quy tắc phân giải tên mà hồ sơ đó đẩy xuống.
Coi giá trị đó là cấu hình, không phải quan sát. Nó ghi lại những gì hồ sơ yêu cầu tại thời điểm kết nối. Windows có thể kết thúc với các tuyến đã áp dụng khác nhau, do tuyến cụ thể hơn của một giao diện khác, một thiết lập chính sách hoặc một mục còn sót lại từ kết nối trước, nên giá trị Boolean không bao giờ tự giải quyết câu hỏi.
So sánh giá trị đã lưu với bảng định tuyến đã áp dụng
Sau khi kết nối, liệt kê các tuyến trên card mạng đường hầm thay vì cuộn toàn bộ bảng:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute là nửa hữu ích. Nó trả lời câu hỏi mà ứng dụng không bao giờ trả lời: với đích này, giao diện nào và địa chỉ nguồn nào Windows thực sự sẽ dùng? Chạy nó cho một máy chủ nội bộ, một máy chủ công khai và bất cứ thứ gì bạn cho là ngoại lệ có chủ đích. Hồ sơ đường hầm đầy đủ phải hiển thị giao diện đường hầm cho địa chỉ công khai. Hồ sơ split tunnel thường hiển thị card mạng vật lý ở đó trong khi các tiền tố nội bộ vẫn phân giải qua VPN.
Hai cái bẫy giải thích phần lớn báo cáo «nó định tuyến sai hướng». Tiền tố cụ thể nhất luôn thắng, nên một /24 trên card mạng vật lý đánh bại tuyến mặc định trên VPN dù metric của đường hầm thấp đến đâu. Metric chỉ phá thế hòa giữa các tuyến cùng tiền tố. Và IPv4 với IPv6 được quyết định riêng: một hồ sơ phủ 0.0.0.0/0 có thể để IPv6 trên liên kết cục bộ, khiến một trang dual-stack trông như bị đường hầm hóa một nửa. Kiểm tra Get-NetRoute -AddressFamily IPv6 trước khi kết luận đường hầm ổn.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Kiểm tra phân giải tên riêng bằng NRPT
Các tên nội bộ thất bại trong khi địa chỉ IP nội bộ hoạt động cho thấy chính sách của bộ phân giải, không phải định tuyến. Windows quyết định DNS theo từng không gian tên thông qua bảng chính sách phân giải tên, bảng này độc lập với bảng định tuyến:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKhi một quy tắc khớp với *.corp.example, các truy vấn cho không gian tên đó đi đến máy chủ DNS của đường hầm kể cả khi đường dữ liệu tới các máy chủ đó vẫn nằm trên card mạng vật lý ở chế độ split tunnel. Đó là thiết kế, và đó là lý do một bài kiểm tra trình duyệt mở trang công khai không cho bạn biết gì về tên nội bộ. Nếu card mạng liệt kê các máy chủ mong đợi nhưng tìm kiếm vẫn đi nơi khác, hãy so sánh thứ tự quy tắc NRPT và kiểm tra xem không gian tên cụ thể hơn có khớp trước không.
Xác minh các luồng, rồi quyết định bạn thực sự đã yêu cầu gì
Đi qua các đích theo thứ tự cố định để kết quả so sánh được giữa các máy: một địa chỉ công khai, một địa chỉ nội bộ, một tên nội bộ và một ngoại lệ có chủ đích như máy in cục bộ hay cuộc gọi video. Ghi lại giao diện và địa chỉ nguồn mà Find-NetRoute trả về cho từng mục. Sau bất kỳ thay đổi chính sách nào, hãy kết nối lại và lặp lại đúng bốn kiểm tra đó; bảng định tuyến sau khi kết nối lại là bằng chứng duy nhất rằng hồ sơ mới đã có hiệu lực.
Sau đó tách định tuyến khỏi việc cưỡng chế. Định tuyến cưỡng bức ưu tiên đường hầm cho lưu lượng được phủ khi đường hầm còn hoạt động. Đó không phải kill switch. Nếu yêu cầu là không có gì rời khỏi máy khi đường hầm sập, điều đó phải đến từ một thiết kế chặn: hồ sơ tường lửa gắn với trạng thái đường hầm, hồ sơ luôn bật với bộ lọc lưu lượng, hoặc tùy chọn đóng-khi-lỗi của chính ứng dụng nhà cung cấp. Định tuyến cưỡng bức cũng phải để địa chỉ của chính máy chủ VPN truy cập được từ ngoài đường hầm, và chặn nó nhân danh «cưỡng chế mọi thứ» là cách chắc chắn để tự khóa mình ra khỏi kết nối bạn đang cố áp đặt.
Trước khi thay đổi bất cứ điều gì, hãy đi qua danh sách này. Mỗi mục thất bại thu hẹp nơi vấn đề thực sự nằm.
- Tên và phạm vi hồ sơ đã xác nhận, dùng
-AllUserConnectioncho hồ sơ toàn máy. SplitTunnelingđã đọc và được coi là cấu hình, không phải bằng chứng vùng phủ.- Các tuyến của card mạng đường hầm được liệt kê riêng cho IPv4 và IPv6.
Find-NetRouteđã chạy cho một đích công khai, một nội bộ và một ngoại lệ.- Quy tắc NRPT được kiểm tra trước khi đổ lỗi cho các tuyến về lỗi tên.
- Yêu cầu chặn đã đọc lại: định tuyến ưu tiên không giống với chặn được áp đặt.
Quyết định đường hầm đầy đủ hay split thuộc về chủ sở hữu hồ sơ, và ghi chú định tuyến của Microsoft mô tả hành vi Windows triển khai khi một hồ sơ đặt nó. Microsoft: định tuyến cưỡng bức và split là tài liệu tham chiếu tôi để mở khi đọc đầu ra.