Encaminhamento de porta ssh do Linux iptables (rejeição marciana)

12

Eu tenho um gateway Linux realizando NAT para minha rede doméstica. Eu tenho outra rede para a qual eu gostaria de encaminhar os pacotes, mas apenas para / de IP / portas específicas (ou seja, não uma VPN). Veja alguns exemplos de IP e portas para trabalhar com:

Source          Router          Remote Gateway     Remote Target
192.168.1.10 -> 192.168.1.1 ->  1.2.3.4        ->  192.168.50.50:5000

Eu gostaria que a máquina de código-fonte pudesse falar com portas específicas no Remote Target como se fosse diretamente roteável do roteador. No roteador, eth0 é a rede privada e eth1 é voltada para a internet. O Remote Gateway é outra máquina Linux que eu posso usar e que pode ser direcionada diretamente para o Remote Target.

Minha tentativa de uma solução simples é configurar o encaminhamento de porta ssh no roteador, como:

ssh -L 5000:192.168.50.50:5000 1.2.3.4

Isso funciona bem para o roteador, que agora pode se conectar localmente à porta 5000. Portanto, "telnet localhost 5000" será conectado a 192.168.50.50:5000 como esperado.

Agora quero redirecionar o tráfego da fonte e canalizar através do túnel ssh, agora estabelecido. Eu tentei uma regra NAT para isso:

iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 127.0.0.1:5000

e como o roteador já é meu gateway NAT, ele já tem a regra de pós-venda necessária:

-A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE

A maioria das perguntas e respostas neste site ou em qualquer outro lugar parece lidar com o encaminhamento de portas de servidor ou NAT em gancho, e eu tenho trabalhado bem em outro lugar, e nenhuma delas se aplica a essa situação. Eu certamente poderia DMZ encaminhar as portas Remote Target através do Remote Gateway, mas eu não quero as portas acessíveis à Internet, eu quero que elas sejam acessíveis apenas através do túnel SSH seguro.

A melhor resposta que posso encontrar está relacionada à rejeição de pacotes marcianos no kernel do Linux:

iptables, como redirecionar a porta do loopback?

Eu habilitei o registro de marcianos e confirmei que o kernel está rejeitando estes pacotes como marcianos. Exceto que eles não são: eu sei exatamente para que servem esses pacotes, de onde são e para onde vão (meu túnel ssh).

A solução "roundabout" apresentada aqui é aplicável a essa pergunta original, mas não se aplica ao meu caso.

No entanto, ao escrever / pesquisar essa questão, resolvi meu problema usando a ligação de IP de origem SSH da seguinte forma:

ssh -L 192.168.1.1:5000:192.168.50.50:5000 1.2.3.4
iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 192.168.1.1:5000

Desde que eu não estou usando loopback, isso contorna a rejeição marciana.

Ainda coloco a questão aqui por dois motivos:

  1. Espero que alguém que tente fazer algo semelhante no futuro encontre isso em suas pesquisas e essa solução alternativa possa ajudá-lo.
  2. Eu ainda prefiro a idéia de manter minha porta ssh encaminhando conexões limitadas apenas para loopback e ser capaz de rotear para elas através do iptables. Como eu sei exatamente quais são esses pacotes e para onde eles estão indo, não deveria haver alguma maneira de eu sinalizá-los para que a filtragem do Linux não os rejeite? Toda a minha busca neste tópico leva ao rp_filter, o que não ajudou em nada nos testes. E mesmo que funcionasse, não é específico para os pacotes exatos que estou tentando permitir.

ps. Originalmente postado para serverfault , como é onde eu encontrei várias respostas relacionadas quando tentando resolver este problema. Inicialmente eu supus serverfault era tudo coisas Unix / Linux e não percebi que havia um Exchange separado, mas de acordo com essa meta , essa troca talvez seja mais adequada para essa pergunta. Estou interessado em contribuir com minha pergunta e solução para a pesquisa geral para salvar alguém as horas de pesquisa que fiz apenas para chegar a becos sem saída, bem como espero ter alguém responder a parte de loopback / marciano da minha pergunta que ainda permanece aberta para mim.

    
por Mark 23.11.2015 / 14:43

2 respostas

1

O problema de fazer um DNAT para 127.0.0.1:5000 é que, quando o lado remoto responde, esses pacotes retornam ao mecanismo de roteamento como se fossem originados localmente (de 127.0.0.1), mas têm um endereço de destino externo. SNAT / MASQUERADE correspondendo à interface externa os teria capturado e reescrito, mas as decisões de roteamento que precisam ser feitas para que os pacotes cheguem a essa interface vêm em primeiro lugar, e eles desautorizam esses pacotes que são falsos por padrão. O mecanismo de roteamento não garante que você se lembre de reescrever depois.

O que você deve ser capaz de fazer é rejeitar qualquer conexão externa com 192.168.1.1:5000 no iptables INPUT, exceto as que vêm de 192.168.1.10 usando o argumento ! antes da especificação do endereço de origem -s . Se você usar a redefinição TCP como o mecanismo de rejeição ( -j REJECT --reject-with tcp-reset , em vez do destino ICMP padrão inalcançável), ela será praticamente idêntica à situação em que nada estava escutando nesse endereço: combinação de portas no mundo externo .

    
por 27.05.2016 / 22:37
0

Eu usaria o openVPN para criar um túnel do roteador para o RemoteGateway.

Então, no Roteador, adiciono uma rota:

rota adicionar -host RemoteTarget gw RemoteGateway-VPNaddress

use uma regra simples do iptables onde você quiser limitar as portas que você permite que o Source chegue.

    
por 30.08.2016 / 06:54