OpenVPN клиентүүд бие биеэ хардаггүй: subnet уу net30 уу?
Клиентүүд серверт хүрдэг ч бие биедээ хүрдэггүй. Алдааг нэг ping-ээр ялгаад, дараа нь subnet топологи, client-to-client эсвэл гүүрлэсэн TAP сегментийг сонгоно.
Хоёр хамааралгүй алдаа ижил гомдол үүсгэдэг. Эхнийхэд нэг клиент нөгөөдөө туннелийн хаягаар ч хүрдэггүй, учир нь хаягууд нэг subnet-д биш эсвэл сервер тэнцүү гишүүдийн хооронд урсгалыг дамжуулдаггүй. Хоёрдугаарт ping ажилладаг ч аппын төхөөрөмжийн жагсаалт хоосон хэвээр байдаг, учир нь илрүүлэлт 3-р түвшний туннел дамжуулж чадахгүй broadcast-д тулгуурладаг. Нэг ping тэднийг ялгадаг ба аль нэгийг засах нь нөгөөг засахад огт төсөөтэй биш.
Нэг ping асуудлыг хоёр хуваана
Нэг клиентээс нөгөө клиентийн туннелийн хаяг руу ping хийнэ, нэр рүү нь ч, LAN хаяг руу нь ч биш. Хэрэв бүтэхгүй бол дамжуулалт эсвэл хаяглалт нь асуудал бөгөөд засагдтал илрүүлэлт хамаагүй. Хэрэв бүтвэл дамжуулалт аль хэдийн ажиллаж байгаа бөгөөд үлдсэн зөрүү нь broadcast эсвэл нэрийн шийдэл.
ip addr show tun0Бусад бүхнээс өмнө клиентийн интерфейсийг уншина, учир нь сүлжээний маск топологийг нэрлэдэг. /24 эсвэл өөр subnet маск нь хуваалцсан сан гэсэн үг; тэнцүү гишүүний хаягтай /30 нь хуучин цэг-цэг зохион байгуулалт бөгөөд клиент бүр яг нэг хөрштэй, тэр нь сервер.
net30 subnet-ийн эсрэг, клиентийн талаас уншсан
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30 үед сервер клиент бүрт жижиг блок олгодог, тиймээс сервер дамжуулахгүй бол өөр клиентийн туннелийн хаяг руу маршрут байхгүй. subnet үед бүхэл сан нэг сүлжээ, клиент бүр бүгдэд хандаж чадна, сервер тэдний хооронд дамжуулна. Тиймээс нэг серверийн тохиргоо эрүүл харагдаж байтал тэнцүү гишүүдийн хоорондын ping бүтэлгүйтдэг: юу ч эвдээгүй, клиентүүд зүгээр л нэг сүлжээнд байхгүй. Клиент ажиллаж буй холбоос болон хариу өгөхгүй тэнцүү гишүүний хаягийг хардаг бөгөөд энэ нь firewall мэт уншигддаг ч үнэндээ хаяглалтын зохион байгуулалт юм.
Директивыг солих нь серверийн талын засвар ба дахин эхлүүлэлт бөгөөд аль хэдийн нээгдсэн сессүүдэд биш, дараагийн холболтод үйлчилнэ. Өөрчлөлтийг үнэлэхээс өмнө клиентүүдийг дахин холбоно. Хэрэв төхөөрөмж тохиргоог вэб интерфейсээс дахин үүсгэдэг бол директив, файл, огноог тэмдэглээд, интерфейс байгаа үед засварыг түүгээр хийнэ, учир нь дахин бүтээх нь дараагийн хадгалалтад гараар хийсэн засварыг дарж бичнэ.
client-to-client нь тусдаа хаалга
Нэг subnet дотор ч сервер нэг клиентээс ирж нөгөө рүү хаяглагдсан пакетуудыг client-to-client тохируулаагүй бол хаядаг. Энэ түлхүүр үг серверийг зөвхөн хүлээн авагч төгсгөлийн цэгээс илүү тэнцүү гишүүдийн урсгалын дамжуулагч болгоно. Топологийг зассаны дараа хүмүүсийн алддаг хоёр дахь нөхцөл энэ.
Энэ нь broadcast руу үргэлжлэхгүй. Тохиргоо нь клиентүүдийн хооронд unicast дамжуулдаг; туннелийг хуваалцсан сегмент болгодоггүй бөгөөд түүний ямар ч хэмжээ multicast илрүүлэлтийн асуулгыг тэнцүү гишүүн бүрт хүргэхгүй.
TUN TAP-ийн эсрэг, аль нь юу дамжуулж чадах вэ
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap төхөөрөмжийг LAN руу гүүрлэх нь алслагдсан клиентүүдийг оффисын broadcast домэйнд оруулдаг бөгөөд энэ нь илрүүлэлтийг бүрэн шийднэ. Үнэ нь TAP-г хэрэгжүүлдэггүй платформууд, сервер дээр байх ёстой гүүр, оффисын кабель дээрх broadcast шуурга алслагдсан зөөврийн компьютер бүрт хүрдэг эвдрэлийн домэйн юм.
Нэрийн шийдэл хэрэгтэй хоёр гурван ажлын станцад hosts бичлэг эсвэл unicast хаяг гүүрнээс хамаагүй хямд. Танд сольж болохгүй протокол 2-р түвшний илрүүлэлтээс хамаарах үед л TAP руу тэмүүл, түүнээс өмнө биш.
Гүүргүй ижил subnet-ийн клиентүүд
LAN хүрээнээс хаяг өгөх нь клиентийг кабель дээр тавьдаггүй. Сервер туннел ба Ethernet-ийн хооронд чиглүүлдэг тул тэр хаягийн ARP серверийн интерфейс дээр зогсдог ба LAN-ийн үлдсэн хэсэг түүнийг хаана амьдардагийг хэзээ ч мэдэхгүй.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP энэ зөрүүг хаадаг: сервер клиентийн өмнөөс хариулдаг. Хүрээний хувьд parpd клиентүүд ирж явах үед бичлэгүүдийг удирдана, sysctl net.ipv4.conf.eth0.proxy_arp=1 нь өөр тийш чиглүүлэгдсэн бүхэнд хариулдаг бөгөөд энэ нь завгүй сегмент дээр өөрийн гэсэн гэнэтийн зүйлсийг бий болгоход хангалттай өргөн.
Аль замыг сонгосон ч туннел ба кабелийн хоорондох NAT-г арилга. MASQUERADE дүрэм нь таны хариулахыг оролдож буй хаяглалтын асуултыг яг нуудаг. Энэ нь дараагийн хүнд клиентийн талаас бодож чадахгүй топологийг үлдээдэг.
Ямар нэг зүйлийг солихоос өмнө сервер дээр tcpdump -ni tun0-ээр нэг оролдлогыг барьж, тэнцүү гишүүний пакет ер нь ирж байгаа эсэхийг батал. Ирээд хаягдвал client-to-client рүү заана; огт ирэхгүй бол топологи эсвэл чиглүүлэлт рүү. OpenVPN 2.6 гарын авлага хоёр түлхүүр үг болон өгөгдмөл топологийг баримтжуулдаг бөгөөд форумын нийтлэлээс мөр хуулахаас өмнө өөрийн хувилбартайгаа тулгах нь зүйтэй.
- tun интерфейс /30 тэнцүү гишүүний хосын оронд сангийн маскыг харуулна.
- Илрүүлэлтийг шалгахаас өмнө нөгөө туннелийн хаяг руу шууд ping амжилттай болно.
- Тэнцүү гишүүд пакет солилцох шаардлагатай үед серверийн тохиргоонд
client-to-clientбайдаг. - Апп бүтэлгүйтдэг гэхийн оронд шалгаж буй илрүүлэлтийн протоколоо нэрлэ.
- Бүлгийн клиент платформ бүр дэмжсэн тохиолдолд л TAP ашигла.
- Нэг subnet доторх хүртээмж чухал үед NAT-г туннел ба LAN-ийн хоорондох замаас гадуур байлга.