Bể địa chỉ VPN của bạn không phải dải DHCP của LAN: vì sao nó hỏng

Lối tắt hấp dẫn là cấp cho máy khách VPN địa chỉ từ cùng dải mà máy chủ DHCP của văn phòng dùng, với lý thuyết rằng dù sao tất cả cũng là một mạng. Không phải vậy. Đường hầm định tuyến mang gói unicast giữa hai đầu, trong khi bể của LAN tồn tại để trả lời các yêu cầu quảng bá trên một phân đoạn vật lý. Dùng lại các con số đặt hai bộ cấp phát chịu trách nhiệm cho một không gian địa chỉ và để tuyến quay về không được xác định.

Hai bộ cấp phát, một không gian địa chỉ

Máy chủ DHCP của LAN biết mình đã cho thuê địa chỉ nào và cho địa chỉ MAC nào, và bảo vệ chúng bằng ARP. Máy chủ VPN có bể riêng và không biết gì về những hợp đồng thuê đó. Cả hai đều không sai; chỉ là chúng chưa bao giờ được giới thiệu với nhau.

Một địa chỉ từ bể của LAN mà máy chủ VPN cấp có thể đã thuộc về một máy in. Giờ hai thiết bị cùng đòi một địa chỉ trên cùng tiền tố, và bảng chuyển tiếp của switch quyết định thiết bị nào trả lời.

Đó là sự cố mà người ta gặp đầu tiên: một máy khách kết nối thành công rồi đi đến nhầm máy, hoặc đến đúng máy một cách chập chờn.

Vì sao router không cấp địa chỉ VPN

Việc dò tìm DHCP là một quảng bá, và quảng bá dừng ở ranh giới định tuyến. Trừ khi thiết kế bắc cầu đường hầm hoặc chạy một relay DHCP có thẩm quyền tương ứng, yêu cầu của máy khách không bao giờ đến được máy chủ của LAN.

Vì thế máy chủ VPN tự gán địa chỉ: một bể trong cấu hình máy chủ, một địa chỉ cho mỗi peer trong một thiết lập WireGuard, hoặc một địa chỉ do tầng xác thực đẩy xuống trong một triển khai IKEv2. Những cơ chế này độc lập với cơ sở dữ liệu thuê của LAN, và chính vì thế chúng cần một dải riêng.

Cùng lý lẽ đó giải thích vì sao đổi phạm vi DHCP không sửa được một máy khách VPN không bao giờ nhận được địa chỉ. Máy khách không hỏi máy chủ của LAN, và không mức chỉnh sửa phạm vi nào khiến nó hỏi.

Sự trùng lặp hiện ra như một xung đột, không phải một mạng chậm

Hai mạng dùng chung một tiền tố mà không có thiết kế được hỗ trợ là vấn đề khác với sở hữu trùng, và chúng thường bị nhầm lẫn. Nếu bể VPN là một tiền tố riêng, trùng lặp chỉ quan trọng khi một tuyến gửi lưu lượng sang phía sai. Nếu bể nằm trong tiền tố của LAN, xung đột là tức thời và cục bộ.

Trong thực tế bạn thấy các phản hồi ARP từ thiết bị sai, các kết nối bị đặt lại giữa chừng, và một máy khách mà địa chỉ của chính nó bị người khác đòi. Không điều nào trong số đó trông giống vấn đề định tuyến, nên bản sửa được áp ở tầng sai. Một hợp đồng thuê trùng thì dễ xác nhận và khó chịu khi sống chung. Nó cũng tồn tại qua các lần khởi động lại, vì cả hai bộ cấp phát vẫn khăng khăng giữ cùng một địa chỉ.

Tuyến quay về là vấn đề riêng

Ngay cả với một bể sạch và riêng, các máy chủ của LAN cần biết cách trả lời một máy khách. Cổng mặc định của chúng là router, và router cần một tuyến cho bể trỏ tới máy chủ VPN, trừ khi thiết kế dịch lưu lượng của máy khách thay vào đó.

Đọc tuyến theo cả hai chiều trước khi thay đổi bất cứ điều gì. Trên cổng, hỏi nhân sẽ dùng giao diện nào cho một địa chỉ máy khách; trên máy khách, hỏi nó dùng tuyến nào cho một địa chỉ của LAN.

Các lệnh này cho thấy quyết định chuyển tiếp trên cổng và các mục lân cận tiết lộ một bản trùng:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Nếu lệnh đầu tiên trả lời bằng giao diện đường hầm, tuyến quay về tồn tại. Nếu nó trả lời bằng giao diện của LAN, router tin rằng máy khách đang ở trên dây và sẽ cố gắng ARP cho nó.

Có những thiết kế bắc cầu, nhưng phải được chọn

Bắc cầu một đường hầm vào LAN là một thiết kế thật, dùng khi máy khách phải nhận quảng bá hoặc phải được các giao thức giả định một phân đoạn phát hiện. Nó đòi hỏi máy chủ sở hữu hành vi bắc cầu đó và việc xử lý địa chỉ đi kèm.

Điều không hiệu quả là bắt chước kết quả bằng cách sao chép các con số. Một bể dùng chung không có cầu cho bạn xung đột mà không có phát hiện, đó là điều tệ nhất trong cả hai cách sắp đặt.

Chọn tầng ba với một bể riêng trừ khi ứng dụng thực sự cần phân đoạn đó, và ghi lại bể để người quản trị tiếp theo không dùng lại dải DHCP chỉ vì gọn gàng.