SSH sem acesso via internet

[Dirty]

Boa tarde pessoal, meu cenário é o seguinte:

Possuo um modem em modo BRIDGE, que envia a conexão ao roteador onde é feita toda a configuração, e do roteador vai para os pcs e para o servidor.
Meu problema está no fato do SSH, rodando no servidor não aceitar conexões vindas da internet.

Consigo me conectar perfeitamente ao ssh via rede local.
ip: 192.168.0.178 : 60022

Se eu tento me conectar no mesmo servidor com o IP da internet (externo) porem de um computador da rede (mesma rede do servidor).
ip: 187.5.180.199 : 60022, também consigo fazer login e me conectar, mas se for de outra rede distinta, não há conexão.

connection time out
network error

Não sei o que fazer, o roteador (muito fraco de configurações por sinal) é o modelo DI-524 da DLINK.
Os ips, são atribuídos a rede por DHCP do roteador, o servidor esta com dhcp ativado mas fixo no 192.168.0.178.
No virtual server (onde deveria abrir a porta do roteador) ele está configurado:

Virtual Server List
  	Name 	Private IP 	Protocol 	Schedule 	 
	SSH	192.168.0.178	TCP 60022 / 60022	Always

E no DMZ, também o ip 192.168.0.178 (Servidor) esta aberto para conexões externas.
Mesmo apos todas essas configurações, verificando uma saída do NMAP:

root@slackware:/home/serv01# nmap -p 60022 187.5.180.199

