Вопрос или проблема
Я не могу подключиться к публичной подсети (a1) на другой машине в той же VPC (10.0.4.0/16) из частных подсетей (a2 и a3)
Пример: ping -I ens6 10.0.4.71 не достигает хоста 10.0.4.71.
Я ищу идеи, как исправить вышеупомянутый маршрут (^^^ ping)?
Каждая машина имеет три сетевых адаптера.
Сетевая конфигурация:
BOX A (подсети a1/28, a2/28, a3/28)
BOX B (так же, как выше)
(Подсеть a1 публичная, a2 и a3 частные.)
Я могу подключаться только к другим подсетям на другой машине, следующим образом:
Box A: a1 --> Box B: a2
Box A: a2 --> Box B: a2
Box A: a2 --> Box B: a3
Но не
Box A: a2 --> Box B: a1
Сетевые настройки Box A:
$ 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
в консоли AWS маршруты:
публичная 10.0.4.64/28 подключена к IGW и 0.0.0.0/0 via local
обе частные 10.0.4.80/28 & 10.0.4.96/28 к NAT и 0.0.0.0/0 via local
Пример проблемы:
ping из Box A:sub a2(частная 10.0.4.80) в Box B (подсеть a1 (публичная 10.0.4.64))
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 завис, нет ответа, поэтому я принудительно завершаю
НО ping из публичной подсети Box A в публичную подсеть Box B работает:
ping из Box A:sub a1(10.0.4.70: 10.0.4.64/28) в Box B (подсеть a1 (10.0.4.64/28))
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
Box A частный в Box B частный также работает:
ping из Box A:sub a2(10.0.4.80) в Box B (подсеть a3 (10.0.4.96))
работает
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
Box A (a2) -> Box B (a2) работает
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
Так что, снова, как мне исправить:
ping -I ens6 10.0.4.71
Ответ или решение
Вопрос о том, почему экземпляр AWS не может установить соединение с другим экземпляром в одной и той же публичной подсети в VPC, поднимает важные аспекты настройки сети. В данном случае предполагается, что инфраструктура состоит из нескольких сетевых адаптеров и разных подсетей, что усложняет диагностику.
Фон проблемы
Имеет место ситуация, когда экземпляры располагаются в следующих подсетях:
- Подсеть a1 (публичная): 10.0.4.64/28
- Подсеть a2 (приватная): 10.0.4.80/28
- Подсеть a3 (приватная): 10.0.4.96/28
Проблема заключается в следующем:
- Вы не получаете ответа, когда пытаетесь подключиться от экземпляра в приватной подсети (например, Box A, 10.0.4.86) к экземпляру в публичной подсети (Box B, 10.0.4.71).
- Обратная связь между публичными подсетями (a1) между двумя экземплярами работает без проблем, как и связь между приватными подсетями.
Варианты решения
1. Проверка правил безопасности (Security Groups)
Убедитесь, что в правилах безопасности для экземпляра в публичной подсети (Box B) разрешён входящий трафик ICMP, который необходим для команд ping. Например, у вас должен быть добавлен inbound rule с типом "All ICMP" для источников, подходящих для частной подсети.
Type Protocol Port Range Source
All ICMP ICMP N/A 10.0.4.80/282. Проверка сетевых ACL (Network ACLs)
Проверьте, что Network ACL для соответствующих подсетей позволяет входящий и исходящий ICMP-трафик. По умолчанию ACL может блокировать этот тип трафика:
- Входящие правила для подсети a1 должны разрешать ICMP из 10.0.4.80/28.
- Исходящие правила должны разрешать ICMP обратно в 10.0.4.80/28.
3. Проверка маршрутов (Routing)
Убедитесь, что в таблице маршрутов (Route Table) для публичной подсети a1 указан маршрут по умолчанию для 0.0.0.0/0 через Internet Gateway. Адреса приватных подсетей (a2 и a3) должны иметь маршруты с direct (local) для связи между наборами адресов.
Destination Target
10.0.4.0/16 local
0.0.0.0/0 igw-xxxxxxxx (для публичной подсети)4. Проверка настройки интерфейсов
Проверьте настройки сетевых интерфейсов в операционной системе, чтобы гарантировать, что IP-адреса правильно назначены и соответствуют вашим ожиданиям.
Вывод команды ip -4 a, который вы предоставили, показывает, что сетевые интерфейсы настроены правильно. Однако стоит убедиться, что назначения маршрутов также корректны.
5. Использование сетевого анализа (Network Diagnostic)
Если все вещи выше проверены и не решают проблему, попробуйте воспользоваться утилитами для диагностики:
- Используйте
tracerouteдля изучения маршрута пакетов и выявления места, где маршрут может быть заблокирован. - Проверьте с помощью команд
tcpdumpилиWireshark, чтобы увидеть, проходят ли пакеты до или от экземпляра.
Заключение
Эти шаги должны помочь вам выяснить, почему экземпляры в разных подсетях не могут общаться. Вероятнее всего, дело в правилах безопасности и настройках маршрутизации. Убедившись, что все настройки верны, вы сможете установить соединение между экземплярами в разных сетевых сегментах вашей VPC.