Eu tenho um gateway Linux executando NAT para minha rede doméstica. Eu tenho outra rede para a qual gostaria de encaminhar pacotes de forma transparente, mas apenas para / de IP / portas específicas (ou seja, não uma VPN). Aqui estão alguns exemplos de IP e portas para trabalhar:
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 origem pudesse falar com portas específicas no destino remoto como se fosse diretamente roteável do roteador. No roteador, eth0 é a rede privada e eth1 é voltado para a Internet. O Gateway Remoto é outra máquina Linux na qual eu posso ssh e pode rotear diretamente para o Destino Remoto.
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, o "telnet localhost 5000" será conectado a 192.168.50.50:5000 conforme o esperado.
Agora, quero redirecionar o tráfego da Origem e funil 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á possui a regra de pós-roteamento necessária:
-A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE
A maioria das perguntas e respostas neste site ou em outro lugar parece lidar com portas de servidor de encaminhamento ou NAT hairpin, ambas as quais estou funcionando bem em outros lugares, e nenhuma delas se aplica a essa situação. Eu certamente poderia a DMZ encaminhar portas de Destino Remoto através do Gateway Remoto, mas não quero que as portas estejam acessíveis pela Internet, quero que elas sejam acessíveis apenas através do túnel SSH seguro.
A melhor resposta que posso encontrar diz respeito à rejeição de pacotes marcianos no kernel do Linux:
iptables, como redirecionar a porta do loopback?
Ativei o log de marcianos e confirmei que o kernel está rejeitando esses pacotes como marcianos. Exceto que eles não são: eu sei exatamente para que servem esses pacotes, de onde eles são e para onde estão indo (meu túnel ssh).
A solução "indireta" apresentada lá é aplicável a essa pergunta original, mas não se aplica ao meu caso.
No entanto, enquanto escrevia / pesquisava essa pergunta, resolvi meu problema usando a ligação IP de origem SSH da seguinte maneira:
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
Como não estou usando loopback, isso contorna a rejeição marciana.
Eu ainda posto a pergunta aqui por dois motivos:
- Na esperança de que alguém que esteja tentando fazer algo semelhante no futuro possa encontrar isso em suas pesquisas e essa solução alternativa possa ajudá-los.
- Eu ainda prefiro a idéia de manter minha conexão ssh de encaminhamento de porta vinculada apenas ao loopback e poder rotear para eles através do iptables. Como eu sei exatamente o que esses pacotes são e para onde eles estão indo, não deveria haver alguma maneira de sinalizá-los dessa maneira para que a filtragem marciana do Linux não os rejeite? Toda a minha pesquisa neste tópico leva ao rp_filter, que não ajudou em nada nos meus testes. E mesmo que funcionasse, não é específico dos pacotes exatos que estou tentando permitir.
Estou interessado em contribuir com minha pergunta e solução alternativa para a pesquisa geral, a fim de economizar para outras pessoas as horas de pesquisa que fiz apenas para chegar a becos sem saída, além de esperar que alguém responda à parte de loopback / marciano da minha pergunta que ainda permanece aberta para mim.
fonte
Respostas:
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 tivessem origem local (a partir de 127.0.0.1), mas eles tinham um endereço de destino externo. O SNAT / MASQUERADE que correspondesse à interface externa os teria capturado e reescrito, mas as decisões de roteamento que devem ser tomadas para que os pacotes cheguem a essa interface são as primeiras, e eles não permitem esses pacotes que são falsos por padrão. O mecanismo de roteamento não garante que você se lembre de reescrever mais tarde.
Em vez disso, você deve poder rejeitar quaisquer conexões externas para 192.168.1.1:5000 no iptables INPUT, exceto aquelas provenientes de 192.168.1.10, usando o
!argumento antes da-sespecificação do endereço de origem. Se você usar a redefinição do TCP como mecanismo de rejeição (em-j REJECT --reject-with tcp-resetvez do destino padrão do ICMP inacessível), será amplamente idêntico à situação em que nada estava ouvindo naquele endereço: combinação de portas no que diz respeito ao mundo externo.fonte
Eu usaria o openVPN para criar um túnel do roteador para o RemoteGateway.
Então, no roteador, adicionaria uma rota:
rota adicionar -host RemoteTarget gw RemoteGateway-VPNaddress
use a regra simples do iptables onde quiser limitar as portas que você permite que o Source acesse.
fonte