O servidor OpenVPN encaminha DNS e tráfego para privados + WWAN

Question

Destinado: O servidor OpenVPN permite que os clientes se disfarçam como seu IPv4 público na WWAN, bem como se conectem a outros servidores locais dentro da rede privada, por exemplo, o servidor DNS interno.

AredeprivadaquecontémoservidorVPN+oservidorDNStemendereçosem10.0.0.0/16.OservidorDNSé10.0.0.2.

Apartirdesse^diagrama,oOpenVPNClientestáconectandoOKeconsegueveraWAN.Noentanto,existemproblemas:

1. NãoconsigoexecutarnslookupmesmoquandoespecificomanualmenteoIPprivadodoservidorDNS.Eutambémtenteiusaro&publicpúblicodoservidorVPNIPsprivadosparaonslookupsemsucesso.

2. Eunãoconsigopingar/http/sshparanenhumservidornasub-redeprivadaexcetoaquelepeloqualeuseiqueestoufazendoVPN.EusoucapazdeSSHparaoendereçoIPprivadodoservidorOpenVPN.

Nota:ParaSSH,eurealmentenãomeimporto^ondedevoprimeiroenviaroagentedeSSHatravésdoservidorVPNparachegaràsoutrascaixasprivadasnaporta22.Masmesmoseeuoptarporisso,euacreditoqueéminharesponsabilidadeentenderexatamentecomoépermitido/negado!

Mesmo que eu tenha especificado o servidor DNS na configuração do meu servidor OpenVPN, e os parâmetros são ecoados na seqüência de inicialização do OpenVPN, então eu sei que o servidor está especificando-os para o cliente de alguma forma- Default DNS o serviço na máquina local fica escuro quando a VPN está conectada . Eu tenho muitas teorias, mas parece prudente para abordar o item # 1 antes de prosseguir esta mais (??)

Durante a seqüência de inicialização do OpenVPN, vejo erros como Unrecognized option or missing parameter , mas acredito que estes devem ser o resultado de itens especificados pelo servidor OpenVPNas! Existe um problema de compatibilidade (talvez) entre o meu cliente OpenVPN e o servidor OpenVPN?

Nota: A pergunta original continha informações falsas e foi editada para ser mais útil. Obrigado pela iluminação & orientação de MariusMatutiae em sua resposta abaixo que aborda falhas na questão original.

Neste processo, tenho estudado Internet Protocal - uma compreensão formal do assunto é indissociável de qualquer tentativa sensata. para configurar uma VPN.

Minhas configurações atuais:

IU de administração do servidor de acesso OpenVPN:

Access Server version:  2.0.17  
Authenticate users with:    pam 
Accepting VPN client connections on IP address: all interfaces  
Port for VPN client connections:    tcp/443, udp/1194   
OSI Layer:  3 (routing/NAT) 
Clients access private subnets using: NAT
Dynamic IP Address Network: 10.0.16.0/24
Group Default IP Address Network: 10.0.16.0/24
Routing: Yes, VPN clients have access to private subnets
Private subnets: 10.0.0.0/16
Yes, Allow access from these private subnets to all VPN client IP addresses and subnets
Yes, client Internet traffic be routed through the VPN
Yes, clients be allowed to access network services on the VPN gateway IP address
Yes, have clients use same DNS servers as server

Diretivas de configuração do servidor:

keepalive 10 60

Diretivas de configuração do cliente:

redirect-gateway
persist-tun
pull

Relatório de inicialização do OpenVPN:

