OpenVPN klientai nemato vienas kito: potinklis ar net30?
Klientai pasiekia serverį, bet ne vienas kito. Atskirkite gedimą vienu ping ir tada pasirinkite potinklio topologiją, client-to-client arba tiltu sujungtą TAP segmentą.
Du nesusiję gedimai duoda tą patį skundą. Pirmuoju atveju vienas klientas nepasiekia kito net tunelio adresu, nes adresai nėra tame pačiame potinklyje arba serveris nepersiunčia srauto tarp porininkų. Antruoju atveju ping veikia, o programos įrenginių sąrašas lieka tuščias, nes aptikimas remiasi transliacija, kurios 3 sluoksnio tunelis negali pernešti. Vienas ping juos atskiria, o kiekvieno taisymas visai nepanašus į kito taisymą.
Vienas ping padalija problemą į dvi
Iš vieno kliento pinginkite kito kliento tunelio adresą, ne jo vardą ir ne jo LAN adresą. Jei tai nepavyksta, problema yra persiuntime arba adresavime, o aptikimas nesvarbus, kol tai nesutvarkyta. Jei pavyksta, persiuntimas jau veikia, o likęs trūkumas yra transliacija arba vardų skyrimas.
ip addr show tun0Pirmiausia perskaitykite kliento sąsają, nes tinklo kaukė įvardija topologiją. /24 ar kita potinklio kaukė reiškia bendrą telkinį; /30 su porininko adresu reiškia senesnį taškas-taškas išdėstymą, kai kiekvienas klientas turi lygiai vieną kaimyną, serverį.
net30 prieš potinklį, skaitoma iš kliento pusės
| 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 |
Su net30 serveris skiria mažą bloką kiekvienam klientui, todėl maršruto į kito kliento tunelio adresą nėra, nebent serveris jį persiunčia. Su potinkliu visas telkinys yra vienas tinklas, kiekvienas klientas gali kreiptis į kiekvieną kitą, o serveris persiunčia tarp jų. Štai kodėl viena serverio konfigūracija gali atrodyti sveika, nors ping tarp porininkų nepavyksta: niekas nesugedę, klientai tiesiog nėra viename tinkle. Klientas mato veikiančią jungtį ir neatsakančio porininko adresą, kas skaitosi kaip užkarda, bet iš tikrųjų yra adresavimo išdėstymas.
Direktyvos pakeitimas yra serverio pusės redagavimas ir paleidimas iš naujo, ir jis galioja kitam prisijungimui, o ne jau atidarytoms sesijoms. Prieš vertindami pakeitimą, prijunkite klientus iš naujo. Jei įrenginys iš naujo generuoja konfigūraciją iš žiniatinklio sąsajos, užsirašykite direktyvą, failą ir datą, o redagavimą atlikite per sąsają, kai ji yra, nes perkūrimas perrašys rankinį redagavimą kitą kartą išsaugant.
client-to-client yra atskiri vartai
Net viename potinklyje serveris išmeta paketus, kurie ateina iš vieno kliento ir yra skirti kitam, nebent client-to-client nustatytas. Tas raktinis žodis paverčia serverį porininkų srauto persiuntėju, o ne galiniu tašku, kuris jį tik priima. Tai antroji sąlyga, kurią žmonės praleidžia sutvarkę topologiją.
Tai netaikoma transliacijai. Nustatymas persiunčia unicast tarp klientų; jis nepaverčia tunelio bendru segmentu, ir joks jo kiekis nepristatys multicast aptikimo užklausos kiekvienam porininkui.
TUN prieš TAP, ir ką kiekvienas gali pernešti
| 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 įrenginio sujungimas tiltu į LAN įkelia nuotolinius klientus į biuro transliacijos sritį, o tai visiškai išsprendžia aptikimą. Kaina yra platformos, kurios neįgyvendina TAP, tiltas, kuris turi egzistuoti serveryje, ir gedimo sritis, kurioje transliacijos audra biuro kabelyje pasiekia kiekvieną nuotolinį nešiojamąjį kompiuterį.
Dviem ar trims darbo stotims, kurioms reikia vardų skyrimo, hosts įrašas ar unicast adresas yra daug pigesnis už tiltą. Į TAP kreipkitės tada, kai protokolas, kurio negalite pakeisti, priklauso nuo 2 sluoksnio aptikimo, ir ne anksčiau.
To paties potinklio klientai be tilto
Adreso skyrimas iš LAN diapazono neįkelia kliento į kabelį. Serveris maršrutizuoja tarp tunelio ir Ethernet, todėl to adreso ARP sustoja serverio sąsajoje, o likęs LAN niekada nesužino, kur jis gyvena.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP užpildo tą spragą, nes serveris atsako kliento vardu. Diapazonui parpd tvarko įrašus klientams ateinant ir išeinant, o sysctl net.ipv4.conf.eth0.proxy_arp=1 atsako už viską, kas maršrutizuojama kitur, o tai pakankamai platu, kad sukurtų savų netikėtumų užimtame segmente.
Kad ir kokį kelią pasirinktumėte, pašalinkite NAT tarp tunelio ir kabelio. MASQUERADE taisyklė paslepia būtent tą adresavimo klausimą, į kurį bandote atsakyti. Ji taip pat palieka kitam žmogui topologiją, apie kurią jis negali mąstyti iš kliento pusės.
Prieš ką nors keisdami, serveryje užfiksuokite vieną bandymą su tcpdump -ni tun0 ir patvirtinkite, ar porininko paketas apskritai ateina. Ateina ir išmetamas — tai rodo client-to-client; niekada neateina — rodo topologiją arba maršrutizavimą. OpenVPN 2.6 vadovas dokumentuoja abu raktinius žodžius ir numatytąją topologiją, ką verta palyginti su savo versija prieš kopijuojant eilutę iš forumo pranešimo.
- tun sąsaja rodo telkinio kaukę, o ne /30 porininkų porą.
- Tiesioginis ping į kitą tunelio adresą pavyksta prieš tikrinant aptikimą.
- Serverio konfigūracija apima
client-to-client, kai tik porininkai turi keistis paketais. - Įvardykite tikrinamą aptikimo protokolą, o ne sakykite, kad programa nepavyksta.
- Naudokite TAP tik jei kiekviena grupės kliento platforma jį palaiko.
- Laikykite NAT už kelio tarp tunelio ir LAN, kai svarbus pasiekiamumas tame pačiame potinklyje.