wget e encaminhamento de porta

Question

Eu tenho um problema estranho. Eu posso executar este comando muito bem de vários servidores:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://GW-BOX:9091/weijhkdsvn/v9_odbc//CRONTAB.2014020

Onde "GW-BOX" é o gateway para minha rede, USER123 e PASSWORD representam o usuário e a senha para weijhkdsvn, e 9091 apontam para um servidor Linux interno. O problema é que esse comando atinge o tempo limite e / ou é rejeitado.

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://GW-BOX:9093/weijhkdsvn/v9_odbc//CRONTAB.20140206

A porta 9093 aponta para um servidor interno diferente. Note que a única diferença é a porta.

Então, tentei fazer um wget diretamente do servidor, para garantir que o http fosse configurado corretamente:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://9091-Server:80/weijhkdsvn/v9_odbc//CRONTAB.20140206

Nesse caso, o 9091-Server é o servidor interno ao qual a porta 9091 se refere. Funciona bem. Então eu tentei o mesmo comando, mas simulando a porta 9093:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://9093-Server:80/weijhkdsvn/v9_odbc//CRONTAB.20140206

em que 9093-Server refere-se ao servidor interno ao qual 9093 aponta.

Portanto, os exemplos acima provam que o 9093-Server tem a configuração http corretamente para permitir o wget, até onde eu possa ver. Isso sugere que talvez o problema esteja com o GW-BOX, então testei as portas com o telnet e a porta 9091 funcionou bem.

[wmsodbc]> telnet GW-BOX 9091
Trying GW-BOX...
Connected to GW-BOX.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[wmsodbc]> 

Mas a porta 9093 não funcionou:

[wmsodbc]> telnet GW-BOX 9093
Trying GW-BOX...
telnet: connect to address GW-BOX: Connection refused
[wmsodbc]>

Então eu verifiquei o iptables no GW-BOX:

[root@wmsgateway ~]# iptables-save | grep "909[13]"
-A INPUT -p tcp -m tcp --dport 9091 -j LOG 
-A INPUT -p tcp -m tcp --dport 9093 -j LOG 
-A PREROUTING -d GW-BOX-EXTERNAL-IP/32 -p tcp -m tcp --dport 9091 -j DNAT --to-destination 9091-ServerIp:80 
-A PREROUTING -d GW-BOX-EXTERNAL-IP/32 -p tcp -m tcp --dport 9093 -j DNAT --to-destination 9093-ServerIp:80 
-A POSTROUTING -d 9091-ServerIp/32 -p tcp -m tcp --dport 9091 -j SNAT --to-source GW-BOX-INTERNAL-IP
-A POSTROUTING -d 9093-ServerIp/32 -p tcp -m tcp --dport 9093 -j SNAT --to-source GW-BOX-INTERNAL-IP 
[root@wmsgateway ~]# 

Então, o que mais posso verificar para ver por que a porta 9091 aceita solicitações wget / telnet, mas 9093 não?

    

Answer 1

Um método para verificar onde está o problema é trocar as portas pelos servidores. ServerA tem atualmente a porta 9091 e funciona corretamente, ServerB tem a porta 9093 e falha. Para determinar se o problema está no GW-Box ou no próprio servidor, gire a configuração do iptables na caixa GW para o SNAT. Ponto 9091 para ServerB e 9093 para ServerA. Se o 9091 continuar a funcionar, você sabe que o problema está em algum lugar na regra que você tem para a porta 9093, já que os Servidores A e B trabalham em 9091, isso também pode indicar um problema de regra de firewall no Servidor B também. Se 9091 falhar, mas 9093 funcionar, você pode seguramente assumir que seu GW-Box está operando corretamente e que o Servidor B de alguma forma não está permitindo que as portas superiores acessem via WGET, desde que você tenha confirmado anteriormente que o WGET está acessível diretamente. / p>     

Answer 2

Primeiro, o teste que você fez diretamente no wget para os servidores, de onde foram feitos esses testes? do host original, ou da GW-box ou de algum host "de terceiros".

Além disso, no GW-box você verificou se outros serviços usam a porta 9093? (no gw-box rodar algo como:

netstat -lnptu | grep 9093

    

Answer 3

Ok, eu descobri a questão. O GW-BOX foi criado para ser uma caixa de gateway, obviamente. Mas como eu disse em outro tópico aqui , Não consegui acessar a internet através desta caixa. Acontece que, uma vez que consertei essa incapacidade de acessar a internet ATRAVÉS desta GW-BOX, pude usar o wget muito bem. No meu caso, de acordo com o tópico que acabei de mencionar, eu tive que mudar o iptables de

iptables-save | grep eth
-A POSTROUTING -o eth1 -j SNAT --to-source 68.AAA.BBB.155

para

iptables-save | grep eth
-A POSTROUTING -o eth2 -j SNAT --to-source 68.AAA.BBB.155

e agora as coisas funcionam. Eu também configurei portas totalmente novas, mas não acho que essa tenha sido a causa raiz.

Obrigado. Espero que isso ajude alguém.