У меня в 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