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

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

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

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

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

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

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

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

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

Рад любой помощи.

С уважением,

Ршад


amazon-web-services endpoint openvpn aws-api-gateway
person Rshad    schedule 21.10.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это разрешилось.

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

Далее мы описываем основные шаги и проблемы, которые мы предприняли для решения этой проблемы.

<сильный>1. Проблема с DNS VPC

Независимо от вопроса проброса OpenVPN DNS клиенту, мы хотели использовать VPC DNS вручную, я имею в виду установку его самостоятельно в конфигурационном файле /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 Проблемы

Мы столкнулись с некоторыми проблемами, когда клиент не мог обновиться сервером или самим клиентом. конфиг ДНС. файл /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

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

  2. Рекомендуется перезапустить 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

С уважением,

Ршад

person Rshad    schedule 23.10.2019