
Configuré OpenVPN detrás de un enrutador y reenvié el puerto 1194
. La VPN está usando la subred 10.3.15.0/24
y tiene 192.168.1.14
la LAN.
Funciona cuando me conecto localmente o desde mi red doméstica conectándome a la IP pública. Pero no en otras redes que he probado.
No puedo establecer una conexión a la VPN y en el cliente aparece:
Mon Apr 20 13:50:42 2015 UDPv4 link local: [undef]
Mon Apr 20 13:50:42 2015 UDPv4 link remote: [AF_INET]83.***.***.***:1194
Mon Apr 20 13:51:42 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Apr 20 13:51:42 2015 TLS Error: TLS handshake failed
Mon Apr 20 13:51:42 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Apr 20 13:51:42 2015 Restart pause, 2 second(s)
Pensé que podría ser un problema de firewall, esto es de mis iptables:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- 10.3.15.0/24 anywhere ctstate NEW
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Pero intenté lavar la mesa, lo cual no funcionó. Y cuando se ejecuta tcpdump -qni any port 1194
hay cierta comunicación (en ambos casos):
13:44:35.936684 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14
13:44:41.043704 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.063426 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.544690 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14
También noté algo sobre destination port unreachable
, pero esos errores desaparecieron.
Esta es la configuración de mi servidor:
port 1194
proto udp
dev tun
ca openvpn_certs/host-ca.pem
cert openvpn_certs/host-cert.pem
key openvpn_certs/host-key.pem
dh openvpn_certs/dh1024.pem
server 10.3.15.0 255.255.255.0
route 10.3.15.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
push "remote-gateway 10.3.15.1"
client-to-client
max-clients 20
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 11
Aquí está la configuración de mi cliente:
client
dev vpn
dev-type tun
proto udp
remote server.remote 1194
resolv-retry infinite
nobind
ns-cert-type server
persist-key
persist-tun
pull
ca certs/ca-host.pem
cert certs/cert-local.pem
key certs/key-local.pem
comp-lzo
verb 11
El servidor ejecuta Alpine Linux mientras que el cliente ejecuta Gentoo.
Estoy estancado y no tengo idea de dónde buscar, ¿alguna idea u orientación?
¡Gracias!
Respuesta1
En primer lugar, no estoy seguro de qué versión de OpenVPN estás usando, pero 'puerta de enlace remota' no es una opción válida en v2.3.2. Si está utilizando una versión anterior, consulte su página de manual local y elimine esa directiva si es necesario.
De acuerdo con lawiki de OpenVPN, el error "Falló la negociación de la clave TLS..." casi siempre es el resultado de:
Un firewall perimetral en la red del servidor está filtrando los paquetes OpenVPN entrantes (de forma predeterminada, OpenVPN usa el número de puerto UDP o TCP 1194).
- Esto parece poco probable en su caso, pero verifique el firewall de su enrutador para estar seguro.
Un firewall de software que se ejecuta en la máquina del servidor OpenVPN está filtrando las conexiones entrantes en el puerto 1194.
La tabla de filtros que proporcionó se ve bien, asumiendo que normalmente tiene la política INPUT predeterminada configurada para aceptar. De lo contrario, deberá permitir el puerto UDP 1194:
iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
Una puerta de enlace NAT en la red del servidor no tiene una regla de reenvío de puerto para TCP/UDP 1194 a la dirección interna de la máquina del servidor OpenVPN.
La configuración del cliente OpenVPN no tiene la dirección del servidor correcta en su archivo de configuración. La directiva remota en el archivo de configuración del cliente debe apuntar al servidor mismo o a la dirección IP pública de la puerta de enlace de la red del servidor.
El firewall de Windows está bloqueando el acceso al binario openvpn.exe. Es posible que deba incluirlo en la lista blanca (agregarlo a la lista de "Excepciones") para que OpenVPN funcione.
Si aún tiene problemas, es probable que haya un problema con su infraestructura de clave pública. No estoy familiarizado con Alpine Linux ni si su paquete OpenVPN viene con easy-rsa, así que adelante ydescargar la última versióny extráigalo a una ubicación adecuada tanto en su servidor como en una máquina (preferiblemente) que no esté conectada a la red (su autoridad de certificación). Para simplificar, asumiré que su servidor está generando solicitudes para clientes. En ambos sistemas, cambie al directorio donde extrajo EasyRSA y...
cp vars.example vars
editor ./vars
En el sistema CA, descomente y edite los campos organizativos en consecuencia (EASYRSA_REQ_COUNTRY, etc.). En el servidor, opcionalmente cambie "set_var EASYRSA_PKI" para que apunte a una ubicación adecuada (por ejemplo, /etc/openvpn/pki).
Generar solicitudes de certificado en el servidor:
./easyrsa init-pki
./easyrsa gen-req <your_server_name> nopass
./easyrsa gen-req <some_client_name> nopass
En el lugar que no es el servidor, cree una nueva CA:
./easyrsa init-pki
./easyrsa build-ca
Copie los archivos .req a su sistema CA, luego impórtelos y fírmelos:
./easyrsa import-req server /tmp/<your_server_name>.req
./easyrsa import-req client /tmp/<some_client_name>.req
./easyrsa sign-req server <your_server_name>
./easyrsa sign-req client <some_client_name>
Copie los certificados recién firmados, así como el certificado de CA, en una ubicación adecuada en el servidor y el cliente. Luego, en el servidor, genere los parámetros dh:
./easyrsa gen-dh
Finalmente, copie la clave del cliente en la máquina cliente (si aún no está allí) y actualice sus configuraciones con las nuevas ubicaciones de clave y certificado.
Respuesta2
Asegúrese de que el certificado de su servidor esté firmado con la designación nsCertType=server (esto está depreciado y no es el valor predeterminado si utilizó easyrsa3). De lo contrario, la directiva 'ns-cert-type server' en la configuración de su cliente provocaría que fallara el protocolo de enlace tls. Utilice 'servidor remoto-cert-tls' en su lugar.