Назад | Перейти на главную страницу

невозможно выполнить ping или ssh между подсетями aws vpc

У меня в VPC довольно стандартная многоуровневая схема подсети. Существует уровень / подсеть базы данных, уровень / подсеть веб-сервера и уровень / подсеть хоста-бастиона. Моя проблема в том, что я не могу пинговать или ssh между подсетями.

В частности, я хотел бы выполнить ping и ssh из уровня / подсети бастиона в уровень / подсеть веб-сервера.

172.31.32.0/20 bastion-tier
172.31.0.0/20 webserver-tier

Обе подсети находятся в одной зоне доступности, и обе подсети присоединены к одной и той же таблице маршрутизации. Таблица маршрутов выглядит так:

172.31.0.0/16 local
0.0.0.0/0 igw-xxxxxxxx

В настоящее время сетевые ACL для уровня веб-сервера разрешают ВСЕ трафик, ВСЕ протоколы, ВСЕ диапазоны портов от 172.31.32.0/20, который является уровнем бастиона. Правила исходящего / исходящего трафика разрешают весь трафик. Группы безопасности также широко открыты. Вот сетевые ACL для уровня веб-сервера.

RULE #  TYPE          PROTOCOL  PORT RANGE  SOURCE          ALLOW/DENY
100     ALL Traffic   ALL       ALL         172.31.32.0/20  ALLOW
200     HTTP (80)     TCP (6)   80          0.0.0.0/0       ALLOW
202     HTTP* (8080)  TCP (6)   8080        0.0.0.0/0       ALLOW
210     HTTPS (443)   TCP (6)   443         0.0.0.0/0       ALLOW
*       ALL Traffic   ALL       ALL         0.0.0.0/0       DENY

Я пробовал ping и ssh в подсетях, при этом обе подсети были подключены к таблице маршрутов по умолчанию / основной, И я попытался подключить подсеть веб-сервера к своей собственной таблице маршрутов. Когда я открываю любую из этих подсетей для трафика с IP-адреса моего ноутбука, я могу успешно подключиться по ssh через общедоступные IP-адреса экземпляров.

Я видел в Интернете информацию, которая подразумевает странное / ошибочное поведение в AWS VPC. Проблемы, например, при создании эластичных IP-адресов через консоль VPC, но при их назначении через консоль EC2, а затем исчезновение трафика, как если бы он был в черной дыре. Решение, казалось, состояло в том, чтобы удалить глючный EIP и воссоздать и полностью назначить новый через консоль VPC или EC2. Однако это в лучшем случае косвенный взгляд на возможные / общие ошибки AWS, поскольку в моем случае не задействованы никакие EIP.

Моя следующая мера по устранению неполадок - начать заново с нового VPC, создать две подсети, развернуть экземпляр сервера в каждой, а затем проверить ping и ssh между ними. Единая таблица маршрутов и широко открытые сетевые ACL и группы безопасности - не может быть проще.

Мне кажется, что это базовая настройка, и поэтому я подозреваю, что есть базовое решение, которое мне не хватает. Есть предположения? Пожалуйста и спасибо!

Вам нужен маршрут и открытые сетевые ACL-списки из подсети уровня веб-сервера обратно в подсеть уровня бастиона, иначе ваши ответные пакеты никогда не вернутся на сервер. Включите ICMP (и убедитесь, что ваш ping-клиент использует только ICMP - некоторые используют пакеты UDP по умолчанию) от подсети веб-сервера до бастиона и откройте соответствующие эфемерные TCP-порты (диапазон обычно зависит от ОС; см. http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports) с уровня веб-сервера на уровень бастиона.

Если вы запустите tcpdump на экземпляре веб-сервера и экземпляре бастиона одновременно, вы, вероятно, увидите, что веб-сервер получает пакеты бастиона и отправляет ответ, но экземпляр бастиона никогда не получает ответа.

Проверьте правила группы безопасности входящего трафика для экземпляра в обеих подсетях. Вам необходимо разрешить CIDR для специфики подсети или присоединить к ним группу безопасности по умолчанию.

«Разрешить входящий трафик от экземпляров, назначенных одной группе безопасности»

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#DefaultSecurityGroup