Máy in, NAS hoặc máy phát triển trên bàn riêng của bạn ngừng phản hồi ngay khi VPN công việc kết nối. Đôi khi một lệnh tuyến đường sửa nó trong vài giây; đôi khi cùng tuyến đường đó đúng mà gói vẫn biến mất, nghĩa là bạn đang gặp một vấn đề khác với triệu chứng tương tự. Quyết định quy về ba câu hỏi, và hỏi sai thứ tự là lý do người ta mất cả buổi tối xóa rồi thêm lại tuyến đường.

Ba câu hỏi trước mọi lệnh

Thứ nhất: có mục nào cho tiền tố nội bộ không, và nó có trỏ tới bộ điều hợp vật lý không? Thứ hai: máy khách có nhận được sự cho phép hay từ chối mạng nội bộ từ cổng khi kết nối không? Thứ ba: bạn chỉ cần truy cập ra LAN, hay có gì đó trên internet cũng phải tới được một dịch vụ chạy trên máy của bạn?

Câu hỏi đầu tiên tách lỗi định tuyến khỏi lỗi lọc. Câu thứ hai cho biết việc sửa tuyến đường có được phép hoạt động hay không. Câu thứ ba thay đổi cách sửa: tuyến đường sửa lưu lượng đi ra, trong khi dịch vụ đi vào không tới được thường là vấn đề ràng buộc bộ lắng nghe và đường trở về mà tuyến đường chỉ làm tệ hơn.

What you seeWhat it points at
No local prefix in the tableMissing route
Correct prefix, no replyClient filter or gateway policy
Works by IP, fails by nameResolver changed by the tunnel
Inbound service dies, outbound fineReturn path or listener binding

Câu hỏi một: tuyến đường, bộ lọc hay tên

Đọc bảng trước khi thêm bất cứ thứ gì vào đó. Chỉ số giao diện quan trọng, vì mọi lệnh tuyến đường bên dưới đều neo vào nó:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Một subnet kết nối trực tiếp thường giữ tuyến đường on-link ngay cả khi tunnel đang bật, nên mục có thể tồn tại mà lưu lượng vẫn thất bại. Sự kết hợp đó là dấu hiệu của một bộ lọc chạy sau định tuyến, và đó là trường hợp tuyến đường thứ hai cụ thể hơn không thay đổi gì cả.

Kiểm tra riêng theo địa chỉ và theo tên. Nếu ping 192.168.1.50 trả lời còn net view 192.168.1.50 thì không, bảng định tuyến chưa bao giờ là vấn đề: tunnel đã đổi bộ phân giải và tên nội bộ không còn được phân giải. Thêm tuyến đường cho việc đó là công vô ích.

Câu hỏi hai: cổng có cho phép truy cập LAN nội bộ không?

Một máy khách thương mại cài nhiều thứ hơn tuyến đường. Nó nhận chính sách khi kết nối, và chính sách đó có thể gồm quyền truy cập mạng nội bộ rõ ràng. Trong triển khai Cisco IPsec, chính sách nhóm mang cài đặt split-tunneling và một cờ riêng cho truy cập LAN nội bộ; hộp kiểm trong máy khách là một yêu cầu mà cổng có thể từ chối. Trong AnyConnect, hồ sơ điều khiển danh sách bao gồm và loại trừ split cùng quyền đó. Trên Windows RRAS, tương đương là tùy chọn cổng mặc định trong hồ sơ cộng với các tuyến tĩnh mà máy chủ gán.

Khi cờ tắt, hành vi được ghi nhận là máy khách chặn lưu lượng tới subnet kết nối trực tiếp dù tồn tại tuyến đường hợp lệ, cụ thể hơn. Đó cũng là lý do các tuyến đường mà máy khách không sở hữu có thể biến mất vài giây sau khi bạn thêm: máy khách đang dựng lại trạng thái mà nó được bảo phải dựng, không phải đang chống lại bạn.

Nhật ký máy khách ghi lại quyết định khi kết nối, và đọc nó nhanh hơn bất kỳ thí nghiệm nào trên máy. Nếu nhật ký nói truy cập nội bộ bị chặn, hãy dừng: không bản sửa dòng lệnh nào sống sót qua điều đó, và các đường còn lại là thay đổi chính sách, tới tài nguyên qua tunnel, hoặc giam máy khách trong máy ảo và để máy chủ ở lại mạng nội bộ.

Câu hỏi ba: bạn cần hướng nào?

Lưu lượng đi ra tới một thiết bị gần đó là câu hỏi định tuyến. Trỏ tiền tố LAN tới cổng nội bộ với số đo đủ thấp để thắng tuyến mặc định của tunnel:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Dạng thứ hai ghim một thiết bị, và đó là điều bạn muốn khi một địa chỉ là toàn bộ yêu cầu. Tương đương netsh ghi cùng quyết định theo tên giao diện thay vì chỉ số:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Các lệnh tuyến đường thất bại với Tham số không đúng khi địa chỉ và mặt nạ không khớp, ví dụ địa chỉ máy chủ với mặt nạ /24. Dùng địa chỉ mạng cho tuyến subnet và mặt nạ máy chủ cho một máy chủ.

Lưu lượng đi vào khác. Một máy chủ VNC hoặc SSH trên cùng máy trở nên không tới được khi các phản hồi cho kết nối đi vào rời qua cổng VPN và không bao giờ trở lại. Kiểm tra dịch vụ lắng nghe trên cái gì trước khi chạm vào tuyến đường:

netstat -ano | findstr :5900

Một bộ lắng nghe gắn với một địa chỉ cụ thể sẽ không trả lời trên giao diện kia. Gắn nó với mọi giao diện là quyết định có chủ đích, được đưa ra cùng với quy tắc tường lửa giới hạn ở mạng bạn tin cậy. Chỉ sau đó việc sửa tuyến đường mới khôi phục đường trở về.

Áp dụng thay đổi nhỏ nhất phù hợp

Một bước phổ biến khác là bỏ chọn “Dùng cổng mặc định trên mạng từ xa” trong thuộc tính nâng cao của IPv4. Điều này giữ lưu lượng internet ở nội bộ, nhưng làm hai việc cùng lúc: VPN không còn là đường mặc định, và máy khách không còn nhận tuyến đường cho mạng từ xa, kể cả multicast. Bỏ chọn và LAN từ xa biến mất trừ khi máy chủ đẩy các tiền tố từ xa cụ thể mà mỗi máy khách cần.

Sự bất đối xứng đó quyết định thứ tự công việc. Nếu phía từ xa phải luôn tới được đầy đủ, hãy đẩy subnet từ xa từ máy chủ và để mặc định nội bộ yên. Nếu không thể đổi máy chủ, hãy thêm tuyến đường thường trực tới tiền tố từ xa qua địa chỉ mà tunnel đã cấp, và kiểm tra bằng route print rằng tiền tố trỏ tới giao diện VPN trong khi mặc định vẫn trỏ tới cổng vật lý.

Sau đó xác nhận việc sửa tồn tại qua lần kết nối lại, vì tuyến đường không thường trực chết cùng bộ điều hợp và một script chạy sau mỗi lần kết nối là nơi trung thực cho chúng. Thử một thiết bị nội bộ và một tài nguyên từ xa trong cùng phiên, ngắt kết nối, kết nối lại và thử lại. Nếu thiết bị nội bộ vẫn thất bại trong khi tuyến đường trông đúng, hãy quay lại câu hỏi hai: máy khách đang lọc, và câu trả lời là thay đổi chính sách chứ không phải tuyến đường thứ hai cạnh tranh.

Bài viết liên quan