OpenVPN müştəriləri bir-birini görmür: subnet, yoxsa net30?
Müştərilər serverə çatır, amma bir-birinə çatmır. Nasazlığı bir ping ilə ayırın, sonra subnet topologiyasını, client-to-client seçimini və ya körpülənmiş TAP seqmentini seçin.
İki əlaqəsiz nasazlıq eyni şikayəti doğurur. Birincisində bir müştəri digərinə hətta tunel ünvanı ilə çatmır, çünki ünvanlar bir subnetdə deyil və ya server qonşu trafiki yönləndirmir. İkincisində ping işləyir, tətbiqin cihaz siyahısı isə boş qalır, çünki kəşf 3-cü qat tunelinin daşıya bilmədiyi yayıma əsaslanır. Bir ping bunları ayırır və hər biri üçün düzəliş digərinin düzəlişinə bənzəmir.
Bir ping problemi ikiyə bölür
Bir müştəridən digər müştərinin tunel ünvanına ping göndərin, adına və LAN ünvanına yox. Əgər uğursuz olarsa, problem yönləndirmə və ya ünvanlamadır və düzəldilənə qədər kəşf əhəmiyyətsizdir. Əgər uğurlu olarsa, yönləndirmə artıq işləyir və qalan boşluq yayım və ya ad həllidir.
ip addr show tun0Hər şeydən əvvəl müştərinin interfeysini oxuyun, çünki topologiyanı netmask adlandırır. /24 və ya başqa subnet maskası paylaşılan hovuz deməkdir; qonşu ünvanı olan /30 isə köhnə nöqtədən-nöqtəyə sxemdir, burada hər müştərinin tam bir qonşusu var: server.
net30 və subnet, müştəri tərəfindən oxunuşu
| 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 ilə server hər müştəriyə kiçik bir blok verir, beləliklə başqa müştərinin tunel ünvanına marşrut yalnız server onu yönləndirdikdə mövcuddur. Subnet ilə bütün hovuz bir şəbəkədir, hər müştəri hər birinə müraciət edə bilər və server aralarında yönləndirir. Buna görə bir server konfiqurasiyası sağlam görünə bilər, halbuki qonşu ping-ləri uğursuz olur: heç nə pozulmayıb, sadəcə müştərilər bir şəbəkədə deyil. Müştəri işləyən bir keçid və cavab verməyən qonşu ünvanı görür; bu firewall kimi oxunur, əslində isə ünvanlama sxemidir.
Direktivi dəyişmək server tərəfində redaktə və yenidən başlatma deməkdir və artıq açıq sessiyalara deyil, növbəti bağlantıya tətbiq olunur. Dəyişikliyi qiymətləndirməzdən əvvəl müştəriləri yenidən qoşun. Cihaz konfiqurasiyanı veb interfeysdən yenidən yaradırsa, direktivi, faylı və tarixi qeyd edin və interfeys varsa redaktəni onun vasitəsilə edin, çünki yenidən qurma növbəti yadda saxlamada əl ilə edilən düzəlişi siləcək.
client-to-client ayrı bir qapıdır
Hətta bir subnetin içində də server bir müştəridən gəlib digərinə ünvanlanmış paketləri client-to-client qurulmayıbsa atır. Bu açar söz serveri yalnız qəbul edən son nöqtə deyil, qonşu trafiki üçün yönləndiriciyə çevirir. İnsanların topologiyanı düzəltdikdən sonra qaçırdığı ikinci şərt budur.
Bu yayıma şamil edilmir. Parametr müştərilər arasında unicast yönləndirir; tuneli paylaşılan seqmentə çevirmir və heç bir miqdarı multicast kəşf sorğusunu hər qonşuya çatdırmayacaq.
TUN və TAP, hər biri nə daşıya bilər
| 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 cihazını LAN-a körpüləmək uzaq müştəriləri ofis yayım domeninə qoyur və kəşfi tamamilə həll edir. Qiyməti TAP-ı tətbiq etməyən platformalar, serverdə mövcud olmalı körpü və ofis kabelindəki yayım fırtınasının hər uzaq noutbuka çatdığı nasazlıq domenidir.
Ad həllinə ehtiyacı olan iki və ya üç iş stansiyası üçün hosts qeydi və ya unicast ünvan körpüdən qat-qat ucuzdur. TAP-a yalnız dəyişdirə bilmədiyiniz protokol 2-ci qat kəşfindən asılı olduqda əl atın, ondan əvvəl yox.
Körpüsüz eyni subnet müştəriləri
LAN aralığından ünvan vermək müştərini kabelə qoymur. Server tunel ilə Ethernet arasında yönləndirir, buna görə həmin ünvan üçün ARP serverin interfeysində dayanır və LAN-ın qalanı onun harada yaşadığını heç vaxt bilmir.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP bu boşluğu serverin müştəri adından cavab verməsi ilə bağlayır. Aralıq üçün parpd qeydləri müştərilər gəlib-getdikcə idarə edir, sysctl net.ipv4.conf.eth0.proxy_arp=1 isə başqa yerə yönləndirilən hər şey üçün cavab verir; bu, məşğul seqmentdə öz sürprizlərini yaratmaq üçün kifayət qədər genişdir.
Hansı yolu seçsəniz seçin, tunel ilə kabel arasından NAT-ı çıxarın. MASQUERADE qaydası cavablandırmağa çalışdığınız ünvanlama sualını tam olaraq gizlədir. O, həm də növbəti adama müştəri tərəfindən düşünülə bilməyən bir topologiya qoyur.
Heç nəyi dəyişməzdən əvvəl serverdə tcpdump -ni tun0 ilə bir cəhdi tutun və qonşu paketinin ümumiyyətlə gəlib-gəlmədiyini təsdiqləyin. Gəlib atılırsa, bu client-to-client göstərir; heç gəlmirsə, topologiya və ya marşrutlaşdırma göstərir. OpenVPN 2.6 təlimatı hər iki açar sözü və topologiya standartını sənədləşdirir; forum yazısından sətir kopyalamazdan əvvəl onu versiyanızla tutuşdurmağa dəyər.
- tun interfeysi /30 qonşu cütü yerinə hovuz maskası göstərir.
- Digər tunel ünvanına birbaşa ping kəşfi sınamazdan əvvəl uğurlu olur.
- Qonşular paket mübadilə etməli olduqda server konfiqurasiyası
client-to-clientehtiva edir. - Tətbiq uğursuz olur demək əvəzinə sınaqdan keçirdiyiniz kəşf protokolunu adlandırın.
- TAP-ı yalnız qrupdakı hər müştəri platforması onu dəstəklədikdə istifadə edin.
- Eyni subnet daxilində əlçatanlıq vacib olduqda NAT-ı tunel ilə LAN arasındakı yoldan kənarda saxlayın.