OpenVPN klijenti ne vide jedni druge: podmreža ili net30?
Klijenti stižu do poslužitelja, ali ne jedni do drugih. Razdvojite kvar jednim pingom, pa odaberite topologiju podmreže, client-to-client ili premošteni TAP segment.
Dva nepovezana kvara daju istu pritužbu. U prvom jedan klijent ne može doći do drugoga čak ni po adresi tunela, jer adrese nisu u istoj podmreži ili poslužitelj ne prosljeđuje promet između parnjaka. U drugom ping radi, a popis uređaja u aplikaciji ostaje prazan, jer otkrivanje ovisi o broadcastu koji tunel 3. sloja ne može prenijeti. Jedan ping ih razdvaja, a popravak za svaki nimalo ne sliči popravku za drugi.
Jedan ping dijeli problem na dva
S jednog klijenta pingajte adresu tunela drugog klijenta, ne njegovo ime i ne njegovu LAN adresu. Ako to ne uspije, problem je u prosljeđivanju ili adresiranju i otkrivanje je nevažno dok se to ne popravi. Ako uspije, prosljeđivanje već radi, a preostali jaz je broadcast ili razrješavanje imena.
ip addr show tun0Pročitajte sučelje klijenta prije svega ostalog, jer netmask imenuje topologiju. /24 ili druga maska podmreže znači zajednički bazen; /30 s adresom parnjaka znači stariji raspored točka-točka, gdje svaki klijent ima točno jednog susjeda, poslužitelj.
net30 nasuprot podmreži, čitano sa strane klijenta
| 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 poslužitelj daje mali blok po klijentu, pa ruta do adrese tunela drugog klijenta ne postoji osim ako je poslužitelj ne proslijedi. S podmrežom cijeli je bazen jedna mreža, svaki klijent može adresirati svakoga drugoga, a poslužitelj prosljeđuje između njih. Zato jedna konfiguracija poslužitelja može izgledati zdravo dok pingovi između parnjaka ne uspijevaju: ništa nije pokvareno, klijenti jednostavno nisu u jednoj mreži. Klijent vidi radnu vezu i adresu parnjaka koja ne odgovara, što zvuči kao vatrozid, ali je raspored adresiranja.
Promjena direktive je uređivanje na strani poslužitelja plus restart, i primjenjuje se na sljedeću vezu, a ne na sjednice koje su već uspostavljene. Ponovno povežite klijente prije nego procijenite promjenu. Ako uređaj ponovno generira konfiguraciju iz web sučelja, zabilježite direktivu, datoteku i datum, i izvršite izmjenu kroz sučelje kad postoji, jer će ponovna izgradnja prepisati ručnu izmjenu pri sljedećem spremanju.
client-to-client su odvojena vrata
Čak i unutar jedne podmreže poslužitelj odbacuje pakete koji dolaze od jednog klijenta i adresirani su na drugoga, osim ako client-to-client nije postavljen. Ta ključna riječ pretvara poslužitelj u prosljeđivač prometa između parnjaka, umjesto u krajnju točku koja ga samo prihvaća. To je drugi uvjet koji ljudi propuste nakon popravka topologije.
To se ne proteže na broadcast. Postavka prosljeđuje unicast između klijenata; ne pretvara tunel u zajednički segment, i nijedna količina toga neće dostaviti multicast upit za otkrivanje svakom parnjaku.
TUN nasuprot TAP, i što svaki može prenijeti
| 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 |
Premošćivanje tap uređaja u LAN stavlja udaljene klijente u broadcast domenu ureda, što potpuno rješava otkrivanje. Cijena su platforme koje ne implementiraju TAP, most koji mora postojati na poslužitelju, i domena kvara u kojoj broadcast oluja na uredskom kabelu stiže do svakog udaljenog prijenosnika.
Za dvije ili tri radne stanice kojima treba razrješavanje imena, hosts unos ili unicast adresa daleko je jeftinija od mosta. Posegnite za TAP-om kad protokol koji ne možete zamijeniti ovisi o otkrivanju na 2. sloju, i ne prije.
Klijenti iste podmreže bez mosta
Dodjela adrese iz LAN raspona ne stavlja klijenta na kabel. Poslužitelj usmjerava između tunela i Etherneta, pa se ARP za tu adresu zaustavlja na sučelju poslužitelja i ostatak LAN-a nikada ne sazna gdje ona stanuje.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP zatvara taj jaz tako što poslužitelj odgovara u ime klijenta. Za raspon parpd upravlja unosima kako klijenti dolaze i odlaze, dok sysctl net.ipv4.conf.eth0.proxy_arp=1 odgovara za sve što se usmjerava drugamo, što je dovoljno široko da stvori vlastita iznenađenja na zauzetom segmentu.
Koji god put odabrali, uklonite NAT između tunela i kabela. MASQUERADE pravilo skriva upravo pitanje adresiranja na koje pokušavate odgovoriti. Ono također ostavlja sljedećoj osobi topologiju o kojoj ne može razmišljati sa strane klijenta.
Prije nego što bilo što promijenite, uhvatite jedan pokušaj na poslužitelju s tcpdump -ni tun0 i potvrdite dolazi li paket parnjaka uopće. Dolazi i biva odbačen — to upućuje na client-to-client; nikada ne dolazi — upućuje na topologiju ili usmjeravanje. OpenVPN 2.6 priručnik dokumentira obje ključne riječi i zadanu topologiju, što vrijedi provjeriti sa svojom verzijom prije nego što kopirate redak s forumske objave.
- tun sučelje pokazuje masku bazena, a ne par parnjaka /30.
- Izravan ping na drugu adresu tunela uspijeva prije nego što testirate otkrivanje.
- Konfiguracija poslužitelja uključuje
client-to-clientkad god parnjaci moraju razmjenjivati pakete. - Imenujte protokol otkrivanja koji testirate, umjesto da kažete da aplikacija ne radi.
- Koristite TAP samo ako ga podržava svaka klijentska platforma u skupini.
- Držite NAT izvan puta između tunela i LAN-a kad je dostupnost unutar iste podmreže važna.