Thu Jul 30 12:37:43 2015 OpenVPN 2.3.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun  8 2015
Thu Jul 30 12:37:43 2015 library versions: OpenSSL 1.0.1f 6 Jan 2014, LZO 2.06
Thu Jul 30 12:37:43 2015 Control Channel Authentication: tls-auth using INLINE static key file
Thu Jul 30 12:37:43 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:43 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:43 2015 Socket Buffers: R=[212992->200000] S=[212992->200000]
Thu Jul 30 12:37:43 2015 UDPv4 link local: [undef]
Thu Jul 30 12:37:43 2015 UDPv4 link remote: [AF_INET]52.58.43.124:1194
Thu Jul 30 12:37:43 2015 TLS: Initial packet from [AF_INET]52.58.43.124:1194, sid=6e5a857f 05e9ff87
Thu Jul 30 12:37:44 2015 VERIFY OK: depth=1, CN=OpenVPN CA
Thu Jul 30 12:37:44 2015 VERIFY OK: nsCertType=SERVER
Thu Jul 30 12:37:44 2015 VERIFY OK: depth=0, CN=OpenVPN Server
Thu Jul 30 12:37:44 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Jul 30 12:37:44 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:44 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Jul 30 12:37:44 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:44 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
Thu Jul 30 12:37:44 2015 [OpenVPN Server] Peer Connection Initiated with [AF_INET]52.58.43.124:1194
Thu Jul 30 12:37:47 2015 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
Thu Jul 30 12:37:47 2015 PUSH: Received control message: 'PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 10,ping-restart 60,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway 10.0.16.129,dhcp-option DNS 10.0.0.2,dhcp-option DNS 8.8.8.8,dhcp-option DOMAIN prd1.o2,register-dns,block-ipv6,ifconfig 10.0.16.131 255.255.255.128'
Thu Jul 30 12:37:47 2015 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:1 is ignored by previous <connection> blocks 
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.7)
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: LZO parms modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: route options modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: route-related options modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jul 30 12:37:47 2015 ROUTE_GATEWAY ON_LINK IFACE=wwan0 HWADDR=4e:cd:17:f4:1e:42
Thu Jul 30 12:37:47 2015 TUN/TAP device tun0 opened
Thu Jul 30 12:37:47 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 12:37:47 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 12:37:47 2015 /sbin/ip link set dev tun0 up mtu 1500
Thu Jul 30 12:37:47 2015 /sbin/ip addr add dev tun0 10.0.16.131/25 broadcast 10.0.16.255
Thu Jul 30 12:37:53 2015 ROUTE remote_host is NOT LOCAL
Thu Jul 30 12:37:53 2015 /sbin/ip route add 52.58.43.124/32 dev wwan0
Thu Jul 30 12:37:53 2015 /sbin/ip route add 0.0.0.0/1 via 10.0.16.129
Thu Jul 30 12:37:53 2015 /sbin/ip route add 128.0.0.0/1 via 10.0.16.129
Thu Jul 30 12:37:53 2015 Initialization Sequence Completed

    

Answer 1

Eu acredito que este é um caso de configuração excessiva. O problema é usar o acesso a sub-redes privadas via roteamento . Na verdade, nesse caso, o simples uso do NAT permitirá que seus clientes tenham acesso total à sub-rede 10.0.0.2 .

Além disso, isso já é sólido. Estamos impedindo o DNS "vazado" - ou qualquer coisa - graças ao "Rotear todo o tráfego por VPN" na configuração do servidor OpenVPN. Esta opção também requer que você especifique o que fazer com o DNS, porque o DNS absolutamente faz vir junto com "todo o tráfego".

Corrija isso, e o restante do processo DHCP deve cuidar das solicitações de DNS do cliente de roteamento através do seu servidor DNS privado.

Além disso, depois que isso for resolvido, você poderá usar o servidor DNS 10.0.0.2 diretamente do cliente, bem como o SSH em todas as caixas da sub-rede 10.0.16.0/24. Ironicamente, você não poderá mais usar o SSH no próprio servidor OpenVPN.

    

Answer 2

Estas duas declarações

  push "remote-gateway 52.58.43.124"
  push "remote-gateway 10.0.31.207"

não faz sentido. Primeiro, eles se contradizem. Segundo, esse tipo de opção push não existe: do manual on-line

This is a partial list of options which can currently be pushed: --route, --route-gateway, --route-delay, --redirect-gateway, --ip-win32, --dhcp-option, --inactive, --ping, --ping-exit, --ping-restart, --setenv, --persist-key, --persist-tun, --echo, --comp-lzo, --socket-flags, --sndbuf, --rcvbuf

Não há menção de push gateway .

Terceiro, eles são supérfluos. Você precisa saber o IP público do seu servidor (primeira declaração) ou o seu cliente nunca será capaz de contatá-lo, portanto, não há necessidade de empurrá-lo para o cliente. Quanto ao IP privado (segunda declaração) a configuração roteada que (presumivelmente) você está contemplando tem uma conexão peer to peer que tornará o IP privado da contraparte conhecido pelo cliente enquanto o túnel é estabelecido, então não há necessidade de empurre a opção.

Se, em vez disso, os endereços acima não se referirem ao IP público do servidor e ao endereço particular da outra extremidade do túnel, então a fortiori não há motivo para o cliente saber esses endereços, portanto, não há push gateway opções.

Como você não fornece arquivos de configuração completos para o servidor e o cliente, é impossível dizer se há mais algum erro, mas com certeza o que foi apontado acima é um erro.