Acesso remoto à máquina interna (encaminhamento de porta ssh)

Question

Eu tenho um servidor (serv05) no trabalho com um ip público, hospedando dois convidados KVM - vtest1 & vtest2 - em duas redes privadas diferentes - 192.168.122.0 & 192.168.100.0 - respectivamente, desta forma:

[root@serv05 ~]# ip -o addr show | grep -w inet
1: lo    inet 127.0.0.1/8 scope host lo
2: eth0    inet xxx.xxx.xx.197/24 brd xxx.xxx.xx.255 scope global eth0
4: virbr1    inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1
6: virbr0    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
#
[root@serv05 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr1
xxx.xxx.xx.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         xxx.xxx.xx.62   0.0.0.0         UG    0      0        0 eth0

Eu também configurei o IP FORWARDing e o Masquerading dessa maneira:

iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface virbr0 -j ACCEPT

Tudo funciona até este ponto. Se eu quiser acesso remoto vtest1 (ou vtest2) primeiro eu ssh para serv05 e, em seguida, de lá ssh para vtest1. Existe uma maneira de configurar um encaminhamento de porta para que vtest1 possa ser acessado diretamente do mundo externo? Isso é o que eu provavelmente preciso configurar:

 external_ip (tcp port 4444) -> DNAT -> 192.168.122.50 (tcp port 22)

Eu sei que é facilmente factível usando um roteador SOHO, mas não consigo descobrir como posso fazer isso em uma caixa Linux.

Atualização: 1

Agora fiz o ssh para ouvir as duas portas:

[root@serv05 ssh]# netstat -tulpn | grep ssh
tcp        0      0 xxx.xxx.xx.197:22           0.0.0.0:*         LISTEN     5092/sshd
tcp        0      0 xxx.xxx.xx.197:4444         0.0.0.0:*         LISTEN     5092/sshd

e o port 4444 é permitido nas regras do iptables:

[root@serv05 sysconfig]# grep 4444 iptables
-A PREROUTING -i eth0 -p tcp -m tcp --dport 4444 -j DNAT --to-destination 192.168.122.50:22 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 4444 -j ACCEPT 
-A FORWARD -i eth0 -p tcp -m tcp --dport 4444 -j ACCEPT 

Mas estou recebendo conexão recusada :

maci:~ santa$ telnet serv05 4444
Trying xxx.xxx.xx.197...
telnet: connect to address xxx.xxx.xx.197: Connection refused
telnet: Unable to connect to remote host

Alguma idéia do que eu ainda estou sentindo falta?

Atualização: 2

Eu removi a terceira interface, virbr1 , do iptables, apenas reduza a saída.

[root@serv05 sysconfig]# iptables -vL -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:67
  108  8112 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  189 42273 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.0/24      0.0.0.0/0           state NEW tcp dpt:21
    0     0 ACCEPT     tcp  --  *      *       192.168.122.0/24     0.0.0.0/0           state NEW tcp dpt:21
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:4444
    0     0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.0/24      0.0.0.0/0           state NEW tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       192.168.122.0/24     0.0.0.0/0           state NEW tcp dpt:80
    2    64 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24    state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4444

Chain OUTPUT (policy ACCEPT 57 packets, 11124 bytes)
 pkts bytes target     prot opt in     out     source               destination

A mesma coisa está aqui também, virbr1 é intencionalmente removido da saída.

[root@serv05 sysconfig]# iptables -t nat -vL -n
Chain PREROUTING (policy ACCEPT 611 packets, 105K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4444 to:192.168.122.50:22 

Chain POSTROUTING (policy ACCEPT 4 packets, 344 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535 
    0     0 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535 
    0     0 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24    
    0     0 MASQUERADE  tcp  --  *      *       192.168.100.0/24    !192.168.100.0/24    masq ports: 1024-65535 
    0     0 MASQUERADE  udp  --  *      *       192.168.100.0/24    !192.168.100.0/24    masq ports: 1024-65535 
    0     0 MASQUERADE  all  --  *      *       192.168.100.0/24    !192.168.100.0/24    

Chain OUTPUT (policy ACCEPT 4 packets, 344 bytes)
 pkts bytes target     prot opt in     out     source               destination  

Atualização: 3

O SSH não está mais atendendo à porta 4444:

[root@serv05 sysconfig]# netstat -tulpn | grep ssh
tcp        0      0 xxx.xxx.xx.197:22         0.0.0.0:*      LISTEN      15231/sshd

A ordem FORWARD é corrigida:

[root@serv05 sysconfig]# iptables -vL -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
[ .... ]

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24    state RELATED,ESTABLISHED 
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0                     
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4444 
    1    64 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 5 packets, 612 bytes)
 pkts bytes target     prot opt in     out     source               destination         

mas continua a recusar a ligação:

maci:~ santa$ telnet serv05 4444
Trying xxx.xxx.xx.197...
telnet: connect to address xxx.xxx.xx.197: Connection refused
telnet: Unable to connect to remote host

Existe alguma outra área cinza para cobrir?

    

Answer 1

Você precisa de uma regra de NAT (para direcionar o tráfego) e uma regra de firewall regular (para permitir isso).

O primeiro será parecido com

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 4444 -j DNAT --to-destination 192.168.122.50:22

O último será parecido com

iptables -A FORWARD -i eth0 -p tcp --dport 4444 -j ACCEPT

Cabe a você garantir que eles cheguem no ponto certo em suas correntes PREROUTING e FORWARD e, além disso, você pode precisar de uma segunda regra de firewall para permitir a metade dessas conexões, se você ainda não tem um pacote geral ACCEPT para ESTABLISHED .

Editar : a ordem das suas regras é extremamente importante. A regra certa no lugar errado não será boa. Você poderia substituir a saída do grep acima pelo resultado de iptables -L -n -v e iptables -t nat -L -n -v ? E se você quiser que a porta 4444 seja encaminhada, não execute um sshd local também ligado a essa porta.

Editar 2 : e esse é o seu problema. O ACCEPT que você adicionou na cadeia FORWARD é a linha 7, mas a linha 4 já negou explicitamente todo o tráfego não permitido anteriormente de todos os lugares ( * ) para virbr0 . Você precisa fazer arranjos para a linha que você adicionou para vir antes da linha 4, talvez adicionando a regra com

iptables -I FORWARD 4 -i eth0 -p tcp --dport 4444 -j ACCEPT

que irá inseri-lo na linha 4, deslocando a linha atual 4 para a linha 5 (e assim por diante).

Com relação ao sshd atual, quero dizer o que eu disse: que você não deve ter um daemon ligado à porta 4444 se estiver tentando encaminhar essa porta. Eu não ligo para as outras portas, apenas 4444 é uma má idéia.

Editar 3 : a máquina da qual você está testando isso está completamente fora do sistema serv05, sim? E (depois de um dia muito desgastante colocando o Fedora 16 em várias caixas) eu temo que você esteja certo, você poderia colocar uma regra comparável de ACCEPT para 4444 na cadeia INPUT também, tomando cuidado para obtê-lo antes alguma REJECTs?