Firewall com ADSL Router X ADSL Bridge - Problemas!! [RESOLVIDO]

removido
(usa Nenhuma)

Enviado em 04/02/2009 - 15:42h

Amigos,

Estou enfrentando problemas com o servidor da empresa onde trabalho. Este servidor possui duas placas de rede (com IP fixo), uma é ligada ao modem ADSL Router e outra ligada ao Switch. Basicamente o serviço fornecido é DHCP (via linux), Firewall (iptables) e Squid. Funciona tudo perfeitamente.

Acontece que recentemente contratei outro plano de internet. Agora tenho outro link da Embratel PME com IP dinâmico, que é praticamente igual ao Cable Modem da Virtua. A diferença é que este modem é bridge e fornece o IP via DHCP.

Então defini para que minha placa de rede externa adquirisse IP via DHCP e pluguei o cabo do novo link. Beleza! A placa pegou um IP válido (externo)!

Acontece que com este novo link eu não consigo conectar em serviço HTTPS (porta 443). Todos outros serviços funcionam corretamente, só o HTTPS que não. Com isso não é possível acessar diversos sites e também não consigo ler e-mails via IMAP seguro.

Quando volto a utilizar o modem roteador, tudo funciona perfeitamente de novo.

Não foi alterado nada no firewall (a politica padrão é DROP), basicamente as regras que liberam a 443 são essas:

$IPTABLES -A INPUT -i $LAN -p tcp --dport 443 -j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 443 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 443 -j ACCEPT

$IPTABLES -A INPUT -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -m state --state RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -m state --state RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state RELATED -j ACCEPT

Alguém pode me dar alguma luz porque não consigo utilizar conexões seguras quando utilizo o modem bridge?

Obrigado!
Alex.

removido
(usa Nenhuma)

Enviado em 05/02/2009 - 11:28h

Help :)

pelo
(usa Debian)

Enviado em 07/02/2009 - 16:01h

Meu caro,

Já tentou colocar um notebook para pegar Ip válido e tentar navegar?
pode ser algum bloqueio na operadora, já que com o outro funciona perfeitamente sem você alterar nada.

Sérgio Abrantes
[]'s

removido
(usa Nenhuma)

Enviado em 08/02/2009 - 23:37h

Obrigado pela resposta!

Pior que não é problema na operadora... ao ligar o link em um notebook a navegação ocorre normalmente... tudo funciona e não há nenhum bloqueio de portas.

É alguma coisa no linux mesmo... mesmo desabilitando o firewall, permitindo qualquer conexão, não consigo navegar em HTTPS (porta 443)... outros protocolos funcionam normalmente.

Estou configurando outra maquina para fazer testes mais aprofundados... por enquanto segue sem solução.

accamargo
(usa Debian)

Enviado em 09/02/2009 - 21:34h

faça um backup de seu script de firewall e depois mude suas politicas de "DROP" para ACCEPT, assim vc vai saber se o problema é seu firewall ou sua operadora, posta ai pra gente ver ..

removido
(usa Nenhuma)

Enviado em 25/02/2009 - 13:33h

Fiz o seguinte teste: configurei outra máquina linux com instalação padrão do Debian. Em uma das placas de rede (eth0), liguei o modem da Embratel PME, na outra placa liguei um notebook através de cabo cross-over.

Utilizei o mesmo script de firewall que estava utilizando no outro servidor.
E por incrível que pareça, tudo funciona! Tanto o servidor navega normalmente, quanto o cliente (notebook)

Então liguei tudo no servidor "oficial" e tentei depurar o problema, e cheguei a conclusão que o FORWARD não funciona! Todas as regras de Forward estão OK, mas as conexões não são estabelecidas.

Através do Wireshark tentei depurar a conexão HTTPS (443) e cheguei a seguinte conclusão:

