Os clientes de OpenVPN non se ven entre si: subrede ou net30?

Dúas fallas sen relación producen a mesma queixa. Na primeira, un cliente non chega a outro nin por enderezo de túnel, porque os enderezos non están nunha soa subrede ou o servidor non reenvía o tráfico entre pares. Na segunda, ping funciona e a lista de dispositivos da aplicación queda baleira, porque o descubrimento depende de broadcast que un túnel de capa 3 non pode transportar. Un só ping sepáraas, e a solución de cada unha non se parece nada á da outra.

Un só ping parte o problema en dous

Desde un cliente, faga ping ao enderezo de túnel do outro cliente, non ao seu nome nin ao seu enderezo de LAN. Se falla, o problema é o reenvío ou o enderezamento e o descubrimento é irrelevante ata que se corrixa. Se funciona, o reenvío xa funciona e o que falta é broadcast ou resolución de nomes.

ip addr show tun0

Lea a interface do cliente antes que nada, porque a máscara de rede nomea a topoloxía. Unha /24 ou outra máscara de subrede significa un pool compartido; unha /30 con enderezo de par significa o deseño antigo punto a punto, onde cada cliente ten exactamente un veciño, o servidor.

net30 fronte a subrede, lido desde o lado do cliente

Con net30 o servidor reparte un bloque pequeno por cliente, así que non existe unha ruta cara ao enderezo de túnel doutro cliente salvo que o servidor a reenvíe. Con subrede todo o pool é unha rede, cada cliente pode dirixirse a calquera outro e o servidor reenvía entre eles. Por iso unha configuración de servidor pode parecer san mentres os ping entre pares fallan: nada está roto, simplemente os clientes non están nunha soa rede. O cliente ve unha ligazón que funciona e un enderezo de par que non responde, o que se le como unha devasa pero é un deseño de enderezamento.

Cambiar a directiva é unha edición do lado do servidor máis un reinicio, e aplícase á seguinte conexión, non ás sesións xa establecidas. Volva conectar os clientes antes de xulgar o cambio. Se un aparello rexenera a configuración desde unha interface web, anote a directiva, o ficheiro e a data, e faga a edición mediante a interface cando exista, porque unha reconstrución sobrescribirá unha edición manual no seguinte gardado.

client-to-client é unha porta aparte

Mesmo dentro dunha soa subrede o servidor descarta os paquetes que chegan dun cliente e van dirixidos a outro salvo que client-to-client estea activado. Esa palabra clave converte o servidor nun reenviador do tráfico entre pares en lugar dun extremo que só o acepta. É a segunda condición que a xente pasa por alto tras arranxar a topoloxía.

Non se estende a broadcast. O axuste reenvía unicast entre clientes; non converte o túnel nun segmento compartido, e ningunha cantidade diso entregará unha consulta de descubrimento multicast a todos os pares.

TUN fronte a TAP, e que pode transportar cada un

Pontear un dispositivo tap cara á LAN coloca os clientes remotos no dominio de broadcast da oficina, o que resolve o descubrimento por completo. O prezo son as plataformas que non implementan TAP, unha ponte que debe existir no servidor e un dominio de fallo onde unha tormenta de broadcast no cable da oficina alcanza cada portátil remoto.

Para dúas ou tres estacións de traballo que necesitan resolución de nomes, unha entrada hosts ou un enderezo unicast é moito máis barata ca unha ponte. Recorra a TAP cando un protocolo que non pode substituír dependa do descubrimento de capa 2, e non antes.

Clientes da mesma subrede sen ponte

Asignar un enderezo do rango da LAN non pon o cliente no cable. O servidor encamiña entre túnel e Ethernet, así que o ARP para ese enderezo detense na interface do servidor e o resto da LAN nunca sabe onde vive.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP pecha esa fenda facendo que o servidor responda no nome do cliente. Para un rango, parpd xestiona as entradas a medida que os clientes entran e saen, mentres que o sysctl net.ipv4.conf.eth0.proxy_arp=1 responde por todo o que se encamiña a outro sitio, o cal é abondo amplo como para crear as súas propias sorpresas nun segmento ocupado.

Escolla a ruta que escolla, quite NAT entre o túnel e o cable. Unha regra MASQUERADE oculta exactamente a pregunta de enderezamento que intenta responder. Tamén deixa á seguinte persoa unha topoloxía sobre a que non pode razoar desde o lado do cliente.

Antes de cambiar nada, capture un intento no servidor con tcpdump -ni tun0 e confirme se o paquete do par chega secasí. Que chegue e se descarte apunta a client-to-client; que nunca chegue apunta a topoloxía ou encamiñamento. O manual de OpenVPN 2.6 documenta ambas as palabras clave e a topoloxía predeterminada, algo que paga a pena contrastar coa súa versión antes de copiar unha liña dunha mensaxe de foro.

• A interface tun mostra unha máscara de pool en lugar dun par /30.
• Un ping directo ao outro enderezo de túnel funciona antes de probar o descubrimento.
• A configuración do servidor inclúe client-to-client sempre que os pares deban intercambiar paquetes.
• Nomee o protocolo de descubrimento que está a probar en lugar de dicir que a aplicación falla.
• Use TAP só se todas as plataformas cliente do grupo o admiten.
• Manteña NAT fóra do camiño entre túnel e LAN cando importe o alcance dentro da mesma subrede.