Odjemalci OpenVPN ne vidijo drug drugega: podomrežje ali net30?
Odjemalci dosežejo strežnik, ne pa drug drugega. Ločite napako z enim pingom in nato izberite topologijo podomrežja, client-to-client ali mostni segment TAP.
Dve nepovezani napaki dajeta isto pritožbo. Pri prvi en odjemalec ne doseže drugega niti po naslovu tunela, ker naslovi niso v istem podomrežju ali strežnik ne posreduje prometa med partnerji. Pri drugi ping deluje, seznam naprav v aplikaciji pa ostane prazen, ker odkrivanje temelji na broadcastu, ki ga tunel 3. plasti ne more prenesti. En ping ju loči in popravek vsake od njiju ni prav nič podoben popravku druge.
En ping razdeli težavo na dvoje
Z enega odjemalca pingajte naslov tunela drugega odjemalca, ne njegovo ime in ne njegov naslov LAN. Če to ne uspe, je težava v posredovanju ali naslavljanju in odkrivanje je nepomembno, dokler ni popravljeno. Če uspe, posredovanje že deluje in kar manjka, je broadcast ali razreševanje imen.
ip addr show tun0Najprej preberite vmesnik odjemalca, ker omrežna maska poimenuje topologijo. /24 ali druga maska podomrežja pomeni skupni nabor; /30 z naslovom partnerja pomeni starejšo postavitev točka-točka, kjer ima vsak odjemalec natanko enega soseda, strežnik.
net30 proti podomrežju, brano z odjemalčeve strani
| 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 |
Pri net30 strežnik dodeli majhen blok na odjemalca, zato poti do naslova tunela drugega odjemalca ni, razen če jo strežnik posreduje. Pri podomrežju je celoten nabor eno omrežje, vsak odjemalec lahko naslovi vsakega drugega in strežnik posreduje med njimi. Zato je lahko ena konfiguracija strežnika videti zdrava, medtem ko pingi med partnerji spodletijo: nič ni pokvarjeno, odjemalci preprosto niso v enem omrežju. Odjemalec vidi delujočo povezavo in naslov partnerja, ki ne odgovarja, kar se bere kot požarni zid, a je postavitev naslavljanja.
Spreminjanje direktive je urejanje na strani strežnika in ponovni zagon, velja pa za naslednjo povezavo, ne za že odprte seje. Preden spremembo ocenite, odjemalce znova povežite. Če naprava konfiguracijo znova ustvari iz spletnega vmesnika, zabeležite direktivo, datoteko in datum ter uredite prek vmesnika, kadar obstaja, ker bo ponovna izgradnja prepisala ročni popravek pri naslednjem shranjevanju.
client-to-client so ločena vrata
Tudi znotraj enega podomrežja strežnik zavrže pakete, ki pridejo od enega odjemalca in so naslovljeni na drugega, razen če je nastavljen client-to-client. Ta ključna beseda spremeni strežnik v posredovalca prometa med partnerji, ne v končno točko, ki ga samo sprejema. To je drugi pogoj, ki ga ljudje spregledajo po popravku topologije.
To se ne razširi na broadcast. Nastavitev posreduje unicast med odjemalci; tunela ne spremeni v skupni segment in nobena količina tega ne bo dostavila poizvedbe odkrivanja multicast vsakemu partnerju.
TUN proti TAP in kaj lahko prenese vsak
| 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 |
Mostenje naprave tap v LAN postavi oddaljene odjemalce v broadcastno domeno pisarne, kar odkrivanje popolnoma reši. Cena so platforme, ki ne izvajajo TAP, most, ki mora obstajati na strežniku, in domena odpovedi, kjer broadcastna nevihta na pisarniškem kablu doseže vsak oddaljeni prenosnik.
Za dve ali tri delovne postaje, ki potrebujejo razreševanje imen, je vnos hosts ali unicast naslov veliko cenejši od mostu. Po TAP posezite, ko je protokol, ki ga ne morete zamenjati, odvisen od odkrivanja na 2. plasti, in ne prej.
Odjemalci istega podomrežja brez mostu
Dodelitev naslova iz območja LAN odjemalca ne postavi na kabel. Strežnik usmerja med tunelom in Ethernetom, zato se ARP za ta naslov ustavi na vmesniku strežnika in preostanek LAN nikoli ne izve, kje prebiva.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP zapre to vrzel tako, da strežnik odgovori v imenu odjemalca. Za območje parpd upravlja vnose, ko odjemalci prihajajo in odhajajo, medtem ko sysctl net.ipv4.conf.eth0.proxy_arp=1 odgovarja za vse, kar se usmerja drugam, kar je dovolj široko, da na zasedenem segmentu ustvari lastna presenečenja.
Ne glede na izbrano pot odstranite NAT med tunelom in kablom. Pravilo MASQUERADE skrije natanko tisto vprašanje naslavljanja, na katero poskušate odgovoriti. Prav tako naslednji osebi pusti topologijo, o kateri ne more razmišljati z odjemalčeve strani.
Preden karkoli spremenite, na strežniku ujamite en poskus z tcpdump -ni tun0 in potrdite, ali paket partnerja sploh prispe. Prispe in je zavržen — to kaže na client-to-client; nikoli ne prispe — na topologijo ali usmerjanje. Priročnik OpenVPN 2.6 dokumentira obe ključni besedi in privzeto topologijo, kar velja primerjati s svojo različico, preden kopirate vrstico s forumske objave.
- Vmesnik tun prikaže masko nabora, ne para partnerjev /30.
- Neposreden ping na drugi naslov tunela uspe, preden preizkusite odkrivanje.
- Konfiguracija strežnika vsebuje
client-to-clientvsakič, ko si morajo partnerji izmenjati pakete. - Poimenujte protokol odkrivanja, ki ga preizkušate, namesto da rečete, da aplikacija spodleti.
- Uporabite TAP le, če ga podpira vsaka odjemalska platforma v skupini.
- Držite NAT zunaj poti med tunelom in LAN, ko je pomembna dosegljivost v istem podomrežju.