- Conexão Embratel PME (problemática):
No. Time Source Destination Protocol Info
1 0.000000 e-cube yx-in-f104.google.com TCP silkp2 > https [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0
2 0.000108 e-cube yx-in-f104.google.com TCP silkp2 > https [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0
3 6.134882 e-cube yx-in-f104.google.com TCP bpcp-trap > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
4 6.135091 e-cube yx-in-f104.google.com TCP bpcp-trap > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
5 6.295541 yx-in-f104.google.com e-cube TCP https > bpcp-trap [SYN, ACK] Seq=0 Ack=1 Win=5720 Len=0 MSS=1430
6 6.295628 e-cube yx-in-f104.google.com TCP bpcp-trap > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
7 6.295695 e-cube yx-in-f104.google.com TCP [TCP Dup ACK 6#1] bpcp-trap > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
8 6.296247 e-cube yx-in-f104.google.com SSL Client Hello
9 6.296335 e-cube yx-in-f104.google.com SSL [TCP Out-Of-Order] Client Hello
10 6.460784 yx-in-f104.google.com e-cube TCP https > bpcp-trap [ACK] Seq=1 Ack=71 Win=5720 Len=0
11 6.467008 yx-in-f104.google.com e-cube SSL [TCP Previous segment lost] Continuation Data
12 6.467048 e-cube yx-in-f104.google.com TCP [TCP Dup ACK 9#1] bpcp-trap > https [ACK] Seq=71 Ack=1 Win=65535 Len=0 SLE=1431 SRE=1719
13 6.467105 e-cube yx-in-f104.google.com TCP [TCP Dup ACK 9#2] bpcp-trap > https [ACK] Seq=71 Ack=1 Win=65535 Len=0 SLE=1431 SRE=1719
14 16.458331 yx-in-f104.google.com e-cube TCP https > bpcp-trap [FIN, ACK] Seq=1719 Ack=71 Win=5720 Len=0

- Conexão GVT (funcionando):
No. Time Source Destination Protocol Info
1 0.000000 192.168.2.17 209.85.193.104 TCP autopac > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
2 0.021640 209.85.193.104 192.168.2.17 TCP https > autopac [SYN, ACK] Seq=0 Ack=1 Win=5720 Len=0 MSS=1430
3 0.021717 192.168.2.17 209.85.193.104 TCP autopac > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
4 0.021781 192.168.2.17 209.85.193.104 TCP [TCP Dup ACK 3#1] autopac > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
5 0.025405 192.168.2.17 209.85.193.104 TLSv1 Client Hello
6 0.025519 192.168.2.17 209.85.193.104 TLSv1 [TCP Out-Of-Order] Client Hello
7 0.047726 209.85.193.104 192.168.2.17 TCP https > autopac [ACK] Seq=1 Ack=71 Win=5720 Len=0
8 0.052726 209.85.193.104 192.168.2.17 TLSv1 Server Hello,
9 0.052925 209.85.193.104 192.168.2.17 TLSv1 Certificate
10 0.052970 192.168.2.17 209.85.193.104 TCP autopac > https [ACK] Seq=71 Ack=1719 Win=65535 Len=0
11 0.053029 192.168.2.17 209.85.193.104 TCP [TCP Dup ACK 10#1] autopac > https [ACK] Seq=71 Ack=1719 Win=65535 Len=0
12 0.185548 192.168.2.17 209.85.193.104 TCP autopac > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
13 0.187009 192.168.2.17 209.85.193.104 TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
14 0.187123 192.168.2.17 209.85.193.104 TLSv1 [TCP Out-Of-Order] Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
15 0.211091 209.85.193.104 192.168.2.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message

CONCLUSÃO:

Na conexão da Embratel PME do servidor "oficial" não recebe-se o SERVER HELLO... no servidor de testes que foi configurado utilizando a mesma conexão, tudo funciona!

O que pode haver de errado no linux que não estabelece esta conexão?? Será que vou ter que reinstalar somente para resolver um problema aparentemente banal?

Obrigado por qualquer ajuda!
Alex.

removido
(usa Nenhuma)

Enviado em 12/03/2009 - 12:17h

O problema era no Linux mesmo! Não consegui identificar o que exatamente.

Substitui o servidor que estava sendo utilizado por um com Debian 5.0. Funcionou tudo de primeira! Agora este novo servidor está fazendo balanceamento de carga entre os 2 links e também gerenciamento de alta disponibilidade.

Obrigado pela ajuda de todos!
Alex.