Executando o servidor DNS para contornar o problema de loopback de NAT

Primeiro, quero dizer que provavelmente li tudo o que existe na internet sobre o problema.

E o problema é que não consigo acessar meu próprio nuvem sobre doc.selfhost.eu se estou na mesma rede. Mas eu posso acessá-lo de dentro da rede através do seu IP interno (192.168.2.200) e de fora da rede sobre doc.selfhost.eu.

Minha configuração: Um servidor doméstico rodando o Linux Mint 17.2 Cinnamon, que deveria ser para a mídia e rodar o owncloud.

O servidor está conectado a um Speedport 723v que não suporta loopback de NAT. Portas 80 e 443 são encaminhadas e para DNS dinâmico eu tenho uma conta no selfhost.de que eu inseri nas configurações do roteador.

Na minha máquina com Windows 7 (da qual estou tentando acessar o servidor) entrei no 192.168.2.200 (o IP interno dos servidores) como DNS.

Em Mint, desativei o gerenciador de rede (na verdade, removi-o) e agora estou usando interfaces.

Não é uma solução para alterar os arquivos hosts de todos os clientes (em andróides não enraizados isso nem é possível).

Questão:

1. O que eu teria que mudar para acessar meu owncloud da rede interna através do IP externo?

/ etc / network / interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.2.200
netmask 255.255.255.0
gateway 192.168.2.1
dns-nameservers doc.selfhost.eu 8.8.8.8

/etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

Em /etc/dnsmasq.conf esta é a única coisa que eu adicionei:

listen-address=127.0.0.1
listen-address=192.168.2.200
address=/doc.selfhost.eu/192.168.2.200

/etc/dnsmasq.d/doc.selfhost.eu (leia em algum lugar para criar isso)

address=/doc.selfhost.eu/192.168.2.200

/ etc / hosts

127.0.0.1       localhost
127.0.1.1       doc-desktop
192.168.2.200   doc.selfhost.eu

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Configurações Owncloud em /var/www/owncloud/config/config.php

'trusted_domains' =>
  array (
0 => '192.168.2.200',
1 => 'doc.selfhost.eu',
  );

Configuração do Apache Em /etc/apache2/apache2.conf tudo é bastante normal. Eu só adicionei:

ServerName doc-desktop

/etc/apache2/sites-enabled/owncloud.conf . Nenhuma mudança no sites disponíveis sem ligação.

<VirtualHost 192.168.2.200:80>

#### Redirect to port 443 ###
RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
#### End of Redirection configuration ###

DocumentRoot /var/www/owncloud/
<Directory /var/www/owncloud>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Require all granted
</Directory>

</VirtualHost>

<VirtualHost 192.168.2.200:443>
####Configuration for SSL #####
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
#### End of SSL Configuration ####
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
DocumentRoot /var/www/owncloud/
<Directory /var/www/owncloud>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Require all granted
</Directory>
</VirtualHost>

Caso isso aconteça. do servidor:

dig doc.selfhost.eu

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> doc.selfhost.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49046
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;doc.selfhost.eu.          IN      A

;; ANSWER SECTION:
doc.selfhost.eu.   0       IN      A       192.168.2.200

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 26 02:35:15 CET 2015
;; MSG SIZE  rcvd: 54

Do cliente dentro da rede (com cygwin):

dig doc.selfhost.eu

; <<>> DiG 9.10.3 <<>> doc.selfhost.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29482
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;doc.selfhost.eu.          IN      A

;; ANSWER SECTION:
doc.selfhost.eu.   0       IN      A       192.168.2.200

;; Query time: 31 msec
;; SERVER: 192.168.2.200#53(192.168.2.200)
;; WHEN: Mon Oct 26 02:37:32     2015
;; MSG SIZE  rcvd: 54

Eu espero que isso seja tudo. Obrigado.

Esta questão vem daqui desde que foi off-topic:

https://stackoverflow.com/questions/33337258/running-dns-server-to-circumvent-nat-loopback-issue

Soluções Externas

O que eu teria que mudar para acessar meu owncloud da rede interna através do IP externo?

Infelizmente, nunca ter encontrado pessoalmente um roteador doméstico que não suportasse o loopback NAT (também conhecido como hairpinning ), Eu não posso fornecer uma resposta concreta sobre como acessá-lo com qualquer coisa externo .

Outras soluções

• Você pode querer olhar mais para DNS de horizonte dividido ou usando PFSense NAT Reflection como sugerido em esta pergunta de superusuário .

• Você também pode querer olhar para isto lista suportada de roteadores suportados por Loopback NAT de OpenSimulator.org se você decidir comprar um novo.

• Também pode ser possível atualizar para um firmware personalizado, por ex. Tomate ou DD-WRT, mas eu investigaria este processo completamente antes de tentar qualquer coisa.

Uma solução baseada em DNS

