Que roles de software necesita unha porta de enlace OpenVPN sen pantalla

Unha máquina dedicada a unha porta de enlace OpenVPN necesita unha instalación de servidor compatible e o software para as tarefas que realmente realiza. Un menú de instalación que ofrece SSH, aloxamento web e outros roles de servidor non é unha lista de requisitos previos de OpenVPN. Un despregue sen pantalla é totalmente razoable. O importante é separar tres tarefas: transportar o túnel, administrar o host e emitir credenciais.

Esta é a orde de inventario que utilizo, coa comprobación que pecha cada paso.

1. Dalle ao servizo de túnel o seu propio paquete e perfil

A guía do servidor OpenVPN de Ubuntu utiliza o paquete openvpn da distribución cunha liña de comandos e unha configuración de servizo. O mesmo paquete serve como cliente de Linux, e a configuración escolle o rol.

Iso significa que instalar un GUI de cliente non é o que converte o host en servidor, e retiralo non é o que o fai sen pantalla. Anota que perfil le a instancia en execución, porque un segundo ficheiro de configuración no mesmo directorio pode cargarse sen que ninguén o note, e o daemon informa de éxito en ambos os casos. Cando existen dous perfís, o xestor de servizos decide cal gaña, e esa decisión pertence ás túas notas e non a unha suposición.

2. Decide a vía de administración antes que o túnel

OpenSSH procede dun paquete openssh-server aparte e execútase como o seu propio servizo. É útil cando un administrador debe chegar á máquina por SSH, pero OpenVPN non necesita un servidor SSH para intercambiar paquetes VPN. Unha consola local ou unha canle de xestión de plataforma aprobada é outra vía válida. Decide en cal confías antes de cambiar o encamiñamento ou o filtrado, porque un túnel novo nunca debería ser a única forma non probada de repararse a si mesmo.

3. Emite credenciais desde o propietario aprobado

O exemplo de Ubuntu instala easy-rsa xunto a OpenVPN para construír unha PKI pequena, o que é un rol de emisión de credenciais e non un servizo de túnel en funcionamento. Se a organización xa ten un proceso de emisión aprobado, úsao en lugar de crear unha CA non relacionada porque un tutorial inclúa unha. Mantén a clave privada e o certificado da porta de enlace separados da clave de sinatura da CA, e escolle deliberadamente a localización de sinatura e de copia de seguridade. Copiar cada ficheiro de PKI en cada host non é un requisito de software.

4. Deixa os complementos de escritorio aos escritorios

Un editor de NetworkManager ou un complemento de importación ten un propósito nunha máquina que usa ese fluxo de traballo. Non é unha función de servidor adicional necesaria porque a porta de enlace fale OpenVPN.

Escolle un único propietario para a conexión, e non inicies unha segunda copia do mesmo perfil xestionada desde o escritorio.

5. Aceita a porta de enlace cun cliente real

Menos paquetes non é unha porta de enlace rematada. O servidor aínda necesita un escoitador aprobado, identidades, rutas, reenvío onde faga falta, unha política de devasa estreita e a ruta de retorno prevista. Anota onde aparecen os seus rexistros e como se aplican as actualizacións, porque esas dúas respostas deciden como se diagnosticará un fallo máis adiante.

Un deseño de saída a internet e un deseño de acceso a unha rede privada teñen requisitos de reenvío diferentes, así que decide cal estás construíndo antes de abrir nada. Levanta un cliente aprobado e comproba o recurso previsto en lugar do indicador do túnel. Despois reinicia o servizo dun xeito controlado e confirma a ruta de arranque sen supervisión, porque unha porta de enlace que só sobe mentres alguén mira aínda non está despregada.