Vì sao máy chủ LAN gửi ARP cho địa chỉ của một máy khách OpenVPN

Các vấn đề về khả năng tiếp cận giữa máy chủ LAN và máy khách VPN thường quay về chính quy hoạch địa chỉ. Gán cho máy chủ đó một giao diện trên 10.0.100.0/22 và nó sẽ coi mọi địa chỉ từ 10.0.100.0 đến 10.0.103.255 là kết nối trực tiếp, kể cả một nhóm máy khách được đặt lặng lẽ tại 10.0.101.0/24. Câu trả lời không bao giờ đi tới bộ định tuyến, vì theo góc nhìn của máy chủ không có bộ định tuyến nào tham gia. Gói tin được gửi tới một máy lân cận và được hỏi trên đường dây.

Cơ chế đó nằm sau cả một nhóm báo cáo: đường hầm đang hoạt động, máy chủ có tuyến đường, vậy mà máy chủ LAN vẫn không chạm tới máy khách.

Tiền tố /22 nuốt mất /24

Hãy đọc tiền tố như một dải, không phải một chuỗi. Một /22 chứa 1024 địa chỉ, và 10.0.100.0/22 trải từ 10.0.100.0 đến 10.0.103.255, nên một nhóm tại 10.0.101.0/24 nằm hoàn toàn bên trong. Sai sót này sống sót qua bước rà soát vì các octet đầu của nhóm trông khác các octet đầu của LAN, và chỉ octet thứ ba mới để lộ sự bao trùm. Hãy viết cả hai dải bằng số trước khi tuyên bố chúng tách rời.

Sự bao trùm tương tự cũng có thể xuất hiện theo chiều ngược lại. Một nhóm trông như còn trống vì hiện không ai dùng vẫn có thể rơi vào một tiền tố mà một bộ định tuyến tại chỗ quảng bá, và quy hoạch địa chỉ là tài liệu duy nhất cho thấy điều đó.

Kết nối trực tiếp nghĩa là ARP, không phải định tuyến

Khi một máy chủ có giao diện /22 gửi tới 10.0.101.25, nhân hệ điều hành so sánh đích với tiền tố của giao diện và thấy khớp. Gói tin trở thành việc phân giải lân cận thay vì một gói được định tuyến, và trên Ethernet việc phân giải lân cận là một yêu cầu ARP cho địa chỉ đó. Nếu địa chỉ thuộc về một máy khách VPN sau một cổng vào đã định tuyến, không máy chủ nào trong LAN sở hữu nó, nên yêu cầu không được trả lời và các gói bị bỏ. Đường hầm không có lỗi, và máy khách không bao giờ thấy lưu lượng.

Đó là lý do sự cố trông không đối xứng và đôi khi chập chờn. Máy chủ VPN thường chạm tới LAN vì các tuyến riêng của nó chỉ đúng hướng, trong khi máy chủ LAN không thể trả lời, và bất cứ thứ gì lưu đệm một mục ARP cũ đều khiến triệu chứng nhấp nháy.

TUN, TAP và những gì mỗi loại mang

Thiết bị TUN mang gói IP, và thiết bị TAP mang khung Ethernet. Một liên kết TUN đã định tuyến không cần mang ARP để cung cấp khả năng tiếp cận IP, và chính vì thế yêu cầu không được trả lời ở trên là điều đáng mong đợi chứ không phải hỏng. TAP với một cầu nối có chủ đích có thể mở rộng miền quảng bá và làm ARP hoạt động, nhưng nó thay đổi những gì máy khách có thể thấy, đòi hỏi các đầu cuối hỗ trợ cùng kiểu đóng khung, và là một lần thiết kế lại mô hình mạng chứ không phải sửa chữa cho một tiền tố chồng lấn. Chuyển một triển khai đã định tuyến sang TAP để chữa lỗi quy hoạch địa chỉ là đánh đổi một vấn đề nhỏ lấy một vấn đề lớn hơn.

Hãy ghi lại yêu cầu ARP xuất hiện ở đâu và hệ thống nào phát ra nó trước khi kết luận. Bên gửi cho bạn biết nó tin gì về đích, chứ không phải đường hầm làm gì.

Thiết kế một nhóm không thể chồng lấn

Chọn một nhóm nằm ngoài mọi tiền tố đã kết nối và mọi tiền tố tại chỗ được quảng bá, rồi thêm các tuyến đường giúp nó tiếp cận được theo cả hai chiều. Một dải như 10.8.0.0/24 trong phần chưa dùng của quy hoạch rất dễ lý giải, và một LAN cần chạm tới nó sẽ nhận một tuyến tĩnh trỏ tới máy chủ VPN. Hãy thay đổi cùng lúc việc phân bổ, các tuyến được quảng bá, các địa chỉ nguồn được phép và các quy tắc tường lửa, vì chúng mô tả một thiết kế chứ không phải bốn cài đặt.

Source NAT trên máy chủ có thể giấu nhóm sau một địa chỉ định tuyến được từ LAN, và đó là công cụ di trú hợp lệ. Nó cũng viết lại nguồn, nên LAN mất khả năng quy kết kết nối cho từng máy khách và áp quy tắc theo từng máy khách.

Để nghiệm thu, hãy dùng địa chỉ thực sự được cấp cho máy khách thật và một yêu cầu ứng dụng thật từ máy chủ LAN, rồi xác nhận câu trả lời đi theo cổng vào đã hoạch định chứ không theo dây.