У меня есть простой веб-сервер (только apache), работающий на AMI CentOS на AWS внутри VPC. У меня есть группы безопасности AWS и iptables, открытые для порта 80, без требований к источнику. Затем я настраиваю Elastic Load Balancer для направления трафика на один экземпляр (когда все работает, я клонирую его для нескольких экземпляров с балансировкой нагрузки). Экземпляр, зарегистрированный в балансировщике нагрузки, в порядке, и в настоящее время указан как «исправный»
Если я открою локальный IP-адрес экземпляра в своем браузере, я могу без проблем подключаться / просматривать страницы.
Если я вызываю имя хоста ELB в своем браузере, время ожидания истекает. Я проверяю / var / log / messages на экземпляре, и iptables сбросил пакет. Я понятия не имею, почему iptables не находит совпадений для этих пакетов, но делает для прямых подключений.
Я удалил большинство правил в iptables, чтобы убедиться, что ничего странного не взаимодействует. Вот мой текущий набор правил:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.40.0.0/16 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -j LOG --log-prefix "IP DROP NO MATCH: "
-A RH-Firewall-1-INPUT -j DROP
COMMIT
Вот как выглядят отброшенные пакеты:
Aug 28 21:59:54 ip-10-40-80-11 kernel: IP DROP NO MATCH: IN=eth0 OUT= MAC=0e:57:37:73:05:4e:0e:57:37:40:00:3F:68:21 SRC=10.40.80.179 DST=10.40.80.11 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2363 DF PROTO=TCP SPT=61866 DPT=80 WINDOW=58 RES=0x00 ACK FIN URGP=0
Из любопытства я закомментировал --dport 80 строка в моей конфигурации iptables, чтобы любой трафик порта 80 был заблокирован; Затем я посетил экземпляр в своем браузере по прямому IP-адресу и поискал журнал сброшенных пакетов. Я хотел сравнить, что будет записывать журнал отброшенных пакетов для «успешных» соединений с моей проблемой с ELB. Вот что я увидел:
Aug 28 22:05:12 ip-10-40-80-11 kernel: IP DROP NO MATCH: IN=eth0 OUT= MAC=0e:57:37:73:05:4e:0e:57:37:40:00:3F:68:21 SRC=10.40.180.110 DST=10.40.80.11 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=2816 DF PROTO=TCP SPT=50995 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Единственная разница (кроме источника, что не имеет значения?) Заключалась в том, что пакеты ELB заканчивались на ACK FIN а моя прямая связь закончилась SYN ... но я признаю, что недостаточно разбираюсь в тонкостях TCP, чтобы понять, действительно ли это имеет значение.
В чем может быть разница, которая помешает HTTP-пакетам ELB успешно пройти через брандмауэр?
Изменить: результаты tcpdump
# tcpdump -i eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:49:38.994125 IP 10.40.80.11.http > 10.40.80.179.62394: Flags [F.], seq 2393122986, ack 3223961569, win 227, options [nop,nop,TS val 116463035 ecr 1792527], length 0
22:49:43.231187 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [S], seq 1887835523, win 14600, options [mss 1460,sackOK,TS val 1836427 ecr 0,nop,wscale 8], length 0
22:49:43.231267 IP 10.40.80.11.http > 10.40.80.179.62426: Flags [S.], seq 3789128001, ack 1887835524, win 14480, options [mss 1460,sackOK,TS val 116467272 ecr 1836427,nop,wscale 6], length 0
22:49:43.231578 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [.], ack 1, win 58, options [nop,nop,TS val 1836427 ecr 116467272], length 0
22:49:43.231684 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [F.], seq 1, ack 1, win 58, options [nop,nop,TS val 1836427 ecr 116467272], length 0
22:49:43.231774 IP 10.40.80.11.http > 10.40.80.179.62426: Flags [F.], seq 1, ack 2, win 227, options [nop,nop,TS val 116467272 ecr 1836427], length 0
22:49:43.232012 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [.], ack 2, win 58, options [nop,nop,TS val 1836427 ecr 116467272], length 0
22:49:47.632855 IP 10.40.80.179.62427 > 10.40.80.11.http: Flags [S], seq 3419546406, win 14600, options [mss 1460,sackOK,TS val 1837527 ecr 0,nop,wscale 8], length 0
22:49:47.632929 IP 10.40.80.11.http > 10.40.80.179.62427: Flags [S.], seq 1724369749, ack 3419546407, win 14480, options [mss 1460,sackOK,TS val 116471673 ecr 1837527,nop,wscale 6], length 0
22:49:47.632942 IP 10.40.80.179.62416 > 10.40.80.11.http: Flags [F.], seq 3666215037, ack 243876755, win 58, options [nop,nop,TS val 1837527 ecr 116411675], length 0
22:49:47.633055 IP 10.40.80.11.http > 10.40.80.179.62416: Flags [F.], seq 1, ack 1, win 227, options [nop,nop,TS val 116471673 ecr 1837527], length 0
22:49:47.633209 IP 10.40.80.179.62427 > 10.40.80.11.http: Flags [.], ack 1, win 58, options [nop,nop,TS val 1837527 ecr 116471673], length 0
22:49:47.633282 IP 10.40.80.179.62416 > 10.40.80.11.http: Flags [.], ack 2, win 58, options [nop,nop,TS val 1837527 ecr 116471673], length 0
Пытаться sudo service iptables stop чтобы узнать, связано ли это с iptables.
Вероятно, iptables не видит пакет ACK / FIN как новое соединение.
Поскольку правило порта 80 указывает, что подключения разрешены только в том случае, если подключение является новым, оно отбрасывает все подключения, которые не являются новыми подключениями.
что произойдет, если вы удалите -m state --state NEW из порта 80 правило и тестировать?