Como posso obter a resolução IP de DNS para um nome de domínio da Internet apontando para um servidor Web hospedado localmente de dentro de uma LAN (em várias sub-redes)?

1

Vá direto ao assunto:

Uma questão específica é a seguinte: um cliente na rede 10.0.3.X / 24 não pode alcançar subdomain.site.com . Como posso tornar os clientes em 10.0.2.X / 24 e 10.0.3.X / 24 capazes de resolver 10.0.1.4 ao chamar subdomain.site.com ?

Gostaria de ter minha resolução de DNS funcionando para minha LAN de servidor da web usando o nome de domínio do lado da WAN. subdomain.site.com tal que n clientes em qualquer sub-rede LAN pode apenas digitar subdomain.site.com ou site.com e ser roteado de forma apropriada (escalável, portanto /etc/hosts é fora de questão).

Minha LAN tem várias sub-redes criadas com LEDE (rede .1) e OpenWRT (rede .2 e rede .3):

10.0.1.X/24 Main puppy with WAN interface facing internet and NAT, web server fixed at 10.0.1.4 with ports forwarded
10.0.2.X/24 Auxiliary router with WAN interface facing 10.0.1.X/24 (routed)
10.0.3.X/24 Auxiliary router with WAN interface facing 10.0.1.X/24 (routed)

Eu não quero nenhuma solução NAT NAT / loopback em gancho. Eu prefiro uma solução usando DNS e aqui está o porquê:

  1. Uma chamada de saída de um cliente chama o DNS autoritativo para encontrar o IP (para roteamento!) e, em seguida, envia um pacote para esse destino,
  2. que, ao chegar, é enviado para o servidor.
  3. O IP de origem é o endereço local do cliente, portanto, o servidor chama o cliente diretamente (usando o IP de origem do pacote).
  4. O cliente rejeita este pacote porque espera que ele venha do gateway, indiretamente do ramal do gateway. addr. fornecida pelo DNS acima.
  5. Um loopback NAT resolve o problema traduzindo o IP de origem de saída para o addr do lado da LAN do gateway. tal que o
  6. O servidor responde ao gateway, em vez de diretamente ao cliente. Feijão fresco.

O problema com esse fluxo de dados é que não é eficiente deixar a LAN e entrar em contato com um servidor DNS global para um endereço IP. quando o servidor é um peer local (no mesmo lado do NAT e no meu caso não necessariamente dentro da mesma sub-rede local). Por que deixar a LAN quando o cliente e o servidor são pares locais? Uma boa explicação de um fluxo NAT de loopback pode ser encontrada aqui, link .

Eu sei que é possível alcançar o que eu quero usando split-horizons DNS ou qualquer termo que algumas pessoas estão chamando atualmente. Além disso, um servidor de nomes local que tenha precedência sobre os servidores de nomenclatura globais em certas instâncias resolveria isso. Como posso implementar isso em OpenWRT ou LEDE ao usar várias sub-redes (vários servidores DHCP + DNS)? Alguém já deve ter feito isso.

Atualmente, os clientes em 10.0.1.X / 24 podem alcançar subdomain.site.com com uma configuração dnsmasq correspondente /etc/config/dhcp , mas não faço ideia do motivo, porque achei que isso não abrangia subdomínios:

config domain
        option name 'site.com'
        option ip '10.0.1.4' # LAN address of web server
    
por Jonathan Komar 04.01.2018 / 19:51

2 respostas

1

1º elemento ausente

Eu tive que adicionar duas coisas à minha configuração do dnsmasq nos aux routers no arquivo /etc/config/dhcp :

    list server '10.0.1.1'# Clients will still get 10.0.3.1 as dns server
    list rebind_domain 'subdomain.site.com' # Allow rebind to web server

O list server faz o dnsmasq encaminhar as consultas de DNS para o servidor em 10.0.1.1 (o servidor principal do dnsmasq do roteador). O list rebind_domain permite a religação de sites específicos, de modo que a proteção de vinculação de dns pode ser deixada ativada. Obrigado "jow" aqui . Outra opção é desativar completamente a proteção de religamento de dns. Como alternativa, pode ser possível usar option rebind_localhost 1 , mas não testei isso. Sem essa etapa, eu não pude fazer o ping subdomain.site.com .

