Não é possível acessar a LAN por trás do OpenVPN a partir do Ubuntu 13.10

3

Estou com problemas para acessar as máquinas em uma VPN. O servidor tem uma configuração TAP e posso conectar-me com sucesso a partir de um cliente Windows 7. Tenho acompanhado este guia principalmente para configurar tudo: link

A parte estranha é que posso me conectar à VPN, o servidor mostra a conexão, mas não consigo acessar os outros computadores da rede quando estou fazendo isso do Ubuntu. Preciso consertar manualmente algum tipo de bridging no cliente ou o Ubuntu deve encontrar automaticamente as rotas? Li em algum lugar que ele pode estar bloqueado pelo firewall, mas tenho certeza de que o firewall foi desativado no cliente e, no servidor, o firewall está obviamente configurado corretamente ou não seria possível conectar-me a partir de um Windows 7 cliente.

O guia me instruiu a usar o OpenVPN 2.1.4 no Windows e foi o que eu fiz, no Ubuntu usei a versão nos repositórios e isso pode ter causado algum problema, mas não vejo por que seria. Aqui abaixo está meu client.conf:

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tap
#dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
proto tcp
#proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote removed.for-sake-of.security 1194
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/client.crt"
key "/etc/openvpn/client.key"

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x
cipher AES-128-CBC

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

Há mais alguma coisa que eu preciso configurar para que meu cliente Ubuntu faça parte da rede / tenha acesso a outras máquinas?

ATUALIZAÇÃO: Esta é a saída do cliente, como você pode ver, parece estar preso em um loop, reiniciando a conexão repetidamente. Copiei a saída desde o início até a segunda vez em que diz Initialization Sequence Completed . Isso ajuda a fornecer uma resposta?

Thu Jan  9 18:52:37 2014 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Jul 12 2013
Thu Jan  9 18:52:37 2014 WARNING: file '/etc/openvpn/krs-niklas.key' is group or others accessible
Thu Jan  9 18:52:37 2014 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Jan  9 18:52:37 2014 Attempting to establish TCP connection with [AF_INET]85.225.217.161:1194 [nonblock]
Thu Jan  9 18:52:38 2014 TCP connection established with [AF_INET]85.225.217.161:1194
Thu Jan  9 18:52:38 2014 TCPv4_CLIENT link local: [undef]
Thu Jan  9 18:52:38 2014 TCPv4_CLIENT link remote: [AF_INET]85.225.217.161:1194
Thu Jan  9 18:52:38 2014 TLS: Initial packet from [AF_INET]85.225.217.161:1194, sid=444e38d7 ac8fcbca
Thu Jan  9 18:52:39 2014 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=OpenVPN, CN=KRS, [email protected]
Thu Jan  9 18:52:39 2014 VERIFY OK: nsCertType=SERVER
Thu Jan  9 18:52:39 2014 VERIFY OK: depth=0, C=US, ST=CA, O=OpenVPN, CN=KRS, [email protected]
Thu Jan  9 18:52:41 2014 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Jan  9 18:52:41 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan  9 18:52:41 2014 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Jan  9 18:52:41 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan  9 18:52:41 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Jan  9 18:52:41 2014 [KRS] Peer Connection Initiated with [AF_INET]85.225.217.161:1194
Thu Jan  9 18:52:43 2014 SENT CONTROL [KRS]: 'PUSH_REQUEST' (status=1)
Thu Jan  9 18:52:43 2014 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.1.1,route-gateway dhcp,ping 15,ping-restart 60'
Thu Jan  9 18:52:43 2014 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jan  9 18:52:43 2014 OPTIONS IMPORT: route-related options modified
Thu Jan  9 18:52:43 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jan  9 18:52:43 2014 TUN/TAP device tap1 opened
Thu Jan  9 18:52:43 2014 TUN/TAP TX queue length set to 100
Thu Jan  9 18:52:43 2014 Initialization Sequence Completed
Thu Jan  9 18:52:49 2014 Connection reset, restarting [0]
Thu Jan  9 18:52:49 2014 SIGUSR1[soft,connection-reset] received, process restarting
Thu Jan  9 18:52:49 2014 Restart pause, 5 second(s)
Thu Jan  9 18:52:54 2014 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Jan  9 18:52:54 2014 Attempting to establish TCP connection with [AF_INET]85.225.217.161:1194 [nonblock]
Thu Jan  9 18:52:55 2014 TCP connection established with [AF_INET]85.225.217.161:1194
Thu Jan  9 18:52:55 2014 TCPv4_CLIENT link local: [undef]
Thu Jan  9 18:52:55 2014 TCPv4_CLIENT link remote: [AF_INET]85.225.217.161:1194
Thu Jan  9 18:52:55 2014 TLS: Initial packet from [AF_INET]85.225.217.161:1194, sid=ff99a93f 04c54987
Thu Jan  9 18:52:56 2014 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=OpenVPN, CN=KRS, [email protected]
Thu Jan  9 18:52:56 2014 VERIFY OK: nsCertType=SERVER
Thu Jan  9 18:52:56 2014 VERIFY OK: depth=0, C=US, ST=CA, O=OpenVPN, CN=KRS, [email protected]
Thu Jan  9 18:52:58 2014 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Jan  9 18:52:58 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan  9 18:52:58 2014 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Jan  9 18:52:58 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan  9 18:52:58 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Jan  9 18:52:58 2014 [KRS] Peer Connection Initiated with [AF_INET]85.225.217.161:1194
Thu Jan  9 18:53:00 2014 SENT CONTROL [KRS]: 'PUSH_REQUEST' (status=1)
Thu Jan  9 18:53:00 2014 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.1.1,route-gateway dhcp,ping 15,ping-restart 60'
Thu Jan  9 18:53:00 2014 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jan  9 18:53:00 2014 OPTIONS IMPORT: route-related options modified
Thu Jan  9 18:53:00 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jan  9 18:53:00 2014 Preserving previous TUN/TAP instance: tap1
Thu Jan  9 18:53:00 2014 Initialization Sequence Completed
    
