alanacjr
(usa Ubuntu)
Enviado em 30/03/2009 - 23:40h
Eu tive um problema semelhante recentemente.
Eu havia configurado um firewall de bloqueio a um certo tempo e o cliente me pediu para configurar acesso remoto para o Terminal Server do windows 2000 e para poder utilizar uma o software de gestao, que utiliza um BD MS SQL.
Inicialmente não funcionava pois o servidor win 2000 não estava com gateway da rede configurado.
Depois verifiquei que o problema não era o re-direcionamento e sim o retorno do pacote, pois apesar de fazer o FORWARD da 3389 a porta do cliente desktop remoto era diferente então, a requisiçao chegava no servidor,pois a regra :
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 3389 -j DNAT --to 192.168.0.100:3389
estava funcionando, porem a porta de origem era diferente e o servidor tentava responder a conexão em outra porta, que era bloqueada pela regra :
iptables -A FORWARD -p tcp -i eth0 -j DROP
Vejam os log's :
[658903.080925] IN=ppp0 OUT= MAC= SRC=2xx.xxx.xxx.xxx DST=189.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=40792 DF PROTO=TCP SPT=1770 DPT=3389 WINDOW=65535 RES=0x00 SYN URGP=0
O pacote veio do clente da Area de trabalho remota de endereço de Intenet 200.xxx.xxx.xxx porta 1770(SPT=1770)chegou na interface PPP0 do Firewall que estava com o endereço 189.xxx.xxx.xxx (Velox Bridge)na porta 3389(DPT=3389).
[658300.150880] IN=ppp0 OUT=eth0 SRC=200.xxx.xxx.xxx DST=192.168.0.100 LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=39788 DF PROTO=TCP SPT=1761 DPT=3389 WINDOW=64793 RES=0x00 ACK URGP=0
Foi redirecionado para o end 192.168.0.100 pota 3389 (DPT=3389), através da interface eth0 (rede local), porém notem que a porta de origem é 1761 (SPT=1761).
[658903.083794] IN=eth0 OUT=ppp0 SRC=192.168.0.100 DST=200.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=7353 PROTO=TCP SPT=3389 DPT=1770 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Acima o retorno do pacote. Vejam que o destino é o 200.xxx.xxx.xxx porta 1770 (DPT=1770) neste ponto o pacote era bloqueado, pois não havia forward para esta porta (Havia para a 3389, que percebi depois que era desnecessária), pois todas as portas que não estavam especificadas estavam bloqueadas.
Pelos log's percebi que o cliente terminal server altera randomicamente a porta de origem da conexão, não sendo possivel fazer um FORWARD de uma porta apenas (Como a 1770 deste exemplo).
Resolvi o problema com a regra abaixo :
iptables -A FORWARD -s 192.168.0.100 -m state --state ESTABLISHED,RELATED -j ACCEPT
Desta forma permite o retorno apenas dos pacotes das conexões estabelecidas no servidor interno (Souce = 192.168.0.100).
Nas pequizas que fiz haviam varias dicas para fazer regras para porta UDP : 3389, Adicionar uma entrada na CHAIN INPUT para a porta 3389, fazer o FORWARD da porta 3389, etc...
No meu caso, apenas esta regra foi necessária para o TS :
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 3389 -j DNAT --to 192.168.0.100:3389
e essa para o SQL :
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 1433 -j DNAT --to 192.168.0.100:1433
Não precisou de mais nada...:)
