OpenVPN-kliënte sien mekaar nie: subnet of net30?
Kliënte bereik die bediener, maar nie mekaar nie. Skei die fout met een ping en kies dan subnet-topologie, client-to-client of 'n oorbrugde TAP-segment.
Twee onverwante foute lewer dieselfde klag. In die eerste kan een kliënt 'n ander nie eers op tonneladres bereik nie, want die adresse is nie in een subnet nie of die bediener stuur nie portuurverkeer deur nie. In die tweede werk ping en bly die toepassing se toestellys leeg, want ontdekking berus op uitsending wat 'n laag-3-tonnel nie kan dra nie. Een ping skei hulle, en die regstelling vir elkeen lyk niks soos die regstelling vir die ander nie.
Een ping verdeel die probleem in twee
Ping van een kliënt na die ander kliënt se tonneladres, nie na sy naam en nie na sy LAN-adres nie. As dit misluk, is deurstuur of adressering die probleem en is ontdekking irrelevant totdat dit reggemaak is. As dit slaag, werk deurstuur reeds en is die oorblywende gaping uitsending of naamresolusie.
ip addr show tun0Lees eers die kliënt se koppelvlak, want die netmasker noem die topologie. 'n /24 of 'n ander subnetmasker beteken 'n gedeelde poel; 'n /30 met 'n portuuradres beteken die ouer punt-tot-punt-uitleg, waar elke kliënt presies een buur het, die bediener.
net30 teenoor subnet, gelees van die kliëntkant
| 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 |
Met net30 gee die bediener 'n klein blok per kliënt, dus bestaan daar nie 'n roete na 'n ander kliënt se tonneladres nie tensy die bediener dit deurstuur. Met subnet is die hele poel een netwerk, elke kliënt kan elke ander bereik, en die bediener stuur tussen hulle deur. Dis hoekom een bedienerkonfigurasie gesond kan lyk terwyl portuur-pings misluk: niks is stukkend nie, die kliënte is bloot nie in een netwerk nie. Die kliënt sien 'n werkende skakel en 'n portuuradres wat nie antwoord nie, wat soos 'n firewall lees maar 'n adresseringsuitleg is.
Om die richtlijn te skakel is 'n redigering aan die bedienerkant plus 'n herbegin, en dit geld vir die volgende verbinding eerder as vir sessies wat reeds op is. Verbind die kliënte weer voordat jy die verandering beoordeel. As 'n toestel die konfigurasie uit 'n webkoppelvlak hergenereer, teken die richtlijn, die lêer en die datum aan, en maak die wysiging deur die koppelvlak wanneer een bestaan, want 'n herbou sal 'n handwysiging by die volgende stoor oorskryf.
client-to-client is 'n aparte hek
Selfs binne een subnet laat val die bediener pakkette wat van een kliënt kom en aan 'n ander geadresseer is, tensy client-to-client gestel is. Daardie sleutelwoord maak die bediener 'n deurstuurder vir portuurverkeer eerder as 'n eindpunt wat dit net aanvaar. Dit is die tweede voorwaarde wat mense mis nadat hulle die topologie reggemaak het.
Dit strek nie tot uitsending nie. Die instelling stuur unicast tussen kliënte deur; dit maak nie die tonnel 'n gedeelde segment nie, en geen hoeveelheid daarvan sal 'n multicast-ontdekkingsnavraag by elke portuur aflewer nie.
TUN teenoor TAP, en wat elkeen kan dra
| 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 |
Om 'n tap-toestel in die LAN te oorbrug plaas afgeleë kliënte in die kantoor se uitsendingsdomein, wat ontdekking heeltemal oplos. Die prys is die platforms wat nie TAP implementeer nie, 'n brug wat op die bediener moet bestaan, en 'n foutdomein waar 'n uitsendingsstorm op die kantoordraad elke afgeleë skootrekenaar bereik.
Vir twee of drie werkstasies wat naamresolusie nodig het, is 'n hosts-inskrywing of 'n unicast-adres baie goedkoper as 'n brug. Gryp na TAP wanneer 'n protokol wat jy nie kan vervang nie op laag-2-ontdekking staatmaak, en nie vroeër nie.
Kliënte in dieselfde subnet sonder 'n brug
Om 'n adres uit die LAN-reeks toe te ken, plaas nie die kliënt op die draad nie. Die bediener roeteer tussen tonnel en Ethernet, so ARP vir daardie adres stop by die bediener se koppelvlak en die res van die LAN leer nooit waar dit woon nie.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP sluit daardie gaping deur die bediener namens die kliënt te laat antwoord. Vir 'n reeks bestuur parpd die inskrywings terwyl kliënte kom en gaan, terwyl die sysctl net.ipv4.conf.eth0.proxy_arp=1 antwoord vir alles wat elders heen geroteer word, wat breed genoeg is om sy eie verrassings op 'n besige segment te skep.
Watter roete jy ook al kies, haal NAT tussen die tonnel en die draad uit. 'n MASQUERADE-reël verberg juis die adresseringsvraag wat jy probeer beantwoord. Dit laat ook die volgende persoon met 'n topologie waaroor hy nie van die kliëntkant kan redekawel nie.
Voordat jy enigiets verander, vang een poging op die bediener met tcpdump -ni tun0 en bevestig of die portuurpakket hoegenaamd aankom. Aankom en weggegooi word wys op client-to-client; nooit aankom nie wys op topologie of roetering. Die OpenVPN 2.6-handleiding dokumenteer beide sleutelwoorde en die verstektopologie, wat die moeite werd is om teen jou weergawe na te gaan voordat jy 'n reël uit 'n forumpos kopieer.
- Die tun-koppelvlak wys 'n poelmasker eerder as 'n /30-portuurpaar.
- 'n Direkte ping na die ander tonneladres slaag voordat jy ontdekking toets.
- Die bedienerkonfigurasie sluit
client-to-clientin wanneer porture pakkette moet uitruil. - Noem die ontdekkingsprotokol wat jy toets in plaas daarvan om te sê die app faal.
- Gebruik TAP net as elke kliëntplatform in die groep dit ondersteun.
- Hou NAT uit die pad tussen tonnel en LAN wanneer bereikbaarheid binne dieselfde subnet saak maak.