por Niklas 09.01.2014 / 10:45

4 respostas

3

Thu Jan  9 18:52:43 2014 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.1.1,route-gateway dhcp,ping 15,ping-restart 60'

No log, a máquina cliente não recebe um IP DHCP válido, que deve ser normalmente enviado pelo servidor com a instrução 'push'. Assim, o cliente não pôde se comunicar com o par (o servidor) e, em seguida, a reinicialização foi acionada.

Como você pode notar que há 'ping 15, ping-restart 60' pressionado também, é por isso que "SIGUSR1" está lá. Por favor, consulte 'man openvpn' para mais detalhes.

   --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).
    
por t4lwh 14.01.2014 / 10:00
2

Você pode acessar o único nó na LAN quando você se conecta, mas não os outros. Aqui está o que está acontecendo. Seu roteador não sabe como rotear o tráfego para o OpenVPN, porque é uma 'rede estrangeira'. Exemplo:

O cliente A se conecta ao servidor OpenVPN B.

O endereço OpenVPN atribuído a A é 172.19.0.2. O endereço OpenVPN do servidor é 172.19.0.1, mas seu endereço de LAN é 192.168.0.101.

A está tentando se conectar a outra caixa na LAN, 192.168.0.33 (C). Para que isso aconteça, o tráfego tem que se originar de A, transmitir para B, transmitir para o gateway para B (o roteador) e, finalmente, transmitir para C.

Agora, seguindo em frente. NENHUM DE ISSO FUNCIONARÁ SE VOCÊ NÃO TER ADMIN ACESSO A SUA LAN ROUTER:

Então, primeiro você precisa ativar o roteamento no servidor OpenVPN para que ele possa rotear os pacotes para o gateway. Isto irá variar com o seu sistema operacional, mas você deve ser capaz de google "habilitar o roteamento em _ " (seu nome do sistema operacional). Faça isso.

Então você precisa adicionar uma rota estática em seu roteador para saber que o tráfego openvpn deve ser retornado da LAN através do seu servidor openvpn. Encontre a seção de rotas estáticas na configuração do roteador e adicione uma rota. A rota deve corresponder à especificação de endereço no seu arquivo de configuração do servidor. Então, se o seu arquivo de configuração do servidor usar a rede virtual 10.20.0.0 com a máscara de rede 255.255.0.0, você adicionaria

network - 10.20.0.0
netmask - 255.255.0.0
gateway - 192.168.0.101 #replace this with your openvpn server's address on the lan)

Isso deve ser feito.

    
por Xavier J 16.01.2014 / 18:55
2

Ubuntu Server 14.04.1 Como configurar o servidor OpenVPN em uma máquina separada do gateway da LAN (com acesso a outras máquinas na LAN do servidor)

Certifique-se de que sua LAN openvpn não é a usual 192.168.1.1 ou 10.0.0.1. Se estiver, faça o login no seu roteador e altere o terceiro número, ou seja. 192.168. (Este número) .1

Certifique-se de encaminhar a porta 1194 em seu roteador para o IP do servidor OpenVPN

Rede de exemplo:

Gateway IP:            192.168.5.1
OpenVPN Server IP:     192.168.5.20

OpenVPN Config:

 port 1194
 proto udp
 dev tun0
 ca ca.crt
 cert server.crt
 key server.key
 dh dh2048.pem
 server 10.8.0.0 255.255.255.0
 ifconfig-pool-persist ipp.txt
 push "route 192.168.5.0 255.255.255.0"
 push "route 10.8.0.0 255.255.255.0"
 push "redirect-gateway def1 bypass-dhcp"
 push "dhcp-option DNS 8.8.8.8"
 push "dhcp-option DNS 8.8.4.4"
 client-to-client
 duplicate-cn
 keepalive 10 120
 tls-auth ta.key 0
 comp-lzo
 user nobody
 group nogroup
 persist-key
 persist-tun 
 status openvpn-status.log
 verb 3

Edite / etc / network / interfaces:

 auto lo
 iface lo inet loopback

 auto eth0
 iface eth0 inet static
      address 192.168.5.20
      netmask 255.255.255.0
      broadcast 192.168.5.255
      network 192.168.5.0
      gateway 192.168.5.1
      dns-nameservers 8.8.8.8
      dns-nameservers 8.8.4.4

 post-up iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to 192.168.5.20

Não deixe de comentar a configuração do ipv6

Edite /etc/sysctl.conf:

Alterar:

 #net.ipv4.ip_forward=1

para:

 net.ipv4.ip_forward=1

Supondo que suas chaves e configurações do cliente estejam todas esquecidas; Reinicie seu servidor e você deve estar pronto!

    
por Kallet 20.10.2014 / 08:42
0

Na situação geral, quando você se conecta a uma VPN, pode acessar a LAN remota, mas seu acesso à LAN local será bloqueado.

    
por Thilina 14.01.2014 / 17:05

Tags