DHCP qua VPN: bắc cầu broadcast hay chuyển tiếp nó?

Một laptop mới ở phía bên kia đường hầm không nhận được địa chỉ, trong khi chính laptop đó hoạt động tại trụ sở chính. Phỏng đoán đầu tiên thường là đường hầm đang chặn DHCP. Thường gặp hơn là broadcast chưa từng có đường đi: máy khách chưa được cấu hình gửi tới 255.255.255.255, và một router IP thông thường không chuyển tiếp gói đó. Đường hầm chỉ đang làm đúng việc một đường hầm định tuyến làm.

Hai thiết kế có thể thay đổi điều đó, và chúng không tương đương. Một bên mang broadcast; bên kia chuyển tiếp yêu cầu.

Broadcast không bao giờ đi qua router

Máy khách DHCPv4 không có địa chỉ gửi từ 0.0.0.0 tới địa chỉ broadcast giới hạn trên cổng UDP 67 và 68. Gói đó ở lại trên đường liên kết của nó theo thiết kế. Một router chuyển tiếp nó sẽ làm ngập mọi phân đoạn mà nó phục vụ.

Vì vậy một đường hầm định tuyến site-to-site nối relay với máy chủ. Nó không mở rộng miền broadcast của máy khách, và không quy tắc tường lửa nào làm được điều đó.

Đường hầm bắc cầu thực sự mở rộng điều gì

Một VPN được bắc cầu có chủ đích có thể mang broadcast Ethernet trong phạm vi tô-pô được hỗ trợ, và khi đó DHCP có thể đi qua như lưu lượng nội bộ. Đó là một lựa chọn thật, nhưng là quyết định thiết kế lớp 2. Bạn đang mở rộng miền sự cố và ranh giới truy cập cùng với broadcast.

Bắc cầu cũng thay đổi phạm vi mà một cơn bão broadcast, một lần quét ARP hay một máy chủ DHCP giả có thể chạm tới. Nếu bạn không cắm văn phòng từ xa vào cùng một switch, đừng bắc cầu đường hầm chỉ để cấp địa chỉ. Hãy thử bán kính ảnh hưởng đó trước khi bật.

Đây là quyết định lớn hơn việc cấp một địa chỉ, và cần được đưa ra một cách có chủ đích.

Thay vào đó hãy chuyển tiếp yêu cầu

Câu trả lời thông thường là một relay trên mạng nội bộ của máy khách. Nó nhận broadcast, biến thành yêu cầu unicast và đặt địa chỉ của chính nó vào trường địa chỉ cổng. Máy chủ trả lời tới địa chỉ relay đó.

Với một văn phòng từ xa làm ví dụ, relay nằm trên LAN của văn phòng và máy chủ được truy cập qua VPN của site. Hãy cấu hình phạm vi cho văn phòng đó, danh tính của relay và máy chủ, cùng đường trả về đầy đủ. Việc cho phép UDP 67 qua đường hầm không cho máy chủ biết phải dùng pool nào.

Một relay chuyển tiếp nhưng không bao giờ nhận được trả lời thường là vấn đề đường trả về. Hãy kiểm tra tuyến về địa chỉ relay trước khi thay đổi phạm vi.

Tách DHCP khỏi ARP và khỏi địa chỉ đường hầm

DHCP chạy trên UDP/IP. Trên Ethernet, một máy chủ cũng có thể dùng ARP để kiểm tra xem địa chỉ ứng viên đã được dùng chưa. Việc kiểm tra xung đột đó là một thao tác cục bộ trên liên kết riêng, không phải phương tiện vận chuyển thông điệp DHCP. Nói DHCP bản chất là ARP là sai; nói hai thứ không bao giờ liên quan là quá rộng.

Máy khách VPN cũng có thể lấy địa chỉ đường hầm từ giao thức VPN hoặc từ pool của chính máy chủ thay vì từ broadcast DHCP. Một tùy chọn có DHCP trong tên có thể mô tả các thiết lập máy khách được đẩy xuống, không phải gói DHCP được chuyển tiếp. Hãy kiểm tra pool của máy chủ trước khi cho rằng DHCP có liên quan.

Ghi lại mạng nhận, chủ sở hữu cấp phát, phạm vi, có relay hay không và hành vi mong đợi khi xảy ra sự cố. Sau đó thử một hợp đồng thuê mới và một lần gia hạn theo mô hình đó. Nếu hai site có thể phục vụ cùng một pool không được quản lý, bạn có một xung đột đang chờ chiếc laptop di động đầu tiên.