Vì sao hai site cùng một subnet không phải là một LAN

Hai văn phòng cùng dùng 192.168.77.0/24, và ai đó đề xuất một đường hầm để chúng thành một mạng. Câu nói nghe đơn giản nhưng che giấu ba thiết kế khác nhau: hai LAN độc lập xung đột nhau, một phân đoạn Ethernet cố ý kéo dài qua WAN, và một cách bố trí proxy-ARP trả lời thay cho các địa chỉ ở xa. Bạn có loại nào sẽ quyết định máy chủ làm gì với gói tin, và câu trả lời hiện ra trước khi cổng VPN tham gia.

Máy chủ quyết định trước bộ định tuyến

Máy chủ có địa chỉ 192.168.77.10/24 so sánh đích với tiền tố của chính nó. Mọi thứ nằm trong tiền tố đó đều ở trên liên kết trực tiếp, nên máy chủ tự phân giải địa chỉ lớp liên kết của đích. Mọi thứ nằm ngoài sẽ đi tới cổng mặc định.

Quyết định đó diễn ra trong ngăn xếp của máy chủ, không phải trong đường hầm. Một tuyến thêm trên cổng không thể cứu gói tin mà máy chủ không bao giờ gửi tới đó.

Vì vậy khi 192.168.77.20 chỉ tồn tại ở site kia, máy chủ cục bộ hỏi nó qua ARP và không nhận được trả lời. Bắt tay VPN có thể hoàn toàn khỏe mạnh trong khi việc này thất bại. Sự cố trông như một máy chủ đã chết chứ không phải vấn đề định tuyến. Nhận ra dấu hiệu đó tiết kiệm một giờ gỡ lỗi đường hầm.

ARP là câu hỏi của liên kết cục bộ

ARP hỏi ai sở hữu một địa chỉ trên liên kết này, và câu trả lời phải đến từ thứ gì đó nghe được quảng bá. Một bộ định tuyến ở đầu kia của đường hầm IPsec không nghe thấy trừ khi thiết kế biến hai site thành một miền quảng bá duy nhất.

Hai thiết bị cùng địa chỉ làm tình hình tệ hơn: ngay cả phân giải thành công cũng không cho biết thiết bị nào đã trả lời.

Đánh địa chỉ trùng lặp không phải lỗi định tuyến và không tuyến nào sửa được. Hoặc các site được đánh số lại vào các tiền tố khác nhau, hoặc chúng cố ý trở thành một miền lớp liên kết duy nhất.

Phân đoạn kéo dài mang khung, không mang tuyến

Một đường hầm mang Ethernet và nối với các cầu nối khiến cả hai site thành một phần của một miền lớp liên kết. Quảng bá ARP tới được phía bên kia, và mỗi cầu nối học được địa chỉ MAC nào ở đâu. Tài liệu về cầu nối trong Linux mô tả ranh giới chuyển tiếp dựa trên MAC đó.

Ở đây cổng ở xa hoàn toàn không định tuyến giữa hai subnet giống nhau. Các khung đi qua một lớp nền tự định tuyến IP, trong khi các cầu nối kéo dài cuộc trò chuyện Ethernet.

Cái giá là bán kính ảnh hưởng lớn hơn. Việc tràn tới các đích không xác định, vòng lặp, cấp phát DHCP và đánh địa chỉ duy nhất đều cần một kế hoạch bao trùm cả hai site. Khi WAN sập, máy chủ mất lưu lượng mà chúng coi là cục bộ. Lọc trên cầu nối và các quy tắc VLAN có thể hạn chế thứ đi qua, nhưng việc mang tải vẫn không hứa rằng mọi khung điều khiển cục bộ đều tới nơi.

Proxy ARP là thiết kế thứ ba

Bộ định tuyến có thể trả lời ARP cho một địa chỉ ở xa rồi định tuyến tới đó. Điều này khiến máy chủ ở xa trông như ở trên liên kết trực tiếp đối với bên gửi mà không kéo dài miền quảng bá.

Đây là công cụ hẹp hơn cầu nối: nó phụ thuộc vào chuyển tiếp, các tuyến quay về và chủ sở hữu rõ ràng cho từng địa chỉ.

Nó cũng không làm cho các giao thức không phải IP tùy ý có thể định tuyến, và không tái tạo một miền quảng bá Ethernet. Hãy dùng nó khi yêu cầu đúng là sự thay thế đó, không phải như lối tắt cho việc đánh số lại bị hoãn.

Chọn theo yêu cầu, rồi kiểm chứng

Đối với truy cập ứng dụng thông thường giữa các văn phòng, các tiền tố khác nhau và tuyến rõ ràng cho một ranh giới rõ hơn. Hãy làm cầu nối khi yêu cầu thực sự là lân cận lớp liên kết. Hãy đánh số lại khi lý do duy nhất của tiền tố dùng chung là chưa ai làm việc đó.

Xác nhận thiết kế nào bạn thực sự có bằng cách hỏi máy chủ xem nó làm gì với đích:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Kết quả trên liên kết trực tiếp với mục lân cận thất bại chỉ ra một đường lớp liên kết bị thiếu. Kết quả via nêu tên cổng và chuyển câu hỏi sang định tuyến. Trên cầu nối, kiểm tra cơ sở dữ liệu chuyển tiếp để xem MAC có được học qua đường hầm không. Mỗi đầu ra thu hẹp câu hỏi thiết kế thay vì bắt đầu lại.