OpenVPN-i kliendid ei näe üksteist: subnet või net30?
Kliendid jõuavad serverini, kuid mitte üksteiseni. Eraldage viga ühe pingiga ja valige siis subnet-topoloogia, client-to-client või sillatud TAP-segment.
Kaks sõltumatut viga annavad sama kaebuse. Esimesel juhul ei jõua üks klient teiseni isegi tunneliaadressi kaudu, sest aadressid ei ole ühes subnetis või server ei edasta võrdõiguslaste liiklust. Teisel juhul ping töötab ja rakenduse seadmete loend jääb tühjaks, sest avastamine tugineb broadcastile, mida 3. kihi tunnel kanda ei suuda. Üks ping eraldab need, ja kummagi parandus ei sarnane üldse teise parandusega.
Üks ping jagab probleemi kaheks
Ühest kliendist pingige teise kliendi tunneliaadressi, mitte selle nime ja mitte selle LAN-aadressi. Kui see ebaõnnestub, on probleem edastamises või adresseerimises ja avastamine on ebaoluline, kuni see on parandatud. Kui see õnnestub, edastamine juba töötab ja ülejäänud lünk on broadcast või nimede lahendamine.
ip addr show tun0Lugege kliendi liidest enne kõike muud, sest võrgumask nimetab topoloogia. /24 või muu alamvõrgu mask tähendab jagatud basseini; /30 koos võrdõiguslase aadressiga tähendab vanemat punkt-punkti paigutust, kus igal kliendil on täpselt üks naaber, server.
net30 versus subnet, loetuna kliendi poolelt
| 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 korral jagab server igale kliendile väikese ploki, seega ei ole teekonda teise kliendi tunneliaadressile, kui server seda ei edasta. Subneti korral on kogu bassein üks võrk, iga klient saab adresseerida iga teist ja server edastab nende vahel. Sellepärast võib üks serveri konfiguratsioon tunduda terve, samal ajal kui võrdõiguslaste vaheline ping ebaõnnestub: miski ei ole katki, kliendid lihtsalt ei ole ühes võrgus. Klient näeb töötavat linki ja võrdõiguslase aadressi, mis ei vasta, mis loeb nagu tulemüür, kuid on adresseerimise paigutus.
Direktiivi vahetamine on serveripoolne muudatus pluss taaskäivitus ja kehtib järgmise ühenduse kohta, mitte juba avatud sessioonide kohta. Ühendage kliendid uuesti enne muudatuse hindamist. Kui seade genereerib konfiguratsiooni veebiliidesest uuesti, kirjutage üles direktiiv, fail ja kuupäev, ning tehke muudatus liidese kaudu, kui see on olemas, sest uuesti genereerimine kirjutab käsitsi tehtud muudatuse järgmisel salvestamisel üle.
client-to-client on eraldi värav
Isegi ühe subneti sees viskab server kõrvale paketid, mis tulevad ühelt kliendilt ja on adresseeritud teisele, kui client-to-client ei ole seatud. See märksõna muudab serveri võrdõiguslaste liikluse edastajaks, mitte ainult seda vastuvõtvaks lõpp-punktiks. See on teine tingimus, mille inimesed pärast topoloogia parandamist kahe silma vahele jätavad.
See ei laiene broadcastile. Säte edastab unicasti klientide vahel; see ei muuda tunnelit jagatud segmendiks ja ükski selle kogus ei toimeta multicast-avastamispäringut igale võrdõiguslasele.
TUN versus TAP ja mida kumbki kanda suudab
| 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-seadme sillamine LAN-i viib kaugkliendid kontori broadcast-domeeni, mis lahendab avastamise täielikult. Hinnaks on platvormid, mis TAP-i ei rakenda, serveris olema pidav sild ja veadomeen, kus kontorikaabli broadcast-torm jõuab iga kaugseadmeni.
Kahele või kolmele tööjaamale, mis vajavad nimede lahendamist, on hosts-kirje või unicast-aadress sillast palju odavam. Haarake TAP-i järele siis, kui protokoll, mida te ei saa asendada, sõltub 2. kihi avastamisest, ja mitte varem.
Sama subneti kliendid ilma sillata
LAN-i vahemikust aadressi määramine ei pane klienti kaablile. Server marsruudib tunneli ja Etherneti vahel, seega peatub selle aadressi ARP serveri liidesel ja ülejäänud LAN ei saa kunagi teada, kus see elab.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP sulgeb selle lünga, lastes serveril kliendi eest vastata. Vahemiku jaoks haldab parpd kirjeid, kui kliendid tulevad ja lähevad, samal ajal kui sysctl net.ipv4.conf.eth0.proxy_arp=1 vastab kõige eest, mis on mujale marsruuditud, mis on piisavalt lai, et tekitada hõivatud segmendil oma üllatusi.
Ükskõik millise tee valite, eemaldage NAT tunneli ja kaabli vahelt. MASQUERADE reegel varjab täpselt selle adresseerimisküsimuse, millele te vastata püüate. See jätab ka järgmisele inimesele topoloogia, millest ta ei saa kliendi poolelt järeldada.
Enne kui midagi muudate, püüdke serveris üks katse tcpdump -ni tun0 abil ja kinnitage, kas võrdõiguslase pakett üldse saabub. Saabumine ja kõrvaleviskamine viitab client-to-client-ile; mitte kunagi saabumine viitab topoloogiale või marsruutimisele. OpenVPN 2.6 käsiraamat dokumenteerib mõlemad märksõnad ja vaiketopoloogia, mida tasub enne foorumipostitusest rea kopeerimist oma versiooniga võrrelda.
- tun-liides näitab basseini maski, mitte /30 võrdõiguslaste paari.
- Otsene ping teisele tunneliaadressile õnnestub enne, kui avastamist testite.
- Serveri konfiguratsioon sisaldab
client-to-clientalati, kui võrdõiguslased peavad pakette vahetama. - Nimetage avastamisprotokoll, mida testite, selle asemel et öelda, et rakendus ebaõnnestub.
- Kasutage TAP-i ainult siis, kui rühma iga kliendiplatvorm seda toetab.
- Hoidke NAT eemale tunneli ja LAN-i vaheliselt teelt, kui oluline on kättesaadavus sama subneti sees.