Địa chỉ VPN so với thuê DHCP trong LAN: ai cấp IP của đường hầm?

Kết nối máy khách và xem bộ điều hợp thay vì biểu tượng Wi-Fi. Một địa chỉ như 10.80.0.14 có thể nằm trên đường hầm trong khi không máy chủ DHCP nào trong LAN văn phòng từng ghi lại bản thuê đó. Chính tiến trình đã chọn con số quyết định nơi bắt đầu việc khắc phục sự cố.

Trên máy khách mọi thứ trông giống nhau: một địa chỉ IPv4, một mặt nạ, đôi khi một cổng mặc định. Sự khác biệt chỉ hiện ra khi bạn hỏi ai trả lời cho địa chỉ đó và ai giữ bản ghi về nó.

Đọc địa chỉ đường hầm từ phía máy khách

Windows cho thấy sự khác biệt nếu bạn đọc toàn bộ khối chứ không chỉ dòng đầu. ipconfig /all in ra mô tả bộ điều hợp, địa chỉ vật lý và một dòng DHCP. Bộ điều hợp quay số PPP hoặc IKEv2 thường báo DHCP là đã tắt, vì kết nối đã thương lượng địa chỉ trong lúc quay số thay vì thuê từ máy chủ trong LAN. Bộ điều hợp đường hầm có DHCP bật là điều bất thường và đáng được điều tra riêng.

Linux chia cùng thông tin đó cho hai công cụ. ip -4 addr show dev tun0 cho địa chỉ và độ dài tiền tố. nmcli -f IP4 connection show work tiết lộ liệu giá trị đến từ hồ sơ kết nối, từ trao đổi DHCP trên liên kết hay từ cấu hình được đẩy xuống. WireGuard là trường hợp rõ nhất, vì wg-quick áp dụng dòng Address từ tệp cấu hình khi giao diện xuất hiện và không đối tác nào cấp phát gì vào lúc kết nối.

Tiền tố cũng nói lên điều gì đó. Một /32, hoặc mặt nạ 255.255.255.255, nghĩa là cổng mong đợi định tuyến tới một địa chỉ máy chủ duy nhất, trong khi mặt nạ rộng hơn gợi ý một mạng con trên liên kết ở đâu đó phía sau đường hầm.

Tải trọng cấu hình IKEv2 mang gì

IKEv2 có một cơ chế riêng cho công việc này. Tải trọng cấu hình được mô tả trong RFC 7296, phần 3.15.1 mang các thuộc tính như INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS và các bản tương đương IPv6 của chúng. Máy khách gửi thuộc tính có giá trị độ dài bằng không khi không có ưu tiên, và bên trả lời gửi lại giá trị mà nó muốn dùng. Trao đổi đó diễn ra bên trong IKE_AUTH, đã được mã hóa, nên không có quảng bá DHCP nào đi qua đường hầm.

Có hai hệ quả. Thứ nhất, địa chỉ do bên trả lời hoặc bất kỳ phần phụ trợ ủy quyền nào mà nó tham vấn chọn, vì thế một nhóm địa chỉ có thể nằm trên cổng, trong phản hồi RADIUS hoặc trong ánh xạ của nhà cung cấp danh tính. Thứ hai, thuộc tính DNS tách biệt với thuộc tính địa chỉ. Nhận được 10.80.0.14 không nói gì về việc bộ phân giải nào đã trả về, hoặc có trả về hay không.

Thuộc tính mặt nạ mạng là tùy chọn trên thực tế. Nhiều triển khai chỉ trả về một địa chỉ và để máy khách cài đặt tuyến tới máy chủ, vì thế cùng một nhóm có thể trông như /32 trên một máy khách và như /24 trên máy khác.

Nơi phạm vi DHCP của LAN và nhóm VPN va chạm

Rắc rối bắt đầu khi cả hai bên cấp phát trỏ tới cùng một dải. Máy chủ DHCP cho 10.20.30.0/24 không biết gì về nhóm VPN được cấu hình cho 10.20.30.128/25, nên không gì ngăn nó cho thuê 10.20.30.140 cho một máy in trong khi cổng trao cùng địa chỉ đó cho một máy khách từ xa. Va chạm cứ im lặng nhiều ngày rồi lộ ra như một bản trùng lặp không thường xuyên.

Thiết kế định tuyến site-to-site tránh va chạm ngay từ cấu trúc. Một máy chủ trong chi nhánh giữ địa chỉ mà máy chủ DHCP cục bộ đã cấp. Các giao diện đường hầm trên hai cổng mang địa chỉ liên kết riêng của chúng, và bảng định tuyến quyết định cách các gói tin di chuyển. Địa chỉ của máy khách truy cập từ xa là hạng mục thứ ba và không nên trộn với địa chỉ liên kết của cổng.

Bắc cầu đường hầm vào LAN loại bỏ sự tách biệt đó. Nếu thiết kế thực sự cần một miền quảng bá duy nhất, điểm cuối VPN phải tham gia vào cùng các quyết định cấp phát như máy chủ DHCP, thông qua bộ chuyển tiếp hoặc nguồn có thẩm quyền dùng chung, thay vì tự phát hành địa chỉ.

Xác minh tiến trình nào sở hữu địa chỉ

Chứng minh quyền sở hữu trước khi thay đổi một phạm vi. Trên máy khách, ghi lại địa chỉ và tiền tố. Trong LAN, tìm trong cơ sở dữ liệu thuê. Trên cổng, liệt kê các nhóm mà nó được cấu hình để phát. Một địa chỉ tìm thấy trong tệp thuê thuộc về máy chủ DHCP, nghĩa là đường hầm được bắc cầu hoặc chuyển tiếp; một địa chỉ chỉ tìm thấy trong nhóm của cổng thuộc về điểm cuối đường hầm.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Ghi lại bốn điều khi câu trả lời đã rõ: thành phần nào cấp địa chỉ cho máy khách, dải nào được dành riêng cho nó, lưu lượng quay về đến dải đó bằng cách nào và tài nguyên nào chấp nhận nó. Bốn mục đó biến một dòng của bộ điều hợp ảo thành một sự thật vận hành.

Lặp lại kiểm tra cho thuộc tính DNS khi bạn còn ở đó. Một nhóm phát địa chỉ nhưng không có bộ phân giải sẽ để máy khách ở DNS cục bộ của nó, đó là một lỗi khác với nhóm phát một địa chỉ mà LAN đã dùng.