Starting Nmap 5.21 ( http://nmap.org ) at 2010-12-31 18:19 BRT
Nmap scan report for 187.5.180.199
Host is up (0.0010s latency).
PORT      STATE    SERVICE
60022/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 9.02 seconds
root@slackware:/home/serv01# nmap -p 60022 192.168.0.178

Starting Nmap 5.21 ( http://nmap.org ) at 2010-12-31 18:20 BRT
Nmap scan report for 192.168.0.178
Host is up (0.0011s latency).
PORT      STATE SERVICE
60022/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 9.11 seconds
root@slackware:/home/serv01#

A porta no servidor local está aberta, já no ip externo ela aparece fechada.
O servidor está com a internet habilitada:

root@slackware:/home/serv01# ping -c 2 www.google.com.br
PING www.l.google.com (64.233.163.104) 56(84) bytes of data.
64 bytes from bs-in-f104.1e100.net (64.233.163.104): icmp_req=1 ttl=55 time=330 ms
64 bytes from bs-in-f104.1e100.net (64.233.163.104): icmp_req=2 ttl=55 time=394 ms

--- www.l.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 330.931/362.797/394.664/31.872 ms
root@slackware:/home/serv01#

Não sei o que fazer, estou achando que o problema esta no roteador, certo?
Atualizei o firmware agora pouco, está na ultima versão.

Firmware Version: V4.05 , Thu, Mar 04 2010

As regras usadas no servidor são as seguintes:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -p tcp --dport 60022 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp -d 192.168.0.1 --dport 60022 -j DNAT --to 192.168.0.178:60022

iptables -A FORWARD -p tcp -d 192.168.0.178 --dport 60022 -j ACCEPT

Valeu, abraços.

[mmachado]

Dirty, me explica uma coisa... O teu DLink é quem tem o IP público, e faz o encaminhamento da porta 60022 para a porta 60022 do teu servidor, no IP 192.168.0.178. Correto?

Se for isso, não entendi as regra de iptables do servidor.

Ele não precisa de ip_forward se ele não for o gateway da rede (pelo visto o teu gateway é o dlink).

Qual o motivo da regra de NAT? Quem é o IP 192.168.0.1? Se for o Dlink, ela é desnecessária, pois nenhum pacote chegará da internet ao servidor com destino o ip final 1. (a mesma dúvida vale para a regra da FORWARD)

A política padrão da chain INPUT é DROP? Se não for, a regra de accept na porta 60022 também não é necessária. Se for DROP, veja se a política da chain OUTPUT está considerando a resposta aos acessos (ou se há regras para ESTABLISHED).

[]s, MM

[Dirty]

Boa noite MMACHADO.

Dirty, me explica uma coisa... O teu DLink é quem tem o IP público, e faz o encaminhamento da porta 60022 para a porta 60022 do teu servidor, no IP 192.168.0.178. Correto?

Sim, sim.. aquelas regras eram antigas, achei que não teria problema em mante-las.
Pois bem, já retirei elas :)

Apos retirar as regras do firewall, fui novamente conferir como estava o estado da porta (de outro PC da rede) porem testando com o IP externo:

Starting Nmap 5.21 ( http://nmap.org ) at 2011-01-02 00:56 PST
Nmap scan report for 188-72-47-11.bnut3242.dsl.net.br (188.72.47.11)
Host is up (0.00058s latency).
PORT      STATE SERVICE
60022/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds

Esta retornando como aberta, testando a porta 60022 de outro local externo (Na saída a seguir foi usado o mesmo comando, porem com o serviço do NmapONLINE):

Starting Nmap 4.75 ( http://nmap.org ) at 2011-01-02 04:01 St?ední Evropa (b?žný ?as)
Interesting ports on 188-72-47-11.bnut3242.dsl.net.br (188.72.47.11):
PORT STATE SERVICE
60022/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 4.31 seconds

Esta aparecendo como se algo estivesse barrando ela, um firewall.
No iptables não ha mais regras:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

No roteador as regras de firewall são as seguintes:

Firewall Rules List
  	Action 	Name 	Source 	Destination 	Protocol 	 
	Allow	SSH	*,*	*,*	*,60022	 
	Allow	SSH	WAN,*	LAN,192.168.0.178	TCP,60022	
	Allow	Ping WAN port	WAN,*	WAN,*	ICMP,*	 
	Deny	Default	*,*	LAN,*	*,*	 
	Allow	Default	LAN,*	*,*	*,*

Não estou conseguindo enxergar o que pode estar errado, que esta barrando as conexões vindas de fora ao SSH.

Valeu, abraços.

[mmachado]

Me parece que é alguma configuração no DLink. Experimenta ativar a opção DMZ dele apontando tudo para o teu servidor e veja se conecta. Se funcionar, é a regra de redirecionamento de porta que não tá funcionando direito.

Só para garantir que você está vendo os pacotes encaminhados para o servidor, experimenta deixar um tcpdump rodando lá enquanto faz os testes. É mais garantido do que esses resultados de verificações online que existem por aí.

tcpdump -ni eth0 port 60022 and not net 192.168.0.0/24

[]s, MM

[Dirty]

Então, não sei o que esta acontecendo (mas muito me indica problema no roteador mesmo).

Queria enfatizar que estou fazendo os testes em dois tipos de serviços que recebem (deveriam receber) conexões externas, o SSH que estou usando a porta 60022, e o apache pela porta 8090.

Utilizei o tcpdump como o MMACHADO falou, porem nada aconteceu:

# tcpdump -ni eth0 port 8090 and not net 192.168.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MP (Ethernet), capture size 96 bytes

Nessa hora estava tentando se estabelecer conexão com a porta 8090 de um pc da internet, mas nada aconteceu, deixei rodando também o iptraf para ver os ips que iriam acessar o servidor, e somente os ips internos (da rede) acessavam.

Outra coisa que notei agora fazendo os testes na porta 8090 é que:
No roteador se eu aponto o serviço DMZ para o servidor e tento acessa-lo com o ip externo (porem com um pc da rede) na porta 8090, ele também não funciona (???) com o ip interno funciona, eu retirando o DMZ do servidor, consigo acessar pelo ip externo (do pc da rede), em ambos os modos ips da internet não tem acesso.

Acho que não existe mais soluções (se tiver, por favor ...), creio que o problema é no roteador mesmo.. estou para fazer a aquisição de um switch, vou coloca-lo no lugar do roteador, e vou usar o servidor para fazer o gerenciamento da rede pelo iptables. Espero não ter mais problemas.

Mas mesmo assim, se alguém tiver qualquer idéia de solução para o problema, fico grato.

Abraços.

[mmachado]

Creio ter me equivocado quanto ao comando. Esse faria mais sentido:

# tcpdump -ni eth0 port 8090 and not src net 192.168.0.0/24

De qualquer forma, se você não viu nada externo pelo iptraf, muito provavelmente seu modem não está fazendo esse mapeamento de portas corretamente.

[]s, MM