Хорошо, у меня есть VPC с тремя серверами приложений и экземпляром Postgres в RDS.
У меня есть группа безопасности под названием «rds-staging», которая разрешает входящие соединения через порт 5432 из группы безопасности под названием «app-elb-staging».
app-elb-staging - это группа безопасности, применяемая ко всем моим экземплярам EC2, и она позволяет исходящему трафику идти куда угодно.
Экземпляр RDS находится в Аризоне us-east-1e. Я могу подключиться к нему из моего экземпляра EC2 в us-east-1e (10.0.3. *), Но не из любых экземпляров EC2 в us-east-1a (10.0.1. *) Или us-east-1c (10.0 .2. *):
deploy@ip-10-0-3-220:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
Connection to xxx.us-east-1.rds.amazonaws.com 5432 port [tcp/postgresql] succeeded!
deploy@ip-10-0-1-155:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
nc: connect to xxx.us-east-1.rds.amazonaws.com port 5432 (tcp) failed: No route to host
deploy@ip-10-0-2-90:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
nc: connect to xxx.us-east-1.rds.amazonaws.com port 5432 (tcp) failed: No route to host
Кто-нибудь видел это раньше? Я проверил DNS, и каждая машина разрешает имя хоста на один и тот же IP-адрес (10.0.3.x).
Хорошо, наконец-то выяснилась основная причина этой проблемы. AMI, который я использовал, создавал мост, который вызывал проблему с подключением из-за столкновения с IP-адресами моих подсетей. Выход из sudo route -n на пораженном экземпляре выглядело так:
ubuntu@ip-10-0-1-92:~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.1.1 0.0.0.0 UG 0 0 0 eth0
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
При этом любое соединение с 10.0.2. * Завершится ошибкой:
deploy@ip-10-0-1-92:~$ nc -zv 10.0.2.53 22
nc: connect to 10.0.2.53 port 22 (tcp) failed: No route to host
Удаление моста с помощью sudo ifconfig lxcbr0 down решил проблему, но с помощью AMI, который не устанавливает этот мост, в первую очередь исправил корень.
Я видел такую проблему, вызванную одной из двух причин:
Вам не нужно определять маршруты для каждой подсети, они неявно указаны в таблице. Двойная проверка IP-адресов, которые ваша запись DNS разрешает в инстансах другой зоны доступности, гарантирует, что он находится в VPC.
Сетевые ACL могут пригодиться, но вы должны их настроить. По умолчанию они широко открыты. Вот почему я пометил это как маловероятное, но это может вызвать подобные проблемы. Тем не менее, ошибка «нет маршрута к хосту» предполагает, что это не ваша проблема.