VPN Windows hiển thị 255.255.255.255: mặt nạ có sai không?

Đường hầm kết nối, bạn mở chi tiết bộ điều hợp và mặt nạ hiển thị 255.255.255.255. So với 255.255.255.0 của LAN văn phòng, nó trông như hỏng, và đó thường là nơi lỗi bắt đầu. Trên một liên kết điểm-điểm, mặt nạ máy chủ là mô tả đúng cho đầu cuối cục bộ, và các mạng từ xa đến dưới dạng tuyến chứ không phải dưới dạng mạng con gắn trực tiếp. Quy trình bên dưới tách hai câu hỏi để bạn không phải dựng lại một dải DHCP đang hoạt động chỉ để sửa một giá trị hiển thị.

Liên kết điểm-điểm không phải một phân đoạn Ethernet

Giao diện Ethernet cần mặt nạ mạng con vì mọi địa chỉ trong dải đó đều có thể tiếp cận được trên cùng một dây cáp. Đường hầm kiểu PPP chỉ có đúng một đối tác ở đầu bên kia. Không có miền quảng bá, không có ARP và không có lý do gì để địa chỉ cục bộ mô tả một dải.

Việc thương lượng địa chỉ cho mô hình đó được định nghĩa trong RFC 1332, tài liệu mô tả cách hai đầu thống nhất địa chỉ của mình. Điều nó không làm là cấp cho máy khách LAN văn phòng như một mạng kết nối trực tiếp. Máy khách học vị trí văn phòng bằng cách cài các tuyến qua liên kết, và chính các tuyến đó quyết định khả năng tiếp cận.

Điều này không có nghĩa mọi mặt nạ bạn thấy đều đúng. Một máy khách cấu hình sai cũng có thể tạo ra địa chỉ lạ. Điểm mấu chốt hẹp hơn: mặt nạ máy chủ trên loại bộ điều hợp này là điều bình thường, nên tự nó không phải bằng chứng của lỗi.

Bước 1: xác nhận mô hình giao diện

Hãy xem bộ điều hợp là gì trước khi đánh giá nó nói gì. Chuỗi mô tả xác định trình điều khiển, và độ dài tiền tố trên địa chỉ được cấp xác nhận những gì máy khách đã thương lượng:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

Lệnh thứ ba là lệnh giải quyết phần lớn tranh cãi. Đơn vị truyền tải tối đa thấp là đặc điểm của một liên kết được đóng gói, trong khi một giá trị giống Ethernet gợi ý một mô hình bộ điều hợp ảo khác. Nếu mô tả nêu trình điều khiển PPP hoặc RAS và tiền tố là 32, bạn đang xem đúng thiết kế được mô tả ở trên và có thể ngừng lo lắng về mặt nạ.

Bước 2: đọc tuyến cho đích bị lỗi

Khả năng tiếp cận được quyết định theo từng đích, và một giao diện đã kết nối không cho bạn biết gì về điều đó. Hỏi trực tiếp bảng tuyến về địa chỉ mà người dùng thực sự đang cố truy cập:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute là câu trả lời trực tiếp: nó nêu giao diện và địa chỉ nguồn mà hệ thống sẽ dùng cho đích đó. Nếu nó trả về đường hầm, lưu lượng đến máy chủ đó đi qua đường hầm và mặt nạ chưa bao giờ là vấn đề.

Nếu nó trả về bộ điều hợp vật lý, hãy so sánh hai tuyến ứng viên và số liệu của chúng. Một tuyến cục bộ cụ thể hơn, một mục còn sót lại từ máy khách khác hoặc số liệu thấp hơn trên đường vật lý đều thắng một tuyến đường hầm rộng. Kết quả nhìn thấy được là một tài nguyên không thể tiếp cận trong khi mọi thứ khác vẫn hoạt động. Tiền tố dài hơn luôn thắng, nên người thắng thường là một tuyến máy chủ mà ai đó đã thêm từ nhiều tháng trước và quên mất.

Hãy kiểm tra cả hai chiều khi bạn ở đây. Một tuyến đến phía máy chủ là cần thiết nhưng chưa đủ, vì phản hồi cũng phải quay lại qua đường hầm. Khi một máy chủ nội bộ hoạt động còn máy khác không, sự khác biệt thường nằm trong bảng này chứ không phải trong cấu hình bộ điều hợp.

Bước 3: tách phân giải tên khỏi quyền truy cập dịch vụ

Một ứng dụng không mở được thư mục chia sẻ có thể thất bại ở một trong hai giai đoạn rất khác nhau. Phân giải tên, rồi đến địa chỉ. Nếu bước đầu thất bại và bước sau hoạt động, đường hầm vẫn ổn và trình phân giải thì không:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Một bài kiểm tra địa chỉ thành công cùng với một bài kiểm tra tên thất bại sẽ khoanh vùng vấn đề vào việc phân giải, và lệnh thứ hai cho thấy giao diện đường hầm có nhận được máy chủ nào hay không. Nhiều máy khách đẩy DNS như một phần cấu hình đường hầm, và một hồ sơ bỏ qua các tùy chọn được đẩy đó sẽ để máy tính dùng trình phân giải không thấy vùng riêng tư.

Đừng coi một địa chỉ đang hoạt động là cách sửa lâu dài. Kết nối bằng địa chỉ bỏ qua phân giải tên và có thể làm suy yếu việc kiểm tra danh tính máy chủ mà ứng dụng lẽ ra phải thực hiện. Đó là một thoái bộ bảo mật được ngụy trang thành giải pháp tạm thời. Hãy dùng nó để khoanh vùng lỗi, rồi sửa phân giải.

Khôi phục: đừng dựng lại DHCP vì một giá trị hiển thị

Nếu bạn đã bắt đầu thay đổi dịch vụ cấp địa chỉ, hãy dừng lại và kiểm tra xem có gì bạn đã thay đổi là thiết yếu không. Tạo lại một dải, cấp lại hợp đồng thuê hoặc di chuyển nhóm địa chỉ sẽ thay đổi trạng thái mà các máy khách khác phụ thuộc vào, và không điều nào trong số đó được biện minh bởi một mặt nạ máy chủ trên bộ điều hợp điểm-điểm.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Chạy ba lệnh này sau mọi thay đổi có chủ đích và so sánh với lần chạy trước. Kết quả hữu ích là một đường đi được ghi lại đến tài nguyên, không phải một bộ điều hợp có mặt nạ giống LAN văn phòng.

Sau đó hãy ghi lại mặt nạ thực sự có nghĩa là gì, vì người tiếp theo sẽ mở cùng hộp thoại đó và đi đến cùng kết luận sai. Một câu trong ghi chú hồ sơ, nói rằng đường hầm là điểm-điểm và các mạng con từ xa đến dưới dạng tuyến, sẽ tiết kiệm toàn bộ cuộc điều tra lần sau.