OpenVPN не разрешает запросы HTTP / s - невозможно подключиться к конечной точке частного API-шлюза AWS при подключении к авторизованной VPN - PullRequest
Новая
       26

OpenVPN не разрешает запросы HTTP / s - невозможно подключиться к конечной точке частного API-шлюза AWS при подключении к авторизованной VPN

0 голосов
/ 21 октября 2019

OpenVPN неправильно разрешает HTTP / s.

Я создал частный шлюз API, к которому я хочу получить доступ через частный DNS, настроенный в конечной точке execute-api, созданной в том же VPC, что и шлюз API,

Я могу связаться с ним из других ресурсов, созданных в том же VPC. Но я хочу, чтобы мои клиенты тоже достигли этого, только будучи подключенными к моей VPN OpenVPN server, но они не в состоянии.

Однако OpenVPN server может достичь API, но клиенты не могут,

То, что я считаю здесь неудачным, заключается в том, что OpenVPN Server неправильно перенаправляет запросы HTTP / s, как это происходит для соединений SSH.

Для соединений SSH VPN работает отлично.

Вероятно, это связано с отсутствием конфигурации. в OpenVPN сервере или клиенте.

Любая идея, пожалуйста?

Ценю любую помощь.

С уважением,

Rshad

1 Ответ

0 голосов
/ 23 октября 2019

Это решено.

Проблема заключалась в том, что серверу OpenVPN не удалось отправить конфигурацию DNS, и хотя имя хоста конечной точки API не было разрешено.

Ниже мы опишемосновные шаги и проблемы, которым мы следовали, чтобы решить эту проблему.

1. Проблема DNS VPC

Независимо от проблемы переадресации DNS OpenVPN клиенту, мы хотели использовать DNS VPC вручную, я имею в виду настройку его самостоятельно в файле конфигурации /etc/resolv.conf следующим образом:

nameserver <VPC DNS>
<default interface>

Мы попытались установить DNS, связанный с нашим VPC, который представлен полем IPv4 CIDR, и давайте рассмотрим его как 10.0.0.0. Попытка использования этого DNS не может работать, поскольку мы назначаем недопустимый DNS. После небольшого исследования мы обнаружили, что DNS-сервер, предоставляемый в среде VPC, является основой диапазона сети VPC плюс 2, поэтому в этом случае он будет => 10.0.0.2, или мы можем использовать общий 169.254.169.253.

Просто напоминание

> (от 0 до 255 включительно), один из которых является сетевым адресом (.0), а другой - сетьюшироковещательный адрес (.255).

Таким образом, если мы проверяем, распознает ли наш клиент DNS, мы запускаем: 

vagrant@manager:~$ nslookup 172.*.*.2
2.0.31.172.in-addr.arpa name = ip-172-*-*-2.us-east-2.compute.internal.

Authoritative answers can be found from:

vagrant@manager:~$

Мы также запускаем dig для имени хоста конечной точки API дляпроверьте возвращенные IP-адреса. В этом случае он должен вернуть 3 IP-адреса, по 1 для каждой подсети, которую мы связали с конечной точкой. 

vagrant@manager:~$ dig pwcc7wokgi.execute-api.us-east-2.amazonaws.com

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> pwcc7wokgi.execute-api.us-east-2.amazonaws.com        
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17511
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:
;pwcc7wokgi.execute-api.us-east-2.amazonaws.com.        IN A

;; ANSWER SECTION:pwcc7wokgi.execute-api.us-east-2.amazonaws.com. 4 IN CNAME 
execute-api.us-east-2.amazonaws.com. 4 IN A     172.*.*.*
execute-api.us-east-2.amazonaws.com. 4 IN A     172.*.*.*
execute-api.us-east-2.amazonaws.com. 4 IN A     172.*.*.*

;; Query time: 116 msec;; SERVER: 169.254.169.253#53(169.254.169.253);; WHEN: Tue Oct 22 17:04:35 UTC 2019
;; MSG SIZE  rcvd: 137

vagrant@manager:~$

2. Пересылка DNS клиенту OpenVPN

. Для этого нам необходимо добавить в файл конфигурации сервера следующие строки: 

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 169.254.169.253"
push "dhcp-option DNS 172.*.*.2"

Первая строка необходима не только в случаеПереадресация DNS, но для перенаправления всего трафика, поступающего от агента, на сервер.

Строки с dhcp-option DNS соответствуют DNS, которые мы хотим добавить к клиенту, 1 из них будет достаточно.

2.1 Проблемы

Мы столкнулись с некоторыми проблемами, когда клиент не мог обновляться сервером или самим клиентом. конфиг DNS. Файл /etc/resolv.conf всегда перезаписывается значением по умолчанию: 

nameserver 127.0.0.53

, что не в нашем случае. после некоторой отладки мы обнаружили, что:

  1. У нас не было установленной библиотеки resolveconf, поскольку это важно для OpenVPN при пересылке DNS. OpenVPN использует два файла конфигурациикоторый использует скрипт /sbin/resolveconf для переопределения файла /etc/resolv.conf при подключении или отключении от VPN при необходимости.

В конфигурации клиента. файл 

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

dnsmasq также может переопределить /etc/resolv.conf по умолчанию - Not a fixed case В нашем случае мне нужно было отключить dnsmasq при подключении к VPN, чтобы OpenVPN не мог переслатьDNS как /etc/resolv.conf всегда перезаписывают его.

Рекомендуется перезапустить network-manager, если были внесены изменения в dnsmasq.

Действительное сообщение журнала 

Tue Oct 22 17:17:16 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 169.254.169.253,dhcp-option DNS 10.0.0.2,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'

dhcp-option DNS 169.254.169.253
dhcp-option DNS 10.0.0.2

С уважением,

Rshad

...