☰

OpenVPN на AWS (работает в режиме NAT, но не работает в режиме маршрутизации)

tag-icon • tag-icon vpn openvpn nat amazon-vpc aws-ec2
OpenVPN на AWS (работает в режиме NAT, но не работает в режиме маршрутизации)

У меня есть совершенно новый VPC (10.0.0.0/16) с 3 публичными подсетями (указывающими на IGW) и 3 частными подсетями (с NAT GW в каждой). Я развернул OpenVPN-устройство в публичной подсети и настроил его на использование режима NAT ( Yes, using NATв конфигурации маршрутизации). У меня также есть тестовый экземпляр в одной из частных подсетей. И экземпляр OpenVPN, и тестовый экземпляр имеют группы SG с «щедрой» гибкостью (т. е. все разрешено входящим и исходящим... для целей тестирования). На OpenVPN я настроил 10.0.0.0/16в Specify the private subnets to which all clients should be given access (one per line):полевых условиях.

С моего Mac (в домашней сети 192.168.178.0/24) я могу установить туннель и легко попасть на тестовый экземпляр. Все хорошо.

Теперь я хочу переключиться в режим маршрутизации.

  • Я изменил режим маршрутизации на Yes, using Routing. Я отключил проверку источника/назначения на экземпляре OpenVPN.
  • Я добавил статический маршрут во все 4 таблицы маршрутизации в VPC (3 для частных подсетей и 1 для публичной подсети), чтобы указать, что трафик, направленный в 192.168.178.0/24(мою домашнюю сеть), должен поступать в экземпляр OpenVPN (вероятно, для публичной подсети это не требовалось).
  • Я добавил 192.168.178.0/24в Specify the private subnets to which all clients should be given access (one per line):поле (не уверен, было ли это обязательным) в дополнение к 10.0.0.0/16.
  • Я перенастроил разрешения пользователя, под которым я вхожу в систему, Use Routingи снова указал обе подсети, указанные выше (10 и 192).

Я все еще могу установить туннель. Я могу получить доступ к внутреннему IP-адресу экземпляра OpenVPN:

$ traceroute 10.0.4.223          
traceroute to 10.0.4.223 (10.0.4.223), 64 hops max, 52 byte packets
 1  10.0.4.223 (10.0.4.223)  178.345 ms  174.470 ms  173.680 ms
$

Но я НЕ могу добраться до тестового экземпляра в частной подсети:

$ traceroute 10.0.165.139
traceroute to 10.0.165.139 (10.0.165.139), 64 hops max, 52 byte packets
 1  172.27.232.1 (172.27.232.1)  194.976 ms  177.014 ms  174.402 ms
 2  * * *
 3  * * *
 4  * * *
^C
$

Интересно, что если я подключаюсь по ssh к своему серверу OpenVPN и пытаюсь запустить curl NGINX на локальной рабочей станции, где я запустил туннель, я не могу до него добраться. Похоже, что рабочая станция может добраться до сервера OpenVPN (см. трассировку выше 10.0.4.223), но сервер OpenVPN не может добраться до рабочей станции (по некоторым причинам).

Похоже, что поток, инициированный с рабочей станции, способен найти маршрут к (и обратно) к экземпляру OpenVPN. Однако маршрут прерывается где-то от рабочей станции к тестовому экземпляру (и обратно) И, похоже, он также прерывается при инициировании от экземпляра OpenVPN к рабочей станции (см. curl).

решение1

В конце концов я понял, что устройство OpenVPN Access Server не может быть настроено для обратного подключения к собственному IP клиента в локальной подсети. Однако клиент может быть доступен через туннельный IP, назначенный VPN. Этот IP может быть настроен статически для каждого пользователя или может быть получен из пула, определенного на устройстве.

В моем случае я настроил оба варианта (см. рисунок).

введите описание изображения здесь

Важно знать, что это (это) также подсети, которые необходимо использовать в информации о маршрутизации. То есть IP, который находится в сети 10.0.0.0/16, может достичь клиентского устройства по одному из назначенных адресов 172.27, и поэтому в таблице маршрутизации необходимо указать сети 172.27 (а НЕ локальную собственную сеть клиентского устройства - 192.168.178.0/24 в моем примере).

Связанный контент