2º elemento ausente

Adicione a seguinte entrada a /etc/dnsmasq.conf no roteador principal .

address=/.site.com/10.0.1.4

Observe o espaço reservado . para qualquer subdomínio. Essa alteração também pode ser possível em /etc/config/dhcp , mas não sei como.

Original 2º elemento ausente (limitado)

Esta foi a minha solução original, que abandonei desde então. Eu adicionei uma entrada ( 10.0.1.4 subdomain.site.com ) no arquivo /etc/hosts do roteador principal, que tem a limitação de não haver espaços reservados para subdomínios ou URLs estendidos, como ao usar o webdav.

127.0.0.1 localhost

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.1.4 subdomain.site.com

Teste isso adicionando logqueries 1 a /etc/config/dhcp para registrar todas as consultas DNS. Algo como o seguinte será exibido, o que indica que /etc/hosts foi a fonte:

Fri Jan  5 14:11:20 2018 daemon.info dnsmasq[7368]: 73 10.0.3.149/64299 /etc/hosts subdomain.site.com is 10.0.1.4

O que não funcionou

Surpreendeu-me que a seguinte configuração de /etc/config/dhcp no roteador principal só funcionou na 10.0.1.X/24 subnet:

config domain
        option name 'site.com'
        option ip '10.0.1.4'

config domain
        option name 'subdomain.site.com'
        option ip '10.0.1.4'

Se alguém puder esclarecer isso, eu adoraria saber o porquê! Talvez um problema?

Parece que adicionar option dns 10.0.1.1 a /etc/config/network nos roteadores auxiliares também não ajudou muito na minha situação.

config interface 'lan'
        option ifname  'eth0.1'
        option force_link '1'
        option type    'bridge'
        option proto   'static'
        option ipaddr  '10.0.2.1'
        option netmask '255.255.255.0'
        option dns     '10.0.1.1'

config interface 'wan'
        option ifname 'eth0.2' # Comment this out if connecting as sta using wlan
        option proto   'dhcp'
        option netmask '255.255.255.0'
        option gateway '10.0.1.1'
        option dns     '10.0.1.1'

Adicionar essa opção faz uma entrada aparecer em cat /tmp/resolv.conf.auto . No entanto, list server 10.0.1.1 , conforme explicado acima, adiciona nameserver 10.0.1.1 para a interface WAN.

Adicionar dhcp_option s a /etc/config/dhcp nos roteadores auxiliares não ajudou.

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '72h'
        option ra 'server'
        #list 'dhcp_option' '3,10.0.1.1' # SET DEFAULT GATEWAY, CAUTION CAN BREAK STUFF
        #list 'dhcp_option' '6,10.0.1.1' # SEND DNS SERVER ADDR TO CLIENTS, CAUTION CAN BREAK STUFF
    
por 05.01.2018 / 14:05
1

Você precisa dividir o horizonte ou um servidor de nomes local.

Apontar os clientes por trás de 10.0 / 16 em um servidor de nomes local que seja autoritativo para a subdomain.example.com zone e recursiva de outra forma. Isso é possível com um servidor de nomes autônomo ou com horizonte dividido.

Ambos os exemplos abaixo contêm o mínimo para executar suas tarefas. Questões de segurança e outros detalhes de configuração estão fora do escopo desta questão.

Recomendo vivamente a leitura do DNS HOWTO e DNS e BIND , nessa ordem.

Horizonte dividido

view "internal" {
  match-clients { // Add any other "on-net" blocks here.
    localnets;
    127.0.0.1;
  };
  recursion yes;

  zone "example.com" in {
    type master;
    file "internal/example.com"; // Contains RFC1918 addresses for on-net hosts
  };

  zone "." in {
    type hint;
    file "root.cache";
  };
};

view "external" {
  recursion no;
  zone "example.com" in {
    type master;
    file "external/example.com"; // Contains public IPs for hosts
  };
};

Servidor de nomes autônomo

Esta é uma instância BIND normal, mas configurada para ser autoritativa para a zona interna.

options {
  recursion yes;
  // and any other options you want
};

zone "example.com" in {
  type master;
  file "example.com"; // Contains the RFC1918 addresses.
};

zone "." in {
  type hint;
  file "root.cache";
};
    
por 04.01.2018 / 20:03