Usamos OpenVPN: protocolo, motor ou aplicativo? O que perguntar em vez disso

A frase «usamos OpenVPN» chega em tickets, formulários de compra e documentos de integração, e em cada um responde a uma pergunta diferente. Às vezes nomeia um protocolo de transporte, às vezes o software de um gateway e às vezes o aplicativo que uma pessoa nova precisa instalar. Esses três fatos levam a passos seguintes diferentes, e perguntar qual é o pretendido leva menos tempo do que adivinhar. O resto da investigação decorre dessa resposta.

Comece separando o papel da marca, porque a marca cobre os três.

O nome cobre três papéis que falham de formas diferentes

Como protocolo, o OpenVPN descreve como pares compatíveis estabelecem um túnel e protegem o que o atravessa. Como software, é uma implementação que fala esse protocolo num papel de cliente ou de servidor. Como cliente, é um aplicativo que alguém instala, com a sua própria versão, o seu formato de perfil e as suas peculiaridades de plataforma. Uma falha num papel não implica uma falha noutro, e é por isso que «o OpenVPN está em baixo» precisa de um sujeito.

Pergunte o que quem reporta consegue ver: um ficheiro de perfil, um programa instalado ou um gateway que administra. Esse único detalhe diz-lhe se o passo seguinte é um registo do cliente, uma pergunta sobre o pacote ou uma verificação do ouvinte do lado do servidor.

OpenVPN 2 e OpenVPN 3 não são um par de atualização

O OpenVPN 2.x funciona tanto no papel de servidor como de cliente, e é o que a maioria das implantações de gateway ainda usa. O OpenVPN 3 é uma implementação separada orientada ao cliente, com a sua própria configuração e o seu próprio modelo de sessão, não a versão seguinte que se instala por cima de um servidor 2.x. O OpenVPN Connect é um aplicativo de cliente construído sobre o motor OpenVPN 3. Instalar qualquer deles não cria um serviço de saída para a internet; a saída é o que o operador tiver configurado.

A compatibilidade ao nível do protocolo não se estende às diretivas do perfil, por isso um perfil que se importa sem erros pode ainda falhar numa diretiva que o cliente não implementa.

O transporte não é o aplicativo lá dentro

A ligação exterior usa um transporte como UDP ou TCP para chegar a um ouvinte configurado, e tudo o que o túnel transporta viaja lá dentro. Um pedido web feito através da VPN não precisa do seu próprio ouvinte OpenVPN e não se torna um pacote OpenVPN no fio. Em modo TLS o canal de controlo negocia o material de chaves enquanto o canal de dados protege a carga útil, e é uma separação que vale a pena manter correta ao ler registos.

Confundir as camadas produz pedidos como abrir uma porta para um sítio que já funciona através do túnel. A porta pertence à ligação exterior, não ao aplicativo.

O que um perfil pode prometer e o que não pode

Um perfil diz a um cliente como chegar a um serviço: ponto final, transporte, material de identidade e, muitas vezes, algumas preferências de encaminhamento e DNS. Não diz nada sobre quem opera esse serviço nem sobre se a conta está autorizada. As rotas, as definições do resolvedor, as regras de reencaminhamento e a política de acesso decidem aquilo a que a sessão chega realmente. Um perfil que se importa corretamente é o início de uma ligação funcional, não a prova de que o seja.

Quando alguém pergunta se um recurso é alcançável pela VPN, a resposta depende da política do servidor e não do ficheiro de configuração do cliente.

Peça o que pode ser aprovisionado

Converta o nome amplo em três concretizações: o cliente e a sua versão, o perfil autorizado para esse cliente e o recurso a que a pessoa precisa de chegar. Com elas, o aprovisionamento é uma tarefa concreta. Sem elas, cada resposta é um palpite sobre qual OpenVPN a pergunta queria dizer.

Registe a resposta no próprio pedido. O próximo ticket fará a mesma pergunta da mesma forma ambígua.