1

Предназначение: сервер OpenVPN позволяет клиентам маскироваться под его общедоступный IPv4 в WWAN, а также подключаться к другим локальным серверам в частной сети, например к внутреннему DNS-серверу.

Сервер OpenVPN направляет весь трафик в частную сеть и WAN

Частная сеть, содержащая VPN-сервер + DNS-сервер, имеет адреса в 10.0.0.0/16. DNS-сервер 10.0.0.2.

Из этой диаграммы ^ клиент OpenVPN подключается и может видеть WAN. Однако есть проблемы:

  1. Я не могу выполнить nslookup даже если я вручную указал частный IP-адрес DNS-сервера. Я также попытался использовать публичные и частные IP-адреса VPN-сервера для nslookup но безрезультатно.

  2. Я не могу пропинговать /http /ssh ни одному серверу в частной подсети, кроме того, через который я знаю, что через VPN проходит. Я могу SSH к частному IP-адресу сервера OpenVPN.

Примечание. Что касается SSH, я на самом деле не против ^ где я должен сначала переадресовать SSH через VPN-сервер, чтобы добраться до других частных ящиков на порту 22. Но даже если я выберу это, я считаю, что это моя ответственность, чтобы понять, как именно это разрешено / запрещено!

  1. Несмотря на то, что я указал DNS-сервер в конфигурации моего сервера OpenVPN, и параметры отображаются в последовательности запуска OpenVPN, поэтому я знаю, что сервер каким-то образом указывает их клиенту - служба DNS по умолчанию на локальном компьютере просто гаснет, когда VPN подключен. У меня есть много теорий, но кажется разумным обратиться к пункту № 1, прежде чем продолжить это (??)

  2. Во время последовательности запуска OpenVPN я вижу ошибки, такие как Unrecognized option or missing parameter но считаю, что они должны быть результатом элементов, указанных сервером OpenVPNas! Есть ли проблема совместимости (возможно) между моим клиентом OpenVPN и сервером OpenVPN?

Примечание: оригинальный Вопрос содержал ложную информацию и был отредактирован, чтобы быть более полезным. Спасибо за освещение и руководство от MariusMatutiae в его ответе ниже, который устраняет недостатки в исходном вопросе.

В этом процессе я изучал интернет-протокол Protocal - формальное понимание предмета неразрывно связано с любой разумной попыткой настроить VPN.

Мои текущие конфигурации:

Интерфейс администратора сервера доступа 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

Директивы конфигурации сервера:

keepalive 10 60

Директивы по настройке клиента:

redirect-gateway
persist-tun
pull

Отчет о запуске 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
|источник

2 ответа2

0

Эти два заявления

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

не имеет никакого смысла. Во-первых, они противоречат друг другу. Во- вторых, этот вид push варианта не существует: в интернет - руководства

Это частичный список опций, которые в настоящее время могут быть отправлены: --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

Там нет упоминания о push gateway .

В-третьих, они лишние. Вам нужно знать общедоступный IP-адрес вашего сервера (первое утверждение), иначе ваш клиент никогда не сможет связаться с ним, поэтому нет необходимости передавать его клиенту. Что касается частного IP (второй оператор), то маршрутизируемая установка, которую (предположительно) вы рассматриваете, имеет одноранговое соединение, которое сделает частный IP-адрес контрагента известным клиенту, поскольку туннель установлен, поэтому нет необходимости нажмите опцию.

Если вместо этого приведенные выше адреса не относятся к общедоступному IP-адресу сервера и к частному адресу другого конца туннеля, то тем более у клиента нет причин знать эти адреса, следовательно, нет параметров push gateway .

Так как вы не обеспечивают полные конфигурационные файлы для сервера и клиента, то невозможно сказать , есть ли какие - либо больше ошибок, но конечно один указано выше ошибка.

|источник
0

Я считаю, что это случай переконфигурации. Проблема заключается в использовании доступа к частным подсетям через маршрутизацию. На самом деле, в этом случае простое использование NAT предоставит вашим клиентам полный доступ к подсети 10.0.0.2 .

Кроме этого, это уже солидно. Мы предотвращаем "утечку" DNS - или что-то в этом роде - благодаря "Маршрутизировать весь трафик через VPN" в конфигурации сервера OpenVPN. Этот параметр также требует , чтобы указать , что делать с DNS, потому что DNS абсолютно приходит вместе с "всем трафиком".

Исправьте это, и остальная часть процесса DHCP должна позаботиться о маршрутизации клиентских DNS-запросов через ваш частный DNS-сервер.

Кроме того, после того, как это будет решено, вы сможете использовать DNS-сервер 10.0.0.2 напрямую с клиента, а также SSH во всех полях подсети 10.0.16.0/24. По иронии судьбы, вы больше не сможете использовать SSH на самом сервере OpenVPN.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .