Conexão OpenVPN recusada (código = 111)

3

Estou tentando configurar um servidor OpenVPN no meu PC. Eu segui os passos descritos aqui .

Meu arquivo de configuração do servidor é assim:

local 192.168.1.150
port 1194
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key

Meu arquivo de configuração do cliente é assim:

remote A.B.C.D # this is my public IP address, is that correct?
port 1194
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key

Quando inicio meu servidor e cliente, o cliente informa o seguinte:

Fri Jan 31 20:04:27 2014 OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 27 2013
Fri Jan 31 20:04:27 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jan 31 20:04:27 2014 WARNING: file 'static.key' is group or others accessible
Fri Jan 31 20:04:27 2014 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 31 20:04:27 2014 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 31 20:04:27 2014 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 31 20:04:27 2014 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 31 20:04:27 2014 Socket Buffers: R=[229376->131072] S=[229376->131072]
Fri Jan 31 20:04:27 2014 TUN/TAP device tun0 opened
Fri Jan 31 20:04:27 2014 TUN/TAP TX queue length set to 100
Fri Jan 31 20:04:27 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jan 31 20:04:27 2014 /sbin/ifconfig tun0 10.8.0.2 pointopoint 10.8.0.1 mtu 1500
Fri Jan 31 20:04:27 2014 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Fri Jan 31 20:04:27 2014 Local Options hash (VER=V4): 'd3880969'
Fri Jan 31 20:04:27 2014 Expected Remote Options hash (VER=V4): 'c41bf3b8'
Fri Jan 31 20:04:27 2014 UDPv4 link local (bound): [undef]
Fri Jan 31 20:04:27 2014 UDPv4 link remote: [AF_INET]A.B.C.D:1194
Fri Jan 31 20:04:37 2014 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Eu adicionei uma regra ao meu ufw para permitir todo o tráfego de entrada para a porta 1194 .

Também adicionei uma regra ao firewall do meu roteador para permitir que todo o tráfego de entrada atinja a porta 1194 .

Eu uso um endereço IP estático 192.168.1.150 .

Eu tentei desligar os dois firewalls para ver se isso daria certo, mas sem resultados.

Existe alguma razão pela qual meu cliente não pode se conectar ao meu servidor? Observe que eu me conecto ao meu endereço IP público, isso está correto? Ou deveria ser outra coisa?

EDITAR:

Log do servidor ( verb 3 ):

Fri Jan 31 23:01:54 2014 OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 27 2013
Fri Jan 31 23:01:54 2014 WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
Fri Jan 31 23:01:54 2014 WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Fri Jan 31 23:01:54 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jan 31 23:01:54 2014 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 31 23:01:54 2014 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 31 23:01:54 2014 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 31 23:01:54 2014 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 31 23:01:54 2014 Socket Buffers: R=[229376->131072] S=[229376->131072]
Fri Jan 31 23:01:54 2014 TUN/TAP device tun0 opened
Fri Jan 31 23:01:54 2014 TUN/TAP TX queue length set to 100
Fri Jan 31 23:01:54 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jan 31 23:01:54 2014 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Fri Jan 31 23:01:54 2014 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Fri Jan 31 23:01:54 2014 Local Options hash (VER=V4): 'c41bf3b8'
Fri Jan 31 23:01:54 2014 Expected Remote Options hash (VER=V4): 'd3880969'
Fri Jan 31 23:01:54 2014 GID set to neftas
Fri Jan 31 23:01:54 2014 UID set to neftas
Fri Jan 31 23:01:54 2014 UDPv4 link local (bound): [AF_INET]192.168.1.150:1194
Fri Jan 31 23:01:54 2014 UDPv4 link remote: [undef]
    
por Stefan van den Akker 31.01.2014 / 20:13

2 respostas

2

ECONNREFUSED significa que a porta à qual você está tentando se conectar não está aberta no IP ao qual você está tentando se conectar. Isso significa que você está se conectando ao IP incorreto, não abriu a porta em seus firewalls com êxito, o servidor não foi iniciado com êxito ou o servidor está usando uma porta diferente. Tente isto:

1) Use "nmap" no servidor com o nome de host "localhost" para verificar se o servidor está funcionando corretamente na porta que você deseja.

2) Use-o no cliente com o IP público do seu servidor para verificar se a porta de destino está aberta.

Também ajudaria se você postar o log do servidor.

    
por Tristan Schmelcher 31.01.2014 / 22:54
0

Eu estava tendo o mesmo problema ao configurar um servidor OpenVPN de um VPS que eu tinha no exterior. Através do nmap, eu concluí que o meu porto de escolha (no meu caso, 443) sobre o UDP estava fechado e não estava recebendo tráfego.

Eu usei o ufw para ter certeza de que a porta 443 / udp estava aberta e recebendo o tráfego que eu estava solicitando do meu cliente.

  

sudo apt-get instalar -y ufw
ufw allow ssh
ufw allow 443 / udp (Insira sua própria porta / protocolo aqui)

Eu editei os arquivos de configuração do ufw:

  

sudo nano / etc / default / ufw

e substituído:

  

DEFAULT_FORWARD_POLICY="DROP"

para

  

DEFAULT_FORWARD_POLICY="ACEITAR"

Em seguida, uma simples ativação e reinicialização do OpenVPN funcionou.

  

sudo ufw enable

E verifiquei digitando:

  

status do sudo ufw

E verifiquei se todas as configurações do firewall estavam corretas e fiz uma verificação cruzada com o nmap:

  

sudo nmap -sU 443 localhost

E isso pareceu fazer isso por mim. Pode não funcionar para os outros, mas resolveu o meu problema e levou apenas cerca de 5 minutos.

    
por thatleokid 02.03.2016 / 01:02

Tags