Klienti OpenVPN na sebe nevidí: podsíť, nebo net30?
Klienti dosáhnou na server, ale ne na sebe. Rozdělte závadu jedním pingem a pak zvolte topologii podsítě, client-to-client nebo přemostěný segment TAP.
Dvě nesouvisející závady dávají stejnou stížnost. V první se jeden klient nedostane na druhého ani na adresu tunelu, protože adresy nejsou v jedné podsíti nebo server nepředává provoz mezi partnery. Ve druhé ping funguje a seznam zařízení v aplikaci zůstává prázdný, protože zjišťování stojí na broadcastu, který tunel 3. vrstvy unést nemůže. Jeden ping je oddělí a oprava každé z nich se té druhé vůbec nepodobá.
Jeden ping rozdělí problém na dva
Z jednoho klienta pingněte adresu tunelu druhého klienta, ne jeho jméno a ne jeho LAN adresu. Pokud to selže, problém je v předávání nebo adresování a zjišťování je irelevantní, dokud se to neopraví. Pokud to uspěje, předávání už funguje a zbývající mezera je broadcast nebo překlad jmen.
ip addr show tun0Přečtěte rozhraní klienta dřív než cokoli jiného, protože maska sítě pojmenovává topologii. /24 nebo jiná maska podsítě znamená sdílený fond; /30 s adresou partnera znamená starší uspořádání bod-bod, kde má každý klient právě jednoho souseda, server.
net30 versus podsíť, čteno ze 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 přiděluje malý blok každému klientovi, takže cesta na adresu tunelu jiného klienta neexistuje, dokud ji server nepředá. S podsítí je celý fond jedna síť, každý klient může adresovat každého dalšího a server mezi nimi předává. Proto může jedna konfigurace serveru vypadat zdravě, zatímco pingy mezi partnery selhávají: nic není rozbité, klienti prostě nejsou v jedné síti. Klient vidí fungující spojení a adresu partnera, která neodpovídá, což vypadá jako firewall, ale je to uspořádání adresování.
Přepnutí direktivy je úprava na straně serveru plus restart a platí pro příští připojení, ne pro už navázaná sezení. Než změnu posoudíte, připojte klienty znovu. Pokud zařízení generuje konfiguraci z webového rozhraní, poznamenejte direktivu, soubor a datum a úpravu proveďte přes rozhraní, když existuje, protože přegenerování přepíše ruční úpravu při příštím uložení.
client-to-client jsou samostatná vrata
I uvnitř jedné podsítě server zahazuje pakety, které přijdou od jednoho klienta a jsou adresované jinému, pokud není nastaveno client-to-client. To klíčové slovo mění server v přeposílač provozu mezi partnery místo koncového bodu, který ho jen přijímá. Je to druhá podmínka, kterou lidé po opravě topologie přehlédnou.
Nevztahuje se to na broadcast. Nastavení přeposílá unicast mezi klienty; nepřeměňuje tunel na sdílený segment a žádné množství toho nedoručí multicastový dotaz na zjišťování každému partnerovi.
TUN versus TAP a co každý unese
| 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 |
Přemostění zařízení tap do LAN postaví vzdálené klienty do broadcastové domény kanceláře, což zjišťování zcela vyřeší. Cenou jsou platformy, které TAP neimplementují, most, který musí na serveru existovat, a doména selhání, kde broadcastová bouře na kancelářském kabelu zasáhne každý vzdálený notebook.
Pro dvě nebo tři pracovní stanice, které potřebují překlad jmen, je záznam v hosts nebo unicastová adresa mnohem levnější než most. Po TAPu sáhněte, když protokol, který nemůžete nahradit, závisí na zjišťování 2. vrstvy, a ne dřív.
Klienti stejné podsítě bez mostu
Přidělení adresy z rozsahu LAN klienta na kabel nepostaví. Server routuje mezi tunelem a Ethernetem, takže ARP pro tuto adresu končí na rozhraní serveru a zbytek LAN se nikdy nedozví, kde bydlí.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP tuto mezeru zavírá tím, že server odpovídá za klienta. Pro rozsah parpd spravuje záznamy, jak klienti přicházejí a odcházejí, zatímco sysctl net.ipv4.conf.eth0.proxy_arp=1 odpovídá za vše směrované jinam, což je dost široké na to, aby si na vytíženém segmentu vytvořilo vlastní překvapení.
Ať zvolíte kteroukoli cestu, odstraňte NAT mezi tunelem a kabelem. Pravidlo MASQUERADE skrývá právě tu otázku adresování, na kterou se snažíte odpovědět. Také nechá dalšímu člověku topologii, o níž nedokáže uvažovat ze strany klienta.
Než cokoli změníte, zachyťte na serveru jeden pokus s tcpdump -ni tun0 a potvrďte, zda paket partnera vůbec dorazí. Dorazí a je zahozen — to ukazuje na client-to-client; nikdy nedorazí — to ukazuje na topologii nebo routování. Příručka OpenVPN 2.6 dokumentuje obě klíčová slova i výchozí topologii a vyplatí se ji porovnat s vaší verzí, než zkopírujete řádek z příspěvku na fóru.
- Rozhraní tun ukazuje masku fondu, ne pár partnera /30.
- Přímý ping na druhou adresu tunelu uspěje dřív, než otestujete zjišťování.
- Konfigurace serveru obsahuje
client-to-client, kdykoli si partneři musí vyměňovat pakety. - Pojmenujte protokol zjišťování, který testujete, místo abyste říkali, že aplikace selhává.
- TAP použijte jen tehdy, pokud ho podporuje každá klientská platforma ve skupině.
- Držte NAT mimo cestu mezi tunelem a LAN, když záleží na dosažitelnosti v rámci stejné podsítě.