Estou acompanhando este tutorial para configurar uma VPN entre o meu servidor de origem e o meu servidor de produção.
Meu problema é que na minha rede, o cliente (servidor inicial) está por trás de um IP dinâmico e o servidor (produção) está atrás de um IP estático.
O que devo fazer de diferente para criar esta VPN entre minha rede doméstica e de produção, considerando que minha casa está por trás de um IP que meu ISP muda com frequência?
O OpenVPN requer que um sistema esteja configurado como o servidor e o outro esteja configurado como o cliente. Clientes se conectam ao servidor.
Assim, você teria a instância do servidor em execução em seu servidor de produção com o IP estático e a instância do cliente em execução em seu servidor inicial com o IP dinâmico. O IP do seu cliente não importa, pois iniciará a conexão com o servidor.
Uma conexão OpenVPN quando pelo menos um entre o cliente e o servidor não possui um endereço IP estático apresenta o seguinte problema: se um deles alterar o endereço durante o curso da conexão, este será descartado.
Existe, no entanto, uma forma padrão ( veja esta página wiki oficial do OpenVPN ) para solicitar automaticamente o cliente e / ou servidor para forçar uma reconexão sempre que a conexão for interrompida. Consiste em usar as seguintes linhas nos arquivos de configuração do servidor e do cliente:
ping 15
ping-restart 300 # 5 minutes
resolv-retry 300 # 5 minutes
persist-tun
persist-key
Entretanto, observe que essas linhas preservam o link OpenVPN, seja qual for a causa da queda temporária (não importa a alteração do endereço IP público), então eu normalmente as mantenho nos arquivos de configuração do cliente e do servidor para permitir uma reconexão automática.
De acordo com o Manual :
--ping n
Ping remote over the TCP/UDP control channel if no packets have been sent for at least n seconds (specify --ping on both peers to cause ping packets to be sent in both directions since OpenVPN ping packets are not echoed like IP ping packets). When used in one of OpenVPN's secure modes (where --secret, --tls-server, or --tls-client is specified), the ping packet will be cryptographically secure.
--ping-restart n
Similar to --ping-exit, but trigger a SIGUSR1 restart after n seconds pass without reception of a ping or other packet from remote. This option is useful in cases where the remote peer has a dynamic IP address and a low-TTL DNS name is used to track the IP address using a service such as http://dyndns.org/ + a dynamic DNS client such as ddclient.
If the peer cannot be reached, a restart will be triggered, causing the hostname used with --remote to be re-resolved (if --resolv-retry is also specified).
In server mode, --ping-restart, --inactive, or any other type of internally generated signal will always be applied to individual client instance objects, never to whole server itself. Note also in server mode that any internally generated signal which would normally cause a restart, will cause the deletion of the client instance object instead.
In client mode, the --ping-restart parameter is set to 120 seconds by default. This default will hold until the client pulls a replacement value from the server, based on the --keepalive setting in the server configuration. To disable the 120 second default, set --ping-restart 0 on the client.
See the signals section below for more information on SIGUSR1.
Note that the behavior of SIGUSR1 can be modified by the --persist-tun, --persist-key, --persist-local-ip, and --persist-remote-ip options.
Also note that --ping-exit and --ping-restart are mutually exclusive and cannot be used together.
--resolv-retry n If hostname resolve fails for --remote, retry resolve for n seconds before failing. Set n to "infinite" to retry indefinitely.
By default, --resolv-retry infinite is enabled. You can disable by setting n=0.
--persist-tun
Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. SIGUSR1 is a restart signal similar to SIGHUP, but which offers finer-grained control over reset options.
--persist-key
Don't re-read key files across SIGUSR1 or --ping-restart. This option can be combined with --user nobody to allow restarts triggered by the SIGUSR1 signal. Normally if you drop root privileges in OpenVPN, the daemon cannot be restarted since it will now be unable to re-read protected key files.
This option solves the problem by persisting keys across SIGUSR1 resets, so they don't need to be re-read.