Acessando o servidor web DNAT de dentro da LAN

Question

Eu tenho uma pequena rede com um roteador, que mantém uma conexão com a Internet, um servidor e algumas estações de trabalho em uma rede local.

OservidordeveseracessadodaInternet,eexistemváriasentradasDNATconfiguradasnoroteadoriptables,destaforma:

-APREROUTING-ippp0-ptcp-mmultiport--dports22,25,80,443-jDNAT--to-destination192.168.2.10

Ospacotesexternoschegamaoroteadoratravésdainterfaceppp0,eospacotesinternosvãodobr-lan,quenaverdadeincluioswitcheoadaptadorWLAN.Oproblemaéque,enquantooacessoexternofuncionabem,tentandoacessaroservidordedentrodaLAN,umIPexternoresolvidopeloDNS(atribuídoappp0)falha.

Aúnicasoluçãoqueconseguiinventaréadicionarentradasestáticasao/etc/hostsdoroteadorapontandoparaoIPinterno,mascomonãohácuringas(etenhopelomenostrêsdomíniosdenívelsuperioratribuídosaessesistema,nãocontandodezenasdesubdomínios),queébastantecrocanteepropensoafalhas.Vocêpodesugeriralgomelhor?

Eusóencontreiesta pergunta , que não foi muito útil.

Se isso for relevante, o roteador executa o OpenWRT 10.03 Kamikaze com dnsmasq.

    

Answer 1

Surpreende-me que, após quase 8 anos, ninguém tenha explicado como fazer isso da maneira correta usando o sistema de configuração UCI usado por padrão no OpenWRT.

A resposta de Steven Monday está correta, mas está usando diretamente os comandos iptables , que é uma camada inferior ao sistema de configuração UCI, e é melhor deixar intocada pela maioria dos usuários do OpenWRT, se possível.

A maneira correta de acessar servidores internos por meio de seus combos públicos de IP / porta de outro host interno na UCI é ativando a opção de configuração reflection em cada destino DNAT específico no arquivo /etc/config/firewall . Esse comportamento está documentado aqui .

Por exemplo:

config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option src_dport '44322' option dest_ip '192.168.5.22' option dest_port '443' option name 'apache HTTPS server' option reflection '1'

Nota:  De acordo com a documentação indicada do OpenWRT, reflection está habilitado por padrão. Nos meus testes, este não foi o caso.

    

Answer 2

Eu deletei minha resposta original porque não tinha certeza de que estava correta. Desde então, tive algum tempo para configurar uma pequena rede virtual de VMs para simular a rede em questão. Aqui está o conjunto de regras de firewall que funcionou para mim (em iptables-save format, apenas para a tabela nat ):

-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE

A primeira regra POSTROUTING é uma maneira direta de compartilhar a conexão à Internet com a LAN. Eu deixei por completo.

A regra PREROUTING e a segunda regra POSTROUTING estabelecem os NATs apropriados, de modo que as conexões com o servidor através do endereço IP externo podem acontecer, independentemente de as conexões serem originadas de fora ou de dentro da LAN. Quando os clientes na LAN se conectam ao servidor através do endereço IP externo, o servidor vê as conexões como provenientes do endereço IP interno do roteador (192.168.2.1).

Curiosamente, há algumas variações da segunda regra POSTROUTING que também funciona. Se o destino for alterado para -j SNAT --to-source 192.168.2.1 , o efeito é (não surpreendentemente) o mesmo que o MASQUERADE : o servidor vê conexões de clientes locais da LAN como originárias do endereço IP interno do roteador. Por outro lado, se o destino for alterado para -j SNAT --to-source 89.179.245.232 , os NATs ainda funcionarão, mas, desta vez, o servidor vê as conexões dos clientes locais da LAN como originárias do endereço IP externo do roteador (89.179. 245.232).

Por fim, observe que a regra original PREROUTING / DNAT com -i ppp0 não funciona, porque a regra nunca corresponde aos pacotes provenientes dos clientes da LAN (já que eles não entram no roteador via ppp0 interface). Seria possível fazê-lo funcionar adicionando uma segunda regra PREROUTING apenas para os clientes LAN internos, mas seria deselegante (IMO) e ainda precisaria se referir explicitamente ao endereço IP externo.

Agora, mesmo depois de ter descrito detalhadamente uma solução "hairpin NAT" (ou "NAT loopback", ou "NAT reflection", ou qualquer que seja a sua preferência para chamá-la), ainda acredito que um DNS de split-horizon solução --- com clientes externos resolvendo para o IP externo e clientes internos resolvendo para o IP interno --- seria o caminho mais aconselhável para tomar. Por quê? Porque mais pessoas entendem como o DNS funciona do que entender como o NAT funciona, e uma grande parte da construção de bons sistemas é escolher usar partes que sejam passíveis de manutenção. É mais provável que uma configuração de DNS seja entendida e, portanto, mantida corretamente, do que uma configuração NAT arcana (IMO, claro).

    

Answer 3

Uma solução comum é apontar seus hosts internos em um servidor DNS local que retorne o endereço "interno" correto para esses nomes de host.

Outra solução - e estamos usando isso onde eu trabalho em nossos firewalls da Cisco - é reescrever as respostas de DNS no firewall que correspondem a esses endereços. Eu não acho que existem ferramentas para o Linux que fazem isso agora.

Você deve ser capaz de configurar o roteamento em seu gateway para fazer a coisa certa. Você pode precisar configurar os servidores para estar ciente de seu endereço IP mapeado externamente (por exemplo, atribuindo-o a uma interface fictícia). Com essa configuração, a comunicação de um sistema interno para outro sistema interno - usando seu endereço "externo" - passaria pelo roteador.

    

Answer 4

O que você está pedindo para fazer é chamado NAT Loopback e requer que você adicione uma regra SNAT para que os pacotes originados de sua LAN para o seu Servidor retornem através do roteador:

-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232

    

Answer 5

comentários de larsks sobre hospedagem de uma versão interna do namespace \ domain geralmente são a maneira como lidamos com esse problema no passado. Claro, você precisa de um servidor DNS internamente para fazer isso.

    

Answer 6

Você deseja usar o dnsmasq para substituir a entrada DNS real do servidor para usar o endereço IP INTERNO.

Se o seu servidor for www.example.com e o seu endereço IP for 1.2.3.4, a partir do EXTERIOR, deverá ter a seguinte aparência:

Name:    www.example.com
Address:  1.2.3.4

Mas no INTERIOR da sua rede, você precisa de www.example.com para apontar para 192.168.2.10, de modo que você possa acessar usando o mesmo nome que faria do lado de fora, para que o nslookup retorne isso na sua LAN:

Name:    www.example.com
Address:  192.168.2.10

Por que esses pacotes "deixam" sua LAN para voltar? Eu nunca tive muito sucesso em fazer isso. Mas, ao mesmo tempo, eu nunca tive uma razão para fazer isso também. Eu vi essa mesma operação feita em muitas outras configurações, como com firewalls Endian, ou uma rede maior e mais complexa, escondida atrás de dispositivos Cisco ASA, bem como uma variedade de servidores DNS diferentes.

Desde que a Internet saiba como chegar ao seu servidor e seus hosts internos saibam como chegar ao seu servidor (por meio da substituição das entradas de DNS nos servidores DNS locais), isso é o mais importante.