OpenVPN klijenti se ne vide međusobno: subnet ili net30?
Klijenti stižu do servera, ali ne jedni do drugih. Razdvojite kvar jednim pingom, pa odaberite subnet topologiju, 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 server ne prosljeđuje saobraćaj između parnjaka. U drugom ping radi, a lista uređaja u aplikaciji ostaje prazna, jer otkrivanje zavisi od broadcasta koji tunel 3. sloja ne može prenijeti. Jedan ping ih razdvaja, a popravka za svaki nimalo ne liči na popravku za drugi.
Jedan ping dijeli problem na dva
Sa 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 interfejs klijenta prije svega ostalog, jer netmask imenuje topologiju. /24 ili druga maska podmreže znači zajednički bazen; /30 sa adresom parnjaka znači stariji raspored tačka-tačka, gdje svaki klijent ima tačno jednog susjeda, server.
net30 nasuprot subnet, č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 |
Sa net30 server daje mali blok po klijentu, pa ruta do adrese tunela drugog klijenta ne postoji osim ako je server ne proslijedi. Sa subnet cijeli bazen je jedna mreža, svaki klijent može adresirati svakog drugog, a server prosljeđuje između njih. Zato jedna konfiguracija servera može izgledati zdrava 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 firewall, ali je raspored adresiranja.
Promjena direktive je uređivanje na strani servera plus restart, i primjenjuje se na sljedeću vezu, a ne na sesije koje su već uspostavljene. Ponovo povežite klijente prije nego procijenite promjenu. Ako uređaj ponovo generiše konfiguraciju iz web interfejsa, zabilježite direktivu, datoteku i datum, i izvršite izmjenu kroz interfejs kad postoji, jer će ponovna izgradnja prepisati ručnu izmjenu pri sljedećem čuvanju.
client-to-client su odvojena vrata
Čak i unutar jedne podmreže server odbacuje pakete koji dolaze od jednog klijenta i adresirani su na drugoga, osim ako client-to-client nije postavljen. Ta ključna riječ pretvara server u prosljeđivač saobraćaja između parnjaka, umjesto u krajnju tačku koja ga samo prihvata. To je drugi uslov koji ljudi propuste nakon popravke 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 šta 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šćavanje tap uređaja u LAN stavlja udaljene klijente u broadcast domen kancelarije, što potpuno rješava otkrivanje. Cijena su platforme koje ne implementiraju TAP, most koji mora postojati na serveru, i domen kvara u kojem broadcast oluja na kancelarijskom kablu stiže do svakog udaljenog laptopa.
Za dvije ili tri radne stanice kojima treba razrješavanje imena, hosts unos ili unicast adresa je daleko jeftinija od mosta. Posegnite za TAP-om kada protokol koji ne možete zamijeniti zavisi od otkrivanja na 2. sloju, i ne prije.
Klijenti iste podmreže bez mosta
Dodjela adrese iz LAN opsega ne stavlja klijenta na kabl. Server rutira između tunela i Ethernet-a, pa se ARP za tu adresu zaustavlja na interfejsu servera 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 server odgovara u ime klijenta. Za opseg parpd upravlja unosima kako klijenti dolaze i odlaze, dok sysctl net.ipv4.conf.eth0.proxy_arp=1 odgovara za sve što se rutira drugdje, što je dovoljno široko da stvori vlastita iznenađenja na zauzetom segmentu.
Koji god put odabrali, uklonite NAT između tunela i kabla. MASQUERADE pravilo skriva upravo pitanje adresiranja na koje pokušavate odgovoriti. Ono takođe ostavlja sljedećoj osobi topologiju o kojoj ne može razmišljati sa strane klijenta.
Prije nego što bilo šta promijenite, uhvatite jedan pokušaj na serveru sa tcpdump -ni tun0 i potvrdite da li paket parnjaka uopšte stiže. Stiže i biva odbačen — to ukazuje na client-to-client; nikada ne stiže — ukazuje na topologiju ili rutiranje. OpenVPN 2.6 priručnik dokumentuje obje ključne riječi i zadanu topologiju, što vrijedi provjeriti sa svojom verzijom prije nego što kopirate red sa forumske objave.
- tun interfejs pokazuje masku bazena, a ne par parnjaka /30.
- Direktan ping na drugu adresu tunela uspijeva prije nego što testirate otkrivanje.
- Konfiguracija servera uključuje
client-to-clientkad god parnjaci moraju razmjenjivati pakete. - Imenujte protokol za otkrivanje koji testirate, umjesto da kažete da aplikacija ne radi.
- Koristite TAP samo ako ga podržava svaka klijentska platforma u grupi.
- Držite NAT izvan puta između tunela i LAN-a kada je dostupnost unutar iste podmreže važna.