Assumindo que sua meta não é mais complicada do que acessar seu servidor de mídia a partir da rede interna com um domínio legível e você está disposto a configurar o DNS BIND, você pode tentar fazer uma pseudo-domínio disponível para a sua rede também.

Este pseudo-domínio potencialmente permitiria que você acessasse seu servidor local em algo como server.own na rede interna. Este falso Domínio de nível superior (TLD) ex . .own essencialmente pode ser qualquer coisa que você quiser.

Eu suspeito que isso deve funcionar mesmo com o problema de loopback de NAT.

Usando um pseudo-domínio

O arranjo mais simples é ter um computador na rede fornecendo DNS. Os maiores inconvenientes potenciais para este arranjo são:

• Você provavelmente precisará certificar-se de que seu roteador está apontando para o servidor que executa o BIND.

• O computador servindo como seu servidor DNS precisará estar ativado para que isso (e sua conexão de rede) funcione.

Além disso, embora provavelmente menos importante neste caso, executar um serviço BIND que forneça acesso a redes internas e externas pode ser um pouco arriscado. Geralmente, você deveria não imitar um TLD público gostar .eu a menos que você saiba o que está fazendo. Se você quiser manter o doc.selfhost prefixo ao invés de outra coisa, tudo bem, mas você deve escolher um diferente sem uso extensão (por ex. doc.selfhost.own ).

Apache e Owncloud

Uma vez ativado, você precisará configurar o Apache (seu pseudo-domínio provavelmente será um VirtualHost) e Owncloud para responder adequadamente às consultas e servir o conteúdo apropriado (por exemplo, Owncloud).

Exemplos de trabalho

Abaixo estão alguns exemplos de como configurar os arquivos principais no BIND para fornecer serviços de pseudo-domínio.

Note que eu sou não cobrindo tudo o que você precisa fazer para que o próprio BIND funcione, então pode haver algumas etapas extras não mencionadas explicitamente aqui. Observe também que esses exemplos são tecnicamente para versões recentes de BIND 9 no Windows (BIND 9.10+).

O conteúdo real de db.rev.10.txt e db.example.own.txt não deve precisar de modificação entre o Windows e o * nix. O maior obstáculo é garantir que o named.conf entradas aparecem nos arquivos corretos em plataformas não-Windows e que db.rev.10.txt e db.example.own.txt aparecem nos diretórios * nix corretos.

Referência para o Ubuntu: Sete etapas fáceis para configurar um servidor DNS interno no Ubuntu

Note que ao usar distros baseadas em Redhat, existem diferenças sutis entre eles e Debian / Ubuntu / Mint.

Assumindo que você está bem com tudo isso, aqui estão os exemplos básicos de trabalho. Esta é essencialmente uma configuração de DNS em cache, se for importante.

1. Obtenha o BIND configurado e funcionando. Eu vou esperar. =)

2. named.conf - Editar named.conf. (aproximadamente) como dado abaixo. No Windows, todas as entradas estão em "named.conf" (localizado no diretório "etc" do BIND). No moderno * nix, essas entradas geralmente são divididas em vários arquivos. Além disso, certifique-se de incluir qualquer entrada "chave rndc" e "controle" conforme necessário.

   ex. named.conf

   # Our basic options -- where do we find our zone files, etc.?
   # On *nix, options likely need to go in "named.conf.options"
   
   options {
       directory "Path\to\zones";      # On *nix it's / not \ of course
       allow-transfer { none; };       # disable zone transfers by default
   
       # We restrict access to recursion to avoid security issues, etc.
       # You can change IPs as required.
       #allow-recursion {192.168.1.0/24;}; 
   
       # "localnets" is a special ACL in BIND
       allow-recursion {"localnets";};
   
       # We are using named.root, so forwarders are disabled.
       # forwarders { 8.8.8.8; 8.8.4.4; };
   };
   
   # Current versions of named.root/db.cache -- ftp://ftp.internic.net/domain/
   # *nix likely uses named.root (Redhat/Fedora) or db.cache (Deb/Ubu/Mint) 
   # This file does need periodic updating (perhaps twice a year)
   
   zone "." {
       type hint;
       file "named.root";      # On Windows, place in your BIND "zone" directory
   };
   
   # Local domain where "example.own" is whatever domain you want
   # On *nix, these zone definitions likely need to go in "named.conf.local"
   
   zone "example.own" IN {
       type master;
       file "db.example.own.txt";   # On Windows, place in your BIND "zone" directory
       allow-transfer { none; };
   }; 
   
   # Local loopback interface so our local domains work
   # The digits are the local lan prefix in reverse
   # Note that /16 subnets use only two digits e.g. 128.10 for 10.128.xxx.xxx
   
   zone "0.0.10.in-addr.arpa" IN {
         type master;
         file "db.rev.10.txt";     # On Windows, place in your BIND "zone" directory
         allow-transfer { none; };
   };
   
   # ### Any "rndc-key" and "control" statements go here ### 
   
   # End of named.conf
   

