OpenVPN-klanten sjogge inoar net: subnet of net30?
Klanten berikke de tsjinner mar net inoar. Skied it fal mei ien ping en kies dan subnet-topology, client-to-client of in oerbrêge TAP-segmint.
Twa ûnôfhinklike fouten jouwe deselde klacht. Yn 'e earste kin in klant in oare sels net fia tunneladres berikke, om't de adressen net yn ien subnet sitte of de tsjinner it ferkear tusken pearen net trochjout. Yn 'e twadde wurket ping en bliuwt de apparatlist fan 'e applikaasje leech, om't ûntdekking berint op broadcast dat in tunnel fan laach 3 net drage kin. Ien ping skiedt se, en de reparaasje foar elk liket hielendal net op dy foar de oare.
Ien ping spjaltet it probleem yn twaen
Ping fan ien klant nei it tunneladres fan 'e oare klant, net nei syn namme en net nei syn LAN-adres. As dat mislearret, is trochjaan of adressearjen it probleem en is ûntdekking net relevant oant dat reparearre is. As it slagget, wurket trochjaan al en is it oerbleaune gat broadcast of namme-oplossing.
ip addr show tun0Lês de ynterface fan 'e klant foar al it oare, om't it netmasker de topology neamt. In /24 of in oar subnetmasker betsjut in dielde pool; in /30 mei in pearadres betsjut de âldere punt-nei-punt-yndieling, wêr't elke klant krekt ien buorman hat, de tsjinner.
net30 tsjin subnet, lêzen fan 'e klantkant
| 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 |
Mei net30 jout de tsjinner in lyts blok per klant, dus bestiet der gjin rûte nei it tunneladres fan in oare klant, útsein as de tsjinner dy trochjout. Mei subnet is de hiele pool ien netwurk, elke klant kin elke oare adressearje, en de tsjinner jout troch tusken har. Dêrom kin ien tsjinnerkonfiguraasje sûn lykje wylst ping tusken pearen mislearret: neat is stikken, de klanten sitte gewoan net yn ien netwurk. De klant sjocht in wurkjende ferbining en in pearadres dat net antwurdet, wat as in firewall lêst mar in adressearringsútlizzing is.
It feroarjen fan 'e rjochtline is in bewurking oan 'e tsjinnerkant plus in werstart, en it jildt foar de folgjende ferbining ynstee fan foar sesjes dy't al iepen binne. Ferbynje de klanten op 'e nij foardat jo de feroaring beoardielje. As in apparaat de konfiguraasje op 'e nij generearret út in webynterface, skriuw dan de rjochtline, it bestân en de datum op, en meitsje de bewurking fia de ynterface as dy der is, om't in weropbou in hânmjittige bewurking by it folgjende bewarjen oerskriuwt.
client-to-client is in aparte poarte
Sels binnen ien subnet smyt de tsjinner pakketten fuort dy't fan ien klant komme en oan in oare adressearre binne, útsein as client-to-client oan stiet. Dat kaaiwurd makket de tsjinner in trochjouwer foar ferkear tusken pearen ynstee fan in einpunt dat it allinne mar akseptearret. It is de twadde betingst dy't minsken misse nei't se de topology reparearre hawwe.
It wreidet him net út nei broadcast. De ynstelling jout unicast troch tusken klanten; it makket de tunnel net in dield segmint, en gjin inkel bedrach dêrfan sil in multicast-ûntdekkingsfraach by elke pear ôflêze.
TUN tsjin TAP, en wat elk drage kin
| 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 |
It oerbrêgjen fan in tap-apparaat yn it LAN set fiere klanten yn it broadcast-domein fan it kantoar, wat ûntdekking folslein oplost. De priis is de platfoarmen dy't TAP net ymplementearje, in brêge dy't op 'e tsjinner bestean moat, en in flaterdomein wêr't in broadcast-stoarm op 'e kantoarkabel elke fiere laptop berikt.
Foar twa of trije wurkstasjons dy't namme-oplossing nedich hawwe, is in hosts-ynfier of in unicast-adres folle goedkeaper as in brêge. Griip nei TAP as in protokol dat jo net ferfange kinne fan ûntdekking op laach 2 ôfhinget, en net earder.
Klanten yn itselde subnet sûnder brêge
It tawizen fan in adres út it LAN-berik set de klant net op 'e kabel. De tsjinner rûtet tusken tunnel en Ethernet, dus ARP foar dat adres stopt by de ynterface fan 'e tsjinner en de rest fan it LAN leart nea wêr't it wennet.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP slút dat gat troch de tsjinner yn namme fan 'e klant antwurdzje te litten. Foar in berik beheart parpd de ynfieringen wylst klanten komme en gean, wylst de sysctl net.ipv4.conf.eth0.proxy_arp=1 antwurdet foar alles wat earne oars hinne rûte wurdt, wat breed genôch is om syn eigen ferrassingen op in drok segmint te meitsjen.
Hokker rûte jo ek kieze, helje NAT fuort tusken de tunnel en de kabel. In MASQUERADE-regel ferberget krekt de adressearringsfraach dy't jo besykje te beantwurdzjen. It lit de folgjende persoan ek in topology nei dêr't dy net fan 'e klantkant oer neitinke kin.
Foardat jo wat feroarje, fang ien besykjen op 'e tsjinner mei tcpdump -ni tun0 en befestigje oft it pearpakket hielendal oankomt. Oankomme en fuortsmiten wurde wiist op client-to-client; nea oankomme wiist op topology of rûtering. It OpenVPN 2.6-hânboek dokumintearret beide kaaiwurden en de standerttopology, wat it wurdich is om tsjin jo ferzje te kontrolearjen foardat jo in rigel út in forumberjocht kopiearje.
- De tun-ynterface toant in poolmasker ynstee fan in /30-pearpear.
- In direkte ping nei it oare tunneladres slagget foardat jo ûntdekking testje.
- De tsjinnerkonfiguraasje befettet
client-to-clientelke kear as pearen pakketten útwikselje moatte. - Neam it ûntdekkingsprotokol dat jo testje ynstee fan te sizzen dat de app mislearret.
- Brûk TAP allinne as elk klantplatfoarm yn 'e groep it stipet.
- Hâld NAT bûten it paad tusken tunnel en LAN as berikberens binnen itselde subnet fan belang is.