Klienti OpenVPN sa navzájom nevidia: podsiete, alebo net30?
Klienti sa dostanú na server, ale nie na seba. Rozdeľte poruchu jedným pingom a potom zvoľte topológiu podsiete, client-to-client alebo premosťovaný segment TAP.
Dve nesúvisiace poruchy dávajú tú istú sťažnosť. V prvej sa jeden klient nedostane na druhého ani na adresu tunela, pretože adresy nie sú v jednej podsieti alebo server nepreposiela prevádzku medzi partnermi. V druhej ping funguje a zoznam zariadení v aplikácii zostáva prázdny, pretože zisťovanie stojí na broadcast, ktorý tunel 3. vrstvy uniesť nemôže. Jeden ping ich oddelí a oprava každej z nich sa tej druhej vôbec nepodobá.
Jeden ping rozdelí problém na dva
Z jedného klienta pingnite adresu tunela druhého klienta, nie jeho meno a nie jeho LAN adresu. Ak to zlyhá, problém je v preposielaní alebo adresovaní a zisťovanie je irelevantné, kým sa to neopraví. Ak to uspeje, preposielanie už funguje a zostávajúca medzera je broadcast alebo preklad mien.
ip addr show tun0Prečítajte rozhranie klienta skôr než čokoľvek iné, pretože maska siete pomenúva topológiu. /24 alebo iná maska podsiete znamená spoločný fond; /30 s adresou partnera znamená staršie usporiadanie bod-bod, kde má každý klient práve jedného suseda, server.
net30 verzus podsiete, čítané zo strany klienta
| 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 |
S net30 server prideľuje malý blok každému klientovi, takže cesta na adresu tunela iného klienta neexistuje, kým ju server neprepošle. S podsiete je celý fond jedna sieť, každý klient môže adresovať každého ďalšieho a server medzi nimi preposiela. Preto môže jedna konfigurácia servera vyzerať zdravo, zatiaľ čo pingy medzi partnermi zlyhávajú: nič nie je pokazené, klienti jednoducho nie sú v jednej sieti. Klient vidí fungujúce spojenie a adresu partnera, ktorá neodpovedá, čo sa číta ako firewall, ale je to usporiadanie adresovania.
Prepnutie direktívy je úprava na strane servera plus reštart a platí pre nasledujúce pripojenie, nie pre už nadviazané sedenia. Pred posúdením zmeny pripojte klientov znova. Ak zariadenie generuje konfiguráciu z webového rozhrania, poznamenajte direktívu, súbor a dátum a úpravu vykonajte cez rozhranie, keď existuje, pretože pregenerovanie prepíše ručnú úpravu pri nasledujúcom uložení.
client-to-client sú samostatné vráta
Aj v jednej podsieti server zahadzuje pakety, ktoré prichádzajú od jedného klienta a sú adresované inému, ak nie je nastavené client-to-client. To kľúčové slovo mení server na preposielača prevádzky medzi partnermi namiesto koncového bodu, ktorý ju len prijíma. Je to druhá podmienka, ktorú ľudia po oprave topológie prehliadnu.
Nevzťahuje sa to na broadcast. Nastavenie preposiela unicast medzi klientmi; nepremieňa tunel na spoločný segment a žiadne množstvo toho nedoručí multicastový dotaz na zisťovanie každému partnerovi.
TUN verzus TAP a čo každý unesie
| 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 |
Premostenie zariadenia tap do LAN postaví vzdialených klientov do broadcastovej domény kancelárie, čo zisťovanie úplne vyrieši. Cenou sú platformy, ktoré TAP neimplementujú, most, ktorý musí na serveri existovať, a doména zlyhania, kde broadcastová búrka na kancelárskom kábli zasiahne každý vzdialený notebook.
Pre dve alebo tri pracovné stanice, ktoré potrebujú preklad mien, je záznam v hosts alebo unicastová adresa oveľa lacnejšia než most. Po TAP siahnite, keď protokol, ktorý nemôžete nahradiť, závisí od zisťovania 2. vrstvy, a nie skôr.
Klienti tej istej podsiete bez mosta
Pridelenie adresy z rozsahu LAN klienta na kábel nepostaví. Server routuje medzi tunelom a Ethernetom, takže ARP pre túto adresu končí na rozhraní servera a zvyšok LAN sa nikdy nedozvie, kde býva.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP túto medzeru zatvára tým, že server odpovedá za klienta. Pre rozsah parpd spravuje záznamy, ako klienti prichádzajú a odchádzajú, zatiaľ čo sysctl net.ipv4.conf.eth0.proxy_arp=1 odpovedá za všetko smerované inam, čo je dosť široké na to, aby si na vyťaženom segmente vytvorilo vlastné prekvapenia.
Nech si vyberiete ktorúkoľvek cestu, odstráňte NAT medzi tunelom a káblom. Pravidlo MASQUERADE skrýva práve tú otázku adresovania, na ktorú sa snažíte odpovedať. Necháva tiež ďalšiemu človeku topológiu, o ktorej nedokáže uvažovať zo strany klienta.
Skôr než čokoľvek zmeníte, zachyťte na serveri jediný pokus s tcpdump -ni tun0 a potvrďte, či paket partnera vôbec dorazí. Dorazí a je zahodený — to ukazuje na client-to-client; nikdy nedorazí — na topológiu alebo routovanie. Príručka OpenVPN 2.6 dokumentuje obe kľúčové slová aj predvolenú topológiu a oplatí sa ju porovnať s vašou verziou, než skopírujete riadok z príspevku na fóre.
- Rozhranie tun ukazuje masku fondu, nie pár partnera /30.
- Priamy ping na druhú adresu tunela uspeje skôr, než otestujete zisťovanie.
- Konfigurácia servera obsahuje
client-to-clientvždy, keď si partneri musia vymieňať pakety. - Pomenujte protokol zisťovania, ktorý testujete, namiesto toho, aby ste povedali, že aplikácia zlyháva.
- TAP použite len vtedy, ak ho podporuje každá klientska platforma v skupine.
- Držte NAT mimo cesty medzi tunelom a LAN, keď záleží na dostupnosti v rámci tej istej podsiete.