Un servidor TAP ou varios? Clientes OpenVPN nunha ponte

Varios clientes TAP non requiren un proceso de servidor, un porto UDP e un dispositivo TAP do host para cada un. Un servidor OpenVPN en modo Ethernet pode admitir moitos clientes autenticados e conectalos a unha única ponte, e esa é a forma documentada de estender un segmento de capa 2. O deseño dun só proceso é o que documenta o manual e adoita ser o valor predeterminado correcto.

A verdadeira pregunta é se eses clientes deberían compartir ese segmento. O número de procesos non a responde, porque as propiedades de illamento veñen da topoloxía e non de cantos daemons se executan. O resto desta comparación trata das dúas topoloxías e do que cada unha facilita.

Dúas arquitecturas, non dous axustes

Un despregamento TUN encamiñado dá a cada cliente unha ligazón punto a punto cara ao dominio de encamiñamento do servidor. As difusións detéñense no servidor, os clientes non ven as tramas dos demais e o tráfico entre clientes, se existe, debe encamiñarse e filtrarse de forma explícita.

Un despregamento TAP empontado fai que os clientes sexan membros dun mesmo segmento Ethernet. Ven as difusións, poden resolverse entre si con ARP e dependen da política da ponte e da devasa en lugar do encamiñamento para manterse separados. Iso é útil cando os clientes deben aparecer como se estivesen conectados ao mesmo conmutador.

A comparación trata, pois, do que os clientes deben acadar, non do rendemento. Escolla primeiro a capa e despois decida cantos procesos a serven.

Que fai o axudante server-bridge

O axudante server-bridge configura o modo Ethernet para varios clientes. A súa forma de grupo de enderezos toma a porta de enlace, a máscara de rede e un rango dedicado dentro da subrede empontada, por exemplo unha porta de enlace en 192.168.50.1 cun grupo de 192.168.50.160 a 192.168.50.199.

Reserve ese rango fóra de calquera outra asignación DHCP ou estática. O axudante asigna enderezos del, pero non se coordina con outro asignador no mesmo segmento, e dous grupos solapados producen enderezos duplicados que parecen fallos de conectividade aleatorios. Escriba o rango reservado no plan de enderezos do sitio para que a seguinte persoa non o reutilice. Un comentario na configuración do servidor é un substituto pobre dese rexistro.

Existe unha forma con proxy DHCP para despregamentos nos que un servidor externo reparte enderezos. Ten os seus propios requisitos previos, e mesturar as dúas formas produce exactamente o conflito que advirte a documentación. Escolla un só asignador para a subrede empontada.

O illamento non vén do número de procesos

Oito procesos OpenVPN conectados á mesma ponte sen restricións seguen compartindo un dominio de difusión. Os clientes poden facer ARP entre eles a través da ponte, e o número de escoitas non cambiou nada diso.

Se o requisito é que grupos de clientes non se vexan entre si na capa 2, o deseño necesita pontes separadas ou conexións VLAN, xunto coas regras de acceso correspondentes. É unha decisión de deseño de rede e é a mesma tanto se intervé un proceso de servidor como oito. O filtrado da ponte pode restrinxir parte do tráfico, pero non crea dominios de difusión separados. Tráteo como un complemento da segmentación, non como un substituto.

Se o requisito é só que os clientes cheguen a determinados servizos IP, un deseño TUN encamiñado adoita ser máis simple que empontar con filtrado. Cada cliente obtén a súa propia ligazón, e a política vive nas regras de encamiñamento e da devasa en lugar do interior da ponte.

Cando varios procesos seguen sendo correctos

Os procesos separados poden xustificarse por necesidades operativas: distintos backends de autenticación, distintas autoridades de certificación, ciclos de actualización separados ou conxuntos de opcións incompatibles. Son razóns reais e son independentes do número de clientes.

Se usa varios, dea a cada un o seu propio escoitante e a propiedade do seu dispositivo, e coordine os rangos de enderezos. Dous servidores que ambos cren posuír o mesmo grupo na mesma ponte acabarán repartindo o mesmo enderezo.

Despois verifique o deseño con varios clientes á vez. Comprobe que os enderezos son únicos, que o tráfico previsto entre clientes funciona e que unha parella que non debe comunicarse non pode facelo. Un ping correcto dun só cliente non exercita nada do deseño para varios clientes.

Lea a ponte e o modo do servidor desde o host en execución antes de confiar no diagrama. A configuración que importa é a que o núcleo e o daemon cargaron realmente, e é tamén a que un revisor pode comprobar.