Usamos OpenVPN: protocolo, motor ou aplicación? Que preguntar no seu lugar

A frase «usamos OpenVPN» chega en tíckets, formularios de compra e documentos de incorporación, e en cada un responde a unha pregunta distinta. Ás veces nomea un protocolo de transporte, ás veces o software dunha pasarela e ás veces a aplicación que debe instalar unha persoa nova. Eses tres feitos levan a pasos seguintes distintos, e preguntar cal se quere dicir custa menos tempo que adiviñalo. O resto da investigación dedúcese desa resposta.

Comece separando o rol da marca, porque a marca cobre os tres.

O nome cobre tres roles que fallan de xeito distinto

Como protocolo, OpenVPN describe como os pares compatibles establecen un túnel e protexen o que o atravesa. Como software, é unha implementación que fala ese protocolo en rol de cliente ou de servidor. Como cliente, é unha aplicación que alguén instala, coa súa propia versión, o seu formato de perfil e as súas peculiaridades de plataforma. Un fallo nun rol non implica un fallo noutro, e por iso «OpenVPN está caído» necesita un suxeito.

Pregunte que pode ver quen o informa: un ficheiro de perfil, un programa instalado ou unha pasarela que administra. Ese único detalle dille se o paso seguinte é un rexistro do cliente, unha pregunta sobre o paquete ou unha comprobación do oínte no lado do servidor.

OpenVPN 2 e OpenVPN 3 non son unha parella de actualización

OpenVPN 2.x funciona tanto en rol de servidor como de cliente, e é o que aínda usa a maioría dos despregamentos de pasarela. OpenVPN 3 é unha implementación á parte orientada ao cliente, coa súa propia configuración e o seu propio modelo de sesión, non a seguinte versión que se instala sobre un servidor 2.x. OpenVPN Connect é unha aplicación de cliente construída sobre o motor OpenVPN 3. Instalar calquera delas non crea un servizo de saída a internet; a saída é o que configurase o operador.

A compatibilidade a nivel de protocolo non se estende ás directivas do perfil, así que un perfil que se importa limpiamente pode fallar nunha directiva que o cliente non implementa.

O transporte non é a aplicación que leva dentro

A conexión exterior usa un transporte como UDP ou TCP para chegar a un oínte configurado, e todo o que o túnel transporta viaxa dentro del. Unha petición web feita a través da VPN non necesita o seu propio oínte OpenVPN e non se converte nun paquete OpenVPN polo cable. En modo TLS o canal de control negocia o material de claves mentres o canal de datos protexe a carga útil, e é unha separación que convén manter correcta ao ler rexistros.

Confundir as capas produce peticións como abrir un porto para un sitio web que xa funciona a través do túnel. O porto pertence á conexión exterior, non á aplicación.

Que pode prometer un perfil e que non

Un perfil di a un cliente como chegar a un servizo: punto final, transporte, material de identidade e a miúdo algunhas preferencias de encamiñamento e DNS. Non di nada sobre quen opera ese servizo nin sobre se a conta está autorizada. As rutas, os axustes do resolutor, as regras de reenvío e a política de acceso deciden a que chega realmente a sesión. Un perfil que se importa correctamente é o comezo dunha conexión funcional, non a proba de que o sexa.

Cando alguén pregunta se un recurso é alcanzable pola VPN, a resposta depende da política do servidor e non do ficheiro de configuración do cliente.

Pida o que se pode aprovisionar

Converta o nome amplo en tres concrecións: o cliente e a súa versión, o perfil autorizado para ese cliente e o recurso ao que a persoa necesita chegar. Con elas, o aprovisionamento é unha tarefa concreta. Sen elas, cada resposta é unha conxectura sobre que OpenVPN quería dicir a pregunta.

Anote a resposta na propia solicitude. O seguinte tícket fará a mesma pregunta do mesmo xeito ambiguo.