Precisa cada peer de OpenVPN unha liña remote? Non exactamente

Compáranse dúas configuracións de peer unha ao lado da outra, unha ten unha liña remote e a outra non, e a conclusión é que unha delas está rota. Esa inferencia é errónea con suficiente frecuencia como para merecer unha análise. A directiva describe a onde debe enviarse o primeiro paquete. Non selecciona se o proceso actúa como cliente que inicia ou como pasarela que espera, e non decide que lado demostra a súa identidade ante o outro.

Que especifica realmente remote

Unha entrada remote nomea un host, opcionalmente un porto e un transporte, e opcionalmente varias desas entradas que se proban en orde.

A súa ausencia ten un significado definido e non indefinido: o proceso espera e non actúa sobre paquetes dun enderezo a non ser que ese peer se autentique. Por iso unha pasarela que atende usuarios itinerantes non ten motivo para nomear a ningún deles de antemán.

Le a entrada como unha relación de enderezos. Se se confía no extremo remoto respóndeno os certificados e as opcións de verificación, non o feito de que se escribise un enderezo.

Tres disposicións deciden a resposta

Un cliente itinerante necesita un destino, porque debe iniciar e sen un non sabe onde está a pasarela. Unha pasarela para varios clientes non necesita un destino por usuario, porque os clientes chegan e autentícanse. Unha ligazón deliberada entre dous peers con extremos coñecidos pode ter destino nun lado, en ambos ou en ningún, segundo que lado inicie.

Pegar un enderezo de cliente fixo nunha pasarela xeral é o erro que se deriva de ignorar esas categorías. Funciona para o único peer cuxo enderezo se rexistrou e engana a todos os demais.

Nada na directiva converte unha configuración nun servidor para varios clientes, e nada na súa presenza impide un papel de servidor. A referencia de OpenVPN 2.6 documenta os argumentos opcionais e o comportamento sen remote por separado, o que é unha pista de ata que punto son independentes.

Os papeis de transporte son outro eixo

Con TCP, un lado espera e o outro establece a conexión. Son directivas separadas do destino, e mesturalas produce unha parella na que ambos esperan ou ambos establecen a conexión.

Tamén existe un papel de filtro de orixe TCP, e por iso é incorrecta a afirmación tallante de que un servidor non pode conter nunca remote.

Con UDP non hai conexión que establecer, así que ambos os extremos usan o transporte UDP correspondente e a directiva só di cara a onde apuntar. Os cambios de enderezo dun peer autenticado xestiónanse cun comportamento dedicado e non engadindo máis entradas. Acertar co transporte é unha condición previa para que o destino signifique algo, e confundir ambos produce configuracións que parecen plausibles e nunca completan un handshake.

Por que un remote ausente non é unha porta aberta

Un proceso sen destino segue rexeitando o tráfico de peers que non se autentican, e esa é a parte que a xente pasa por alto cando le a liña ausente como un oínte aberto a calquera.

A autenticación e o destino son independentes, e a primeira é a que importa para a confianza.

O erro inverso é máis perigoso. Un enderezo de orixe fixo pode parecer un control de acceso porque é concreto e fácil de comprobar, pero non demostra nada sobre quen está ao outro lado. Conserva a verificación de certificados e as comprobacións de identidade que vinculan un certificado co seu papel. Substituílas por unha coincidencia de enderezos cambia un control real pola aparencia dun.

Anota que asume a configuración

Para cada lado, rexistra tres cousas: como chega o primeiro paquete ao peer, que lado pode aceptar o transporte e que verifica cada lado sobre o outro.

Eses supostos son o deseño. As directivas só son a súa escritura.

Se os dous ficheiros difiren, comproba se expresan supostos distintos en lugar de supoñer que un está mal. Unha parella simétrica de ficheiros non é necesaria nin suficiente para un túnel funcional, e a asimetría adoita ser a parte que fai funcionar unha topoloxía.