OpenVPN-klienter kan ikke se hinanden: subnet eller net30?
Klienter når serveren, men ikke hinanden. Del fejlen med ét ping og vælg derefter subnet-topologi, client-to-client eller et brokoblet TAP-segment.
To uafhængige fejl giver den samme klage. I det første kan en klient ikke nå en anden, selv ikke via tunneladressen, fordi adresserne ikke er i samme subnet, eller serveren ikke videresender peer-trafik. I det andet virker ping, og applikationens enhedsliste forbliver tom, fordi opdagelse afhænger af broadcast, som en tunnel på lag 3 ikke kan bære. Ét ping skiller dem, og løsningen på hver af dem ligner slet ikke løsningen på den anden.
Ét ping deler problemet i to
Fra én klient pinges den anden klients tunneladresse, ikke dens navn og ikke dens LAN-adresse. Hvis det fejler, er videresendelse eller adressering problemet, og opdagelse er irrelevant, indtil det er rettet. Hvis det lykkes, virker videresendelsen allerede, og det resterende gab er broadcast eller navneopløsning.
ip addr show tun0Læs klientens interface før alt andet, fordi netmasket navngiver topologien. En /24 eller et andet subnetmaske betyder en delt pulje; en /30 med en peer-adresse betyder det ældre punkt-til-punkt-layout, hvor hver klient har præcis én nabo, serveren.
net30 kontra subnet, læst fra klientsiden
| 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 |
Med net30 uddeler serveren en lille blok pr. klient, så der findes ikke en rute til en anden klients tunneladresse, medmindre serveren videresender den. Med subnet er hele puljen ét netværk, hver klient kan adressere hver anden, og serveren videresender mellem dem. Derfor kan én serverkonfiguration se sund ud, mens peer-pings fejler: intet er i stykker, klienterne er simpelthen ikke i ét netværk. Klienten ser et fungerende link og en peer-adresse, der ikke svarer, hvilket lyder som en firewall, men er et adresseringslayout.
At skifte direktivet er en redigering på serversiden plus en genstart, og det gælder for den næste forbindelse snarere end for sessioner, der allerede er oppe. Genopret klienternes forbindelse, før du vurderer ændringen. Hvis et apparat genskaber konfigurationen fra en webgrænseflade, så noter direktivet, filen og datoen, og foretag redigeringen gennem grænsefladen, når der er en, fordi en genopbygning vil overskrive en håndredigering ved næste gemning.
client-to-client er en separat sluse
Selv inden for ét subnet kasserer serveren pakker, der kommer fra én klient og er adresseret til en anden, medmindre client-to-client er sat. Det nøgleord gør serveren til en videresender af peer-trafik i stedet for et endepunkt, der kun accepterer den. Det er den anden betingelse, folk overser efter at have rettet topologien.
Det strækker sig ikke til broadcast. Indstillingen videresender unicast mellem klienter; den gør ikke tunnelen til et delt segment, og ingen mængde af den vil levere en multicast-opdagelsesforespørgsel til hver peer.
TUN kontra TAP, og hvad hver kan bære
| 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 |
At brokoble en tap-enhed ind i LAN'et placerer fjernklienter i kontorets broadcast-domæne, hvilket løser opdagelse fuldstændigt. Prisen er de platforme, der ikke implementerer TAP, en bro der skal findes på serveren, og et fejldomæne, hvor en broadcast-storm på kontorledningen når hver fjern laptop.
Til to eller tre arbejdsstationer, der har brug for navneopløsning, er en hosts-post eller en unicast-adresse langt billigere end en bro. Grib efter TAP, når en protokol, du ikke kan erstatte, afhænger af opdagelse på lag 2, og ikke før.
Klienter i samme subnet uden en bro
At tildele en adresse fra LAN-intervallet sætter ikke klienten på ledningen. Serveren router mellem tunnel og Ethernet, så ARP for den adresse stopper ved serverens interface, og resten af LAN'et finder aldrig ud af, hvor den bor.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP lukker det gab ved at lade serveren svare på klientens vegne. For et interval administrerer parpd indgangene, efterhånden som klienter kommer og går, mens sysctl net.ipv4.conf.eth0.proxy_arp=1 svarer for alt, der routes andetsteds hen, hvilket er bredt nok til at skabe sine egne overraskelser på et travlt segment.
Uanset hvilken vej du vælger, skal du fjerne NAT mellem tunnelen og ledningen. En MASQUERADE-regel skjuler netop det adresseringsspørgsmål, du forsøger at besvare. Den efterlader også den næste person med en topologi, som de ikke kan ræsonnere om fra klientsiden.
Før du ændrer noget, fang ét forsøg på serveren med tcpdump -ni tun0 og bekræft, om peer-pakken overhovedet ankommer. At den ankommer og kasseres peger på client-to-client; at den aldrig ankommer peger på topologi eller routing. OpenVPN 2.6-manualen dokumenterer begge nøgleord og standardtopologien, hvilket er værd at tjekke mod din version, før du kopierer en linje fra et forumindlæg.
- tun-interfacet viser en puljemaske i stedet for et /30-peer-par.
- Et direkte ping til den anden tunneladresse lykkes, før du tester opdagelse.
- Serverkonfigurationen indeholder
client-to-client, når peers skal udveksle pakker. - Navngiv den opdagelsesprotokol, du tester, i stedet for at sige, at appen fejler.
- Brug kun TAP, hvis hver klientplatform i gruppen understøtter det.
- Hold NAT ude af vejen mellem tunnel og LAN, når nåbarhed inden for samme subnet betyder noget.