Els clients d'OpenVPN no es veuen entre ells: subxarxa o net30?

Dues fallades sense relació produeixen la mateixa queixa. En la primera, un client no arriba a un altre ni per adreça de túnel, perquè les adreces no són en una sola subxarxa o el servidor no reenvia el trànsit entre parells. En la segona, el ping funciona i la llista de dispositius de l'aplicació resta buida, perquè el descobriment depèn d'un broadcast que un túnel de capa 3 no pot transportar. Un sol ping les separa, i la solució de cadascuna no s'assembla gens a la de l'altra.

Un sol ping parteix el problema en dos

Des d'un client, feu ping a l'adreça de túnel de l'altre client, no al seu nom ni a la seva adreça de LAN. Si falla, el problema és el reenviament o l'adreçament i el descobriment no hi té res a veure fins que no es corregeixi. Si funciona, el reenviament ja funciona i el que falta és broadcast o resolució de noms.

ip addr show tun0

Llegiu la interfície del client abans que res, perquè la màscara de xarxa diu la topologia. Una /24 o una altra màscara de subxarxa vol dir un pool compartit; una /30 amb adreça de parell vol dir el disseny antic punt a punt, on cada client té exactament un veí, el servidor.

net30 enfront de subxarxa, llegit des del costat del client

Amb net30 el servidor reparteix un bloc petit per client, així que no existeix cap ruta cap a l'adreça de túnel d'un altre client tret que el servidor la reenviï. Amb subxarxa tot el pool és una xarxa, cada client pot adreçar-se a qualsevol altre i el servidor reenvia entre ells. Per això una configuració de servidor pot semblar sana mentre els pings entre parells fallen: no hi ha res trencat, simplement els clients no són en una sola xarxa. El client veu un enllaç que funciona i una adreça de parell que no respon, cosa que sembla un tallafoc però és un disseny d'adreçament.

Canviar la directiva és una edició al costat del servidor més un reinici, i s'aplica a la connexió següent, no a les sessions ja establertes. Torneu a connectar els clients abans de jutjar el canvi. Si un aparell regenera la configuració des d'una interfície web, anoteu la directiva, el fitxer i la data, i feu l'edició per la interfície quan n'hi hagi, perquè una reconstrucció sobreescriurà una edició manual al desament següent.

client-to-client és una porta a part

Fins i tot dins d'una sola subxarxa el servidor descarta els paquets que arriben d'un client i van adreçats a un altre tret que client-to-client estigui activat. Aquesta paraula clau converteix el servidor en un reenviador del trànsit entre parells en lloc d'un extrem que només l'accepta. És la segona condició que la gent passa per alt després d'arreglar la topologia.

No s'estén al broadcast. El paràmetre reenvia unicast entre clients; no converteix el túnel en un segment compartit, i cap quantitat no farà arribar una consulta de descobriment multicast a tots els parells.

TUN enfront de TAP, i què pot transportar cadascun

Pontar un dispositiu tap a la LAN posa els clients remots al domini de broadcast de l'oficina, cosa que resol el descobriment del tot. El preu són les plataformes que no implementen TAP, un pont que ha d'existir al servidor i un domini de fallada on una tempesta de broadcast al cable de l'oficina arriba a cada portàtil remot.

Per a dues o tres estacions de treball que necessiten resolució de noms, una entrada hosts o una adreça unicast és molt més barata que un pont. Recurrí a TAP quan un protocol que no podeu substituir depèn del descobriment de capa 2, i no abans.

Clients de la mateixa subxarxa sense pont

Assignar una adreça del rang de la LAN no posa el client al cable. El servidor encamina entre túnel i Ethernet, així que l'ARP per a aquesta adreça s'atura a la interfície del servidor i la resta de la LAN no sap mai on viu.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP tanca aquesta bretxa fent que el servidor respongui en nom del client. Per a un rang, parpd gestiona les entrades a mesura que els clients entren i surten, mentre que el sysctl net.ipv4.conf.eth0.proxy_arp=1 respon per tot el que s'encamina enlloc, cosa prou àmplia per crear les seves pròpies sorpreses en un segment ocupat.

Prengueu la ruta que prengueu, traieu el NAT entre el túnel i el cable. Una regla MASQUERADE amaga exactament la pregunta d'adreçament que intenteu respondre. També deixa a la persona següent una topologia sobre la qual no pot raonar des del costat del client.

Abans de canviar res, captureu un intent al servidor amb tcpdump -ni tun0 i confirmeu si el paquet del parell arriba. Que arribi i es descarti apunta a client-to-client; que no arribi mai apunta a topologia o encaminament. El manual d'OpenVPN 2.6 documenta les dues paraules clau i la topologia per defecte, cosa que val la pena contrastar amb la vostra versió abans de copiar una línia d'un missatge de fòrum.

• La interfície tun mostra una màscara de pool en lloc d'una parella /30.
• Un ping directe a l'altra adreça de túnel funciona abans de provar el descobriment.
• La configuració del servidor inclou client-to-client sempre que els parells hagin d'intercanviar paquets.
• Anomeneu el protocol de descobriment que proveu en lloc de dir que l'aplicació falla.
• Useu TAP només si totes les plataformes de client del grup el suporten.
• Manteniu el NAT fora del camí entre túnel i LAN quan importa l'abast dins de la mateixa subxarxa.