Приложение из одной подсети не может достучаться до сервиса в другой подсети, хотя security group на обоих инстансах настроены правильно. Объясните, в чём может быть разница между security group и network ACL и где искать проблему.

Короткий ответ

Security group — stateful и применяется на уровне инстанса (разрешённый входящий ответ пропускается автоматически), а network ACL (NACL) — обычно stateless и применяется на уровне подсети, поэтому для него нужно явно разрешить трафик в обе стороны. Проблема часто в том, что NACL подсети блокирует либо входящий, либо ответный трафик.

Как это работает подробнее

пакет, идущий между подсетями, проверяется security group источника и назначения (stateful) и одновременно NACL обеих подсетей на входе и выходе (stateless, то есть ответный пакет должен быть разрешён отдельным правилом).

Пример кода

example.txtКопировать

NACL private-subnet:
  Inbound:  100 ALLOW TCP 5432 from 10.0.11.0/24
  Outbound: 100 ALLOW TCP 5432 to 10.0.11.0/24   # но ответ идёт с эфемерного порта!
  # Отсутствует: Outbound ALLOW TCP 1024-65535 to 10.0.11.0/24

Что использовать на практике

• Рекомендация. при диагностике межсетевых проблем проверяют NACL после security group: типичная ошибка — разрешён входящий TCP на целевой порт, но не разрешён исходящий трафик с эфемерных портов обратно к источнику, из-за чего SYN доходит, а SYN-ACK блокируется.
• Проверка. TCP-соединение зависает на этапе handshake (SYN_SENT на клиенте без ответа); tcpdump на стороне сервера покажет входящий SYN, но ответ не дойдёт без правильного outbound-правила NACL.

Подводные камни

• Риск. считать, что раз security group настроены верно, NACL можно не проверять
• Риск. забывать, что правила NACL применяются по номеру в порядке возрастания и более ранний deny может перекрыть более поздний allow
• Риск. использовать кастомный NACL с default deny, не добавив правило для эфемерных портов.