3. db.rev.10.txt - Nosso arquivo de zona reversa. Adicione registros PTR para cada servidor físico mencionado em seu arquivo de zona de encaminhamento (por exemplo, db.example.own.txt ). Neste exemplo, estamos assumindo como servidor de mídia único em 10.0.0.3 nós queremos ligar example.own.

   ex. db.rev.10.txt

   ; BIND reverse data file for a local loopback interface
   ; The domain used should be a listed 'zone' in named.conf 
   
   $TTL 86400                ; Default TTL
   @   IN SOA  example.own.    admin.example.own. (
                2015071301      ; serial
                10800           ; Refresh period
                3600            ; Retry interval
                604800          ; Expire time
                86400 )         ; Negative caching TTL
   
   ; The number before PTR is the last octet of the IP address
   ; for the device to map (e.g. 10.0.0.3). For /16 subnets,
   ; this is the last two digits e.g. "8.9" for "128.10.in-addr.arpa" (10.128.9.8)
   
       IN  NS  ns1.example.own.
       IN  NS  ns2.example.own.
   3   IN  PTR example.own.
   

4. db.example.own.txt - Nosso arquivo de zona de encaminhamento. Neste exemplo, estamos assumindo como servidor de mídia único em 10.0.0.3 nós queremos ligar example.own. Você também pode adicionar MX e CNAMEs, é claro. Se você adicionar servidores adicionais (por exemplo, media IN A 10.0.0.4 ), adicione também o registro PTR apropriado à sua zona reversa (por exemplo, db.rev.10.txt → 4 IN PTR media.example.own )

   ex. db.example.own.txt

   ; We are using our reverse DNS to provide name server services
   ; Enables use of http://(www).example.own on our local network
   
   $TTL 86400              ; Default TTL
   @   IN SOA  ns1.example.own.    admin.example.own. (
               2015071322  ; serial
               10800       ; Refresh period
               3600        ; Retry interval
               604800      ; Expire time
               86400 )     ; Negative caching TTL
   
   @       NS  ns1.example.own.
   
   ns1             IN A        10.0.0.3        ; This entry is ABSOLUTELY NECESSARY - Use an IP
   ns2             IN A        10.0.0.3        ; Secondary Name Server Prefix/IP (Required 2nd Name Server - backup - IP or domain)
   
   example.own.    IN A        10.0.0.3        ; A Record for the basic domain name
   www             IN A        10.0.0.3        ; A Record for the www prefix
   

Miudezas

• Certifique-se de atualizar o Serial em ambas as zonas, frente e verso, sempre que fizer alterações nelas.

• Da mesma forma, certifique-se de "recarregar" bind depois de fazer qualquer alteração em seus arquivos de configuração BIND. Como um pensamento geral, você provavelmente vai querer voltar todos os originais bem antes de mexer.

• Supondo que tudo esteja configurado corretamente, todos os dispositivos compatíveis (incluindo o Android) na rede devemos ser capaz de acessar example.own sem configuração adicional (ou seja, como a rede regular).

• Observe que, se você estiver usando o Google Chrome, precisará anexar uma barra à direita na barra de endereço (por exemplo, example.own/ ), caso contrário, você pode ser redirecionado para a pesquisa do Google. Este requisito provavelmente não será alterado em nenhuma versão futura .

• Enquanto para configurações mais tradicionais, esses dois artigos para Ubuntu e Centos 7 (Redhat) ilustram algumas das diferenças na configuração do BIND entre os dois.

Eu tenho lutado com esse problema no mês passado desde a compra de um novíssimo roteador Linksys WRT1200AC de US $ 180. Eu também tenho uma conta IP dinâmica que me permite acessar minha rede doméstica da estrada. Eu fiz uma tonelada de pesquisa, como você fez. Mas algo tão simples como garantir que meus sites estejam on-line agora é impossível. Eu até criei um servidor proxy Python na nuvem do Google para poder ver esses sites; no entanto, eventualmente, parou de funcionar por algum motivo desconhecido.

Meu ambiente é o Windows, mas o problema é idêntico. Meu conselho sincero é simplesmente comprar um novo roteador e poupar muita frustração e miséria. Agora estou comprando uma, mas está provado que é muito difícil encontrar um novo roteador que suporte loopback de NAT. Eu não descobri uma maneira de contornar este problema de outra forma. Boa sorte.

Eu não estou muito certo, para entender todos os aspectos disso e eu tropecei aqui mais acidentalmente. Para minha própria infra-estrutura, resolvi isso usando as regras do iptables para redirecionar as solicitações intrenais para os servidores internos - mas estou usando uma máquina linux como meu firewall. De qualquer forma parece útil ler este link: Acessando um DNAT sever da LAN local usando o endereço IP público