AWS: Хост с несколькими сетевыми интерфейсами (подсеть) не может найти маршрут к другому экземпляру в той же публичной подсети внутри VPC.

Вопрос или проблема

СЕРВЕР A (подсеть a1/28, a2/28, a3/28)  
СЕРВЕР B (то же, что и выше)  

$ ip -4 a  
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000  
    inet 10.0.4.70/28 metric 100 brd 10.0.4.79 scope global dynamic ens5  
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000  
    inet 10.0.4.86/28 metric 200 brd 10.0.4.95 scope global dynamic ens6  

$ ip ro  
default via 10.0.4.65 dev ens5 proto dhcp src 10.0.4.70 metric 100   
default via 10.0.4.81 dev ens6 proto dhcp src 10.0.4.86 metric 200   
10.0.4.2 via 10.0.4.65 dev ens5 proto dhcp src 10.0.4.70 metric 100   
10.0.4.2 via 10.0.4.81 dev ens6 proto dhcp src 10.0.4.86 metric 200   
10.0.4.64/28 dev ens5 proto kernel scope link src 10.0.4.70 metric 100   
10.0.4.65 dev ens5 proto dhcp scope link src 10.0.4.70 metric 100   
10.0.4.80/28 dev ens6 proto kernel scope link src 10.0.4.86 metric 200   
10.0.4.81 dev ens6 proto dhcp scope link src 10.0.4.86 metric 200   

$ ip ru  
0:      from all lookup local  
32765:  from 10.0.4.86 lookup 101 proto static  
32766:  from all lookup main  
32767:  from all lookup default  

ping 10.0.4.71  
PING 10.0.4.71 (10.0.4.71) 56(84) bytes of data.  
64 bytes from 10.0.4.71: icmp_seq=1 ttl=64 time=0.462 ms  
64 bytes from 10.0.4.71: icmp_seq=2 ttl=64 time=0.452 ms  
^C  

ping -I ens6 10.0.4.71  
PING 10.0.4.71 (10.0.4.71) from 10.0.4.86 ens6: 56(84) bytes of data.  
^C  

ping -I ens6 10.0.4.103  
PING 10.0.4.103 (10.0.4.103) from 10.0.4.86 ens6: 56(84) bytes of data.  
64 bytes from 10.0.4.103: icmp_seq=1 ttl=64 time=0.431 ms  
^C  

ping -I ens6 10.0.4.87  
PING 10.0.4.87 (10.0.4.87) from 10.0.4.86 ens6: 56(84) bytes of data.  
64 bytes from 10.0.4.87: icmp_seq=1 ttl=64 time=0.466 ms  
^C  

Ответ или решение

Проблема: отсутствие маршрута между экземплярами в одной публичной подсети VPC с несколькими сетевыми интерфейсами (NIC)

В данной ситуации мы имеем экземпляры (BOX A и BOX B), которые находятся в одной и той же Virtual Private Cloud (VPC) с несколькими подсетями. Подсеть a1 является публичной подсетью, а подсети a2 и a3 — приватными. При этом, несмотря на наличие сетевых интерфейсов, связывающих эти подсети, мы сталкиваемся с проблемой, когда экземпляры могут общаться между собой только в рамках их частных подсетей, но не могут установить соединение с экземплярами в публичной подсети на другом BOX.

1. Анализ конфигурации сети

1. Подсети и IP-адреса:

   • BOX A использует 10.0.4.70 (a2) и 10.0.4.86 (a3);
   • BOX B использует 10.0.4.71 (a1) и соответствует указанным характеристикам.

2. Маршрутизация:

   • Ваша маршрутизируемая таблица IP-адреса показывает, что параметры по умолчанию и маршруты к местным IP-адресам настроены корректно.
   • Поскольку подключение между каждым из приватных интерфейсов (a2 и a3) работает, проблема кроется именно в маршрутах к публичной подсети a1.

2. Проблема блокировки трафика

Причина, по которой экземплары не могут общаться между публичной подсетью и частными подсетями, может быть связана с правилами безопасности (Security Groups) или сетевыми ACL (Network Access Control Lists).

• Security Groups: Проверьте, разрешен ли входящий трафик в Security Group BOX B с адреса 10.0.4.86 (a3) и аналогично из других подсетей. Вам нужно убедиться, что вызовы ICMP (пинг) разрешены из необходимых подсетей.

• Network ACLs: Убедитесь, что сетевые ACL не блокируют трафик между подсетями. Стандартные настройки могут позволять или блокировать трафик в зависимости от конфигурации.

3. Тестирование и отладка

1. Проверьте, происходит ли блокировка пакетов на уровне интерфейса используя утилиты типа tcpdump. Это позволит увидеть, приходит ли ICMP-запрос на интерфейс BOX B.

   sudo tcpdump -i ens5 icmp

2. Если пакеты приходят, но не получают откликов, это подтверждает, что проблема на уровне безопасности или ACL.

4. Решение проблемы

• Изменение правил безопасности: Отредактируйте rules Security Group для BOX B, добавив правило, которое разрешает входящие ICMP-запросы от подсетей a2 и a3.

• Настройка Network ACLs: Убедитесь, что оба направления (входящие и исходящие) разрешают трафик ICMP.

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

Заключение

Данная проблема может быть решена посредством проверки и соответствующей настройки правил безопасности и сетевых ACL. Понимание структуры вашей сети и настроек VPC в AWS критически важно для успешного устранения подобных неисправностей. Рассматривайте подобные вопросы с учетом всех компонентов, влияющих на сетевую коммуникацию, и проводите детальную диагностику для нахождения наиболее эффективных решений.