OpenVPN mijozlari bir-birini ko'rmaydi: subnet yoki net30?

Mijozlar serverga yetadi, lekin bir-biriga yetmaydi. Nosozlikni bitta ping bilan ajrating, so'ng subnet topologiyasini, client-to-client yoki ko'prik qilingan TAP segmentini tanlang.

Bir-biriga bog'liq bo'lmagan ikki nosozlik bir xil shikoyat beradi. Birinchisida bir mijoz boshqasiga tunnel manzili bilan ham yetmaydi, chunki manzillar bitta subnetda emas yoki server tengdoshlar orasidagi trafikni uzatmaydi. Ikkinchisida ping ishlaydi, lekin ilovadagi qurilmalar ro'yxati bo'sh qoladi, chunki aniqlash 3-qatlam tunnel ko'tara olmaydigan broadcastga tayanadi. Bitta ping ularni ajratadi va har birining tuzatishi boshqasining tuzatishiga umuman o'xshamaydi.

Bitta ping muammoni ikkiga bo'ladi

Bitta mijozdan boshqa mijozning tunnel manziliga ping yuboring, uning nomiga emas va LAN manziliga emas. Agar bu muvaffaqiyatsiz bo'lsa, uzatish yoki manzillash muammo va u tuzatilmaguncha aniqlash ahamiyatsiz. Agar muvaffaqiyatli bo'lsa, uzatish allaqachon ishlaydi va qolgan bo'shliq broadcast yoki nomlarni hal qilishdir.

ip addr show tun0

Hamma narsadan oldin mijoz interfeysini o'qing, chunki topologiyani tarmoq maskasi nomlaydi. /24 yoki boshqa subnet maskasi umumiy hovuz demakdir; tengdosh manzili bilan /30 esa eski nuqta-nuqtaga sxemasi, unda har bir mijozning aynan bitta qo'shnisi bor, server.

net30 va subnet, mijoz tomondan o'qilganda

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

net30 da server har bir mijozga kichik blok beradi, shuning uchun server uni uzatmasa, boshqa mijozning tunnel manziliga marshrut yo'q. subnet da butun hovuz bitta tarmoq, har bir mijoz har kimga murojaat qila oladi va server ular orasida uzatadi. Shuning uchun bitta server konfiguratsiyasi sog'lom ko'rinishi mumkin, lekin tengdoshlar orasidagi ping muvaffaqiyatsiz bo'ladi: hech narsa buzilmagan, mijozlar shunchaki bir tarmoqda emas. Mijoz ishlayotgan ulanishni va javob bermaydigan tengdosh manzilini ko'radi, bu xuddi firewall kabi o'qiladi, aslida esa manzillash sxemasi.

Direktivani almashtirish server tomonidagi tahrir va qayta ishga tushirish, va u allaqachon ochilgan sessiyalarga emas, keyingi ulanishga taalluqli. O'zgarishni baholashdan oldin mijozlarni qayta ulang. Agar qurilma konfiguratsiyani veb-interfeysdan qayta yaratsa, direktiva, fayl va sanani yozib qo'ying, va interfeys bo'lsa tahrirni o'sha orqali qiling, chunki qayta qurish keyingi saqlashda qo'lda qilingan tahrirni ustiga yozadi.

client-to-client alohida darvoza

Bir subnet ichida ham server bir mijozdan kelgan va boshqasiga yo'naltirilgan paketlarni client-to-client o'rnatilmagan bo'lsa tashlab yuboradi. Bu kalit so'z serverni faqat qabul qiluvchi oxirgi nuqta emas, tengdoshlar trafigining uzatuvchisiga aylantiradi. Topologiyani tuzatgandan keyin odamlar o'tkazib yuboradigan ikkinchi shart shu.

Bu broadcastga taalluqli emas. Sozlama mijozlar orasida unicast uzatadi; u tunnelni umumiy segmentga aylantirmaydi, va uning qancha bo'lishidan qat'i nazar multicast aniqlash so'rovini har bir tengdoshga yetkazmaydi.

TUN va TAP, va har biri nimani ko'tara oladi

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

tap qurilmasini LANga ko'prik qilish uzoq mijozlarni ofis broadcast domeniga qo'yadi, bu esa aniqlashni butunlay hal qiladi. Narxi TAPni joriy qilmaydigan platformalar, serverda mavjud bo'lishi shart ko'prik va ofis kabelidagi broadcast bo'roni har bir uzoq noutbukka yetadigan nosozlik domenidir.

Nomlarni hal qilish kerak bo'lgan ikki yoki uch ish stansiyasi uchun hosts yozuvi yoki unicast manzil ko'prikdan ancha arzon. TAPga almashtira olmaydigan protokol 2-qatlam aniqlashiga bog'liq bo'lgandagina murojaat qiling, undan oldin emas.

Ko'priksiz bir subnet mijozlari

LAN diapazonidan manzil berish mijozni kabelga qo'ymaydi. Server tunnel va Ethernet orasida marshrutlaydi, shuning uchun o'sha manzil uchun ARP server interfeysida to'xtaydi va LANning qolgani uning qayerda yashashini hech qachon bilmaydi.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP bu bo'shliqni yopadi: server mijoz nomidan javob beradi. Diapazon uchun parpd yozuvlarni mijozlar kelib-ketganda boshqaradi, sysctl net.ipv4.conf.eth0.proxy_arp=1 esa boshqa joyga marshrutlanadigan hamma narsaga javob beradi, bu gavjum segmentda o'z kutilmagan hodisalarini yaratish uchun yetarlicha keng.

Qaysi yo'lni tanlamang, tunnel va kabel orasidan NATni olib tashlang. MASQUERADE qoidasi siz javob bermoqchi bo'lgan manzillash savolini aynan yashiradi. U keyingi odamga mijoz tomonidan o'ylab bo'lmaydigan topologiyani ham qoldiradi.

Biror narsani o'zgartirishdan oldin serverda tcpdump -ni tun0 bilan bitta urinishni ushlang va tengdosh paketi umuman kelayotganini tasdiqlang. Kelib tashlansa client-to-clientga ishora qiladi; hech qachon kelmasa topologiya yoki marshrutlashga. OpenVPN 2.6 qo'llanmasi ikkala kalit so'zni va standart topologiyani hujjatlashtiradi, forum postidan satr ko'chirishdan oldin uni o'z versiyangiz bilan solishtirish arziydi.

  • tun interfeysi /30 tengdosh juftligi o'rniga hovuz maskasini ko'rsatadi.
  • Aniqlashni sinashdan oldin boshqa tunnel manziliga to'g'ridan-to'g'ri ping muvaffaqiyatli bo'ladi.
  • Tengdoshlar paket almashishi kerak bo'lganda server konfiguratsiyasida client-to-client bo'ladi.
  • Ilova muvaffaqiyatsiz deb aytish o'rniga sinab ko'rayotgan aniqlash protokolini nomlang.
  • TAPni faqat guruhdagi har bir mijoz platformasi qo'llab-quvvatlasa ishlating.
  • Bir subnet ichidagi yetib borish muhim bo'lsa, NATni tunnel va LAN orasidagi yo'ldan tashqarida tuting.

O'xshash maqolalar