Eu tenho um servidor web simples (somente apache) rodando na AMI do CentOS na AWS dentro de um VPC. Eu tenho os grupos de segurança da AWS e iptables abertos para a porta 80, sem requisitos de origem. Em seguida, configurei um Elastic Load Balancer para direcionar o tráfego para a instância única (quando tudo funciona, clonei para várias instâncias de balanceamento de carga). A instância registrada com o balanceador de carga está bem e está atualmente listada como "saudável"
Se eu puxar o IP local das instâncias no meu navegador, posso me conectar / visualizar páginas muito bem.
Se eu puxar o nome do host do ELB no meu navegador, o tempo limite será esgotado. Eu verifico / var / log / messages na instância e o iptables descartou o pacote. Eu não tenho idéia porque o iptables não encontra uma correspondência para esses pacotes, mas faz para as conexões diretas.
Eu removi a maioria das regras do iptables apenas para ter certeza de que nada interagia de maneira estranha. Aqui está o meu conjunto de regras atual:
*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
Veja como os pacotes descartados se parecem:
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
Por curiosidade, eu comentei a linha --dport 80 na minha configuração do iptables para que qualquer tráfego da porta 80 fosse bloqueado; Em seguida, visitei a instância no meu navegador por IP direto e procurei pelo log de pacotes descartados. Eu queria comparar o que o log de pacotes descartados registraria para conexões 'bem-sucedidas' versus o meu problema com o ELB. Aqui está o que eu vi:
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
A única diferença (diferente da fonte, que não deveria importar?) foi que os pacotes ELB terminaram em ACK FIN enquanto minha conexão direta terminou em SYN ... mas eu admito que não sabe o suficiente sobre as complexidades do TCP para saber se isso realmente está fazendo alguma diferença.
Qual pode ser a diferença que impediria que os pacotes HTTP ELB passassem pelo firewall com sucesso?
Editar: resultados do 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
É provável que o iptables não veja o pacote ACK / FIN como uma nova conexão.
Como a regra da porta 80 especifica que as conexões só são permitidas se a conexão for uma nova conexão, todas as conexões que não forem novas serão descartadas.
o que acontece se você remover -m state --state NEW da regra da porta 80 e testar?
Teste sudo service iptables stop para ver se é relacionado ao iptables.