Không truy cập được mạng nội bộ khi VPN đang kết nối? Bốn bước kiểm tra

Đường hầm được thiết lập, intranet hiện ra, và máy in ngừng phản hồi. Không có gì hỏng trong LAN; client đã đổi đường đi mà nó dùng cho những địa chỉ mà nó không còn coi là nội bộ. Hãy làm bốn bước kiểm tra dưới đây theo thứ tự và dừng lại khi một bước cho thấy sự không khớp cụ thể, vì cùng một triệu chứng có bốn nguyên nhân phổ biến và chỉ một trong số đó được khắc phục bằng cách sửa VPN.

Trước tiên, hãy xem bảng định tuyến mà client đã cài

Mở bảng định tuyến của client khi VPN đang kết nối. Trên Linux dùng ip route, trên Windows dùng route print hoặc Get-NetRoute, và trên macOS dùng netstat -rn. Bạn đang tìm tuyến mặc định đi qua đường hầm và điều gì đã xảy ra với tuyến mặc định vật lý.

Client toàn hầm thường thêm hai tuyến nửa mặc định, 0.0.0.0/1 và 128.0.0.0/1, thay vì thay thế 0.0.0.0/0. Tuyến mặc định ban đầu vẫn hiển thị nhưng thua mọi lần tra cứu, đó là lý do bảng có thể trông nguyên vẹn trong khi mọi lưu lượng ngoài subnet dịch chuyển. Nếu client VPN có tùy chọn chia hầm và chính sách cho phép, đó là cách sửa sạch nhất.

Nếu đường hầm phải tiếp tục là tuyến mặc định, hãy ghim subnet nội bộ thay vì thế. Trên Linux tuyến nêu tên giao diện vật lý và cổng; trên Windows thêm -p để nó tồn tại lâu dài và đọc số giao diện từ route print thay vì đoán:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Tuyến đã ghim chỉ giữ được chừng nào địa chỉ mà nó nêu vẫn giữ nguyên. Một laptop nhận số mới cho bộ điều hợp Wi-Fi mỗi lần kết nối sẽ lại phá vỡ quy tắc, nên hãy kiểm tra địa chỉ giao diện trước khi kết luận bản sửa đã thất bại.

Thứ hai, xác nhận rằng địa chỉ đó vốn đã là nội bộ

Nếu đích nằm trong subnet đang kết nối, tuyến mặc định của đường hầm không bao giờ áp dụng và VPN không phải nguyên nhân. Máy in ở 192.168.1.40 trên client có 192.168.1.0/24 dùng tuyến đã kết nối; nếu địa chỉ đó lỗi, hãy xem thiết bị, switch hoặc tường lửa của client chứ không phải VPN.

Trường hợp đánh lừa mọi người là địa chỉ công khai cho một máy chủ nội bộ. Từ bên trong LAN, việc đến địa chỉ WAN của router rồi quay lại cần hairpin NAT, và nhiều router đơn giản là không triển khai nó cho chuyển tiếp cổng. Hãy thử địa chỉ riêng bên cạnh địa chỉ công khai. Nếu địa chỉ riêng hoạt động còn địa chỉ công khai thì không, VPN chỉ phơi bày một giới hạn NAT vốn đã tồn tại.

Tên máy chủ làm mọi thứ tệ hơn. Nếu tên nội bộ giờ phân giải thành địa chỉ công khai, client sẽ tiếp tục thử con đường không thể quay về. Dùng địa chỉ riêng cho bài kiểm tra, rồi sửa tên thay vì thêm một chuyển tiếp cổng nữa.

Thứ ba, xem ai đang trả lời các tên bây giờ

Bộ phân giải của doanh nghiệp biết intranet và thường không biết gì về tên máy chủ của NAS, tên Bonjour của máy in hay bí danh nội bộ của router. Khi VPN đẩy các máy chủ DNS của nó vào, những tên đó ngừng phân giải dù địa chỉ vẫn còn truy cập được. Hãy truy vấn tên trực tiếp và so sánh câu trả lời với địa chỉ mà bạn biết thiết bị đang có.

Trên Linux, resolvectl query nas.local cho biết bộ phân giải nào đã trả lời. Trên Windows, nslookup nas.local nêu tên máy chủ, và ipconfig /all cho thấy thứ tự các bộ phân giải. Nếu hậu tố nội bộ giờ do bộ phân giải doanh nghiệp xử lý, hãy chuyển hậu tố đó trở lại bộ phân giải nội bộ hoặc dùng địa chỉ IP cho thiết bị.

Khám phá là một tầng riêng. mDNS và quảng bá không đi qua đường hầm có định tuyến, nên thiết bị có thể truy cập được bằng địa chỉ trong khi tên vẫn vô hình. Một bộ phản xạ hoặc một mục DNS nội bộ giải quyết điều đó; tuyến thì không.

Thứ tư, kiểm tra xem máy kia có cũng ở trong VPN không

Khi máy bạn muốn đến cũng chạy một client VPN, phiên của bạn có thể đến trong khi câu trả lời của nó đi ra qua đường hầm kia. Điều đó tạo ra một kết nối được thiết lập rồi khựng lại, hoặc một lần thử RDP và SSH hết thời gian mà không báo lỗi ở phía bạn. Hãy kiểm tra bảng định tuyến và tuyến mặc định của máy kia trước khi đổ lỗi cho client của bạn.

Cũng hãy kiểm tra địa chỉ mà dịch vụ đang lắng nghe. Một bộ lắng nghe chỉ gắn với địa chỉ đường hầm sẽ nhận kết nối từ VPN và từ chối kết nối từ LAN, ngay cả khi định tuyến hoàn hảo. Đó là cấu hình của dịch vụ, không phải đường mạng, và nó phổ biến trên các giao diện quản trị bị khóa vào địa chỉ VPN.

Hãy giữ một đường quản trị không phụ thuộc vào đường hầm: một tuyến tĩnh nêu tên mạng nguồn của bạn, một giao diện khác gắn với LAN, hoặc một bảng điều khiển bỏ qua hoàn toàn đường hầm. Thiết kế đường đó sau khi phiên rớt khó hơn nhiều so với việc thêm nó trước lần kết nối tiếp theo.

Áp dụng bản sửa khớp với bước kiểm tra đã thất bại

Nếu bảng định tuyến cho thấy sự chiếm đoạt nửa mặc định, hãy chọn chia hầm khi chính sách cho phép và tuyến nội bộ đã ghim khi không cho phép. Nếu địa chỉ hóa ra là công khai, hãy chuyển bài kiểm tra và tên sang địa chỉ riêng. Nếu bộ phân giải đổi tay, hãy giới hạn ở hậu tố nội bộ hoặc dùng địa chỉ. Nếu máy kia ở trong đường hầm, hãy sửa đường quay về hoặc cách gắn bộ lắng nghe của nó.

Chỉ thay đổi một thứ, rồi lặp lại đúng bước kiểm tra đó. Một tuyến được thêm cho subnet sai, một hậu tố bộ phân giải bị lỗi chính tả và một tuyến ghim trên giao diện nhận số mới đều trông giống sự cố ban đầu. Chính việc lặp lại phân biệt bản sửa với sự trùng hợp.

Hãy ghi lại tuyến, địa chỉ và bộ phân giải đã hoạt động khi VPN đang kết nối. Lần kết nối lại tiếp theo sẽ thay đổi ít nhất một trong số đó, và ghi chú biến sự cố kế tiếp thành một so sánh ngắn thay vì một cuộc điều tra mới.