Hai lỗi không liên quan tạo ra cùng một phàn nàn. Ở trường hợp đầu, một máy khách không đến được máy khác ngay cả bằng địa chỉ tunnel, vì các địa chỉ không nằm trong cùng một subnet hoặc máy chủ không chuyển tiếp lưu lượng giữa các máy ngang hàng. Ở trường hợp sau, ping hoạt động nhưng danh sách thiết bị của ứng dụng vẫn trống, vì việc phát hiện dựa vào broadcast mà một tunnel lớp 3 không thể mang được. Một ping phân tách hai trường hợp, và cách sửa của mỗi bên không giống chút nào cách sửa của bên kia.

Một ping chia đôi vấn đề

Từ một máy khách, ping địa chỉ tunnel của máy kia, không phải tên và không phải địa chỉ LAN của nó. Nếu thất bại, chuyển tiếp hoặc đánh địa chỉ là vấn đề và việc phát hiện không còn liên quan cho đến khi sửa xong. Nếu thành công, chuyển tiếp đã hoạt động và phần còn thiếu là broadcast hoặc phân giải tên.

ip addr show tun0

Hãy đọc giao diện của máy khách trước mọi thứ, vì mặt nạ mạng đặt tên cho cấu trúc. /24 hay mặt nạ subnet khác nghĩa là một nhóm dùng chung; /30 có địa chỉ ngang hàng là cách bố trí điểm-đến-điểm cũ, trong đó mỗi máy khách có đúng một hàng xóm, máy chủ.

net30 so với subnet, đọc từ phía máy khách

What you observenet30subnet
Client netmask/30 with a peer addressThe pool's own mask
Peers a client can address directlyOne, the serverEvery client in the pool
AddressingOne /30 block per client, with the server as the only peerOne pool mask shared by all clients
Effect of client-to-clientRequired for any peer trafficRequired for peer traffic, still no broadcast

Với net30 máy chủ cấp một khối nhỏ cho mỗi máy khách, nên không có tuyến đến địa chỉ tunnel của máy khách khác trừ khi máy chủ chuyển tiếp. Với subnet cả nhóm là một mạng, mỗi máy khách có thể gọi mọi máy khác, và máy chủ chuyển tiếp giữa chúng. Vì thế một cấu hình máy chủ có thể trông khỏe mạnh trong khi ping giữa các máy ngang hàng thất bại: không có gì hỏng, các máy khách đơn giản là không ở trong một mạng. Máy khách thấy một liên kết hoạt động và một địa chỉ ngang hàng không trả lời, điều này đọc như tường lửa nhưng thực ra là cách bố trí địa chỉ.

Đổi chỉ thị là sửa ở phía máy chủ cộng khởi động lại, và nó áp dụng cho kết nối kế tiếp chứ không cho các phiên đã mở. Kết nối lại máy khách trước khi đánh giá thay đổi. Nếu thiết bị tạo lại cấu hình từ giao diện web, hãy ghi lại chỉ thị, tệp và ngày, và sửa qua giao diện khi có, vì việc dựng lại sẽ ghi đè chỉnh sửa thủ công ở lần lưu sau.

client-to-client là một cổng riêng

Ngay trong một subnet, máy chủ vẫn bỏ các gói đến từ một máy khách và hướng tới máy khác trừ khi client-to-client được đặt. Từ khóa đó biến máy chủ thành bộ chuyển tiếp lưu lượng giữa các máy ngang hàng thay vì một điểm cuối chỉ nhận nó. Đó là điều kiện thứ hai mà người ta bỏ sót sau khi sửa cấu trúc.

Điều này không mở rộng tới broadcast. Cấu hình chuyển tiếp unicast giữa các máy khách; nó không biến tunnel thành một đoạn chia sẻ, và dù đặt bao nhiêu cũng không đưa truy vấn phát hiện multicast tới mọi máy ngang hàng.

TUN so với TAP, và mỗi loại mang được gì

PropertyTUNTAP
LayerLayer 3, IP packetsLayer 2, Ethernet frames
Broadcast and multicastNot carriedCarried
Bridging to the LANNot applicableRequired for a shared segment
Client platform supportEverywhereMissing on Android and iOS, limited on macOS

Bắc cầu một thiết bị tap vào LAN đưa các máy khách từ xa vào miền broadcast của văn phòng, điều này giải quyết hoàn toàn việc phát hiện. Cái giá là các nền tảng không triển khai TAP, một cầu nối phải tồn tại trên máy chủ, và một miền hỏng nơi bão broadcast trên cáp văn phòng chạm tới mọi máy tính xách tay từ xa.

Với hai hoặc ba máy trạm cần phân giải tên, một mục hosts hoặc một địa chỉ unicast rẻ hơn nhiều so với một cầu nối. Hãy dùng TAP khi một giao thức bạn không thể thay thế phụ thuộc vào phát hiện lớp 2, và không sớm hơn.

Máy khách cùng subnet không có cầu nối

Gán một địa chỉ trong dải LAN không đưa máy khách lên cáp. Máy chủ định tuyến giữa tunnel và Ethernet, nên ARP cho địa chỉ đó dừng ở giao diện máy chủ và phần còn lại của LAN không bao giờ biết nó sống ở đâu.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP bịt khoảng trống đó bằng cách để máy chủ trả lời thay máy khách. Với một dải, parpd quản lý các mục khi máy khách đến và đi, trong khi sysctl net.ipv4.conf.eth0.proxy_arp=1 trả lời cho mọi thứ được định tuyến đi nơi khác, đủ rộng để tạo ra những bất ngờ riêng trên một đoạn bận rộn.

Dù chọn đường nào, hãy bỏ NAT giữa tunnel và cáp. Một quy tắc MASQUERADE che đúng câu hỏi đánh địa chỉ mà bạn đang cố trả lời. Nó cũng để lại cho người sau một cấu trúc mà họ không thể suy luận từ phía máy khách.

Trước khi thay đổi bất cứ điều gì, hãy bắt một lần thử trên máy chủ bằng tcpdump -ni tun0 và xác nhận xem gói của máy ngang hàng có đến hay không. Đến rồi bị bỏ chỉ ra client-to-client; không bao giờ đến chỉ ra cấu trúc hoặc định tuyến. Hướng dẫn OpenVPN 2.6 ghi lại cả hai từ khóa và cấu trúc mặc định, điều đáng đối chiếu với phiên bản của bạn trước khi sao chép một dòng từ bài đăng diễn đàn.

  • Giao diện tun hiển thị mặt nạ nhóm chứ không phải cặp ngang hàng /30.
  • Ping trực tiếp tới địa chỉ tunnel kia thành công trước khi bạn kiểm tra phát hiện.
  • Cấu hình máy chủ bao gồm client-to-client mỗi khi các máy ngang hàng phải trao đổi gói.
  • Hãy nêu tên giao thức phát hiện bạn đang kiểm tra thay vì nói ứng dụng thất bại.
  • Chỉ dùng TAP nếu mọi nền tảng máy khách trong nhóm hỗ trợ nó.
  • Giữ NAT ra khỏi đường đi giữa tunnel và LAN khi khả năng tiếp cận trong cùng subnet là quan trọng.

Bài viết liên quan