Ausführen des DNS-Servers zum Umgehen des NAT-Loopback-Problems

2061
doc

Zuerst möchte ich sagen, dass ich wahrscheinlich alles gelesen habe, was es im Internet gibt.

Und das Problem ist, dass ich nicht über doc.selfhost.eu auf meine owncloud zugreifen kann, wenn ich im selben Netzwerk bin. Ich kann jedoch von innerhalb des Netzwerks über die interne IP (192.168.2.200) und von außerhalb des Netzwerks über doc.selfhost.eu darauf zugreifen.

Mein Setup: Ein Home-Server mit Linux Mint 17.2 Cinnamon, der für Medien gedacht ist und ownCloud ausführen soll.

Der Server ist mit einem Speedport 723v verbunden, der NAT Loopback nicht unterstützt. Die Ports 80 und 443 werden weitergeleitet und für dynamisches DNS habe ich einen Account auf selfhost.de, den ich in den Router-Einstellungen eingetragen habe.

Auf meinem Windows 7-Rechner (von dem ich versuche, auf den Server zuzugreifen), habe ich 192.168.2.200 (die interne IP des Servers) als DNS eingegeben.

In Mint habe ich den Netzwerkmanager deaktiviert (tatsächlich habe ich ihn entfernt) und benutze jetzt Schnittstellen.

Es wäre keine Lösung, die Hosts-Dateien aller Clients zu ändern (bei ungereiften Androiden ist dies gar nicht möglich).

Frage:

  1. Was muss ich ändern, um über das externe Netzwerk auf meine owncloud vom internen Netzwerk aus zuzugreifen?

/ etc / network / schnittstellen

# 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 

In /etc/dnsmasq.conf ist dies das einzige, was ich hinzugefügt habe:

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 (irgendwo lesen, um dies zu erstellen)

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 

Owncloud-Einstellungen in /var/www/owncloud/config/config.php

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

Apache-Konfiguration In /etc/apache2/apache2.conf ist alles ziemlich normal . Ich habe nur hinzugefügt:

ServerName doc-desktop 

/etc/apache2/sites-enabled/owncloud.conf . Keine Änderungen in den Websites verfügbar, keine Verknüpfung.

<VirtualHost 192.168.2.200:80>  #### Redirect to port 443 ### RewriteEngine on ReWriteCond % !^443$ RewriteRule ^/(.*) https://%/$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> 

Falls es aufkommt. vom Server:

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 

Vom Client innerhalb des Netzwerks (mit 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 

Ich hoffe das ist alles. Vielen Dank.

Diese Frage kommt von hier, da sie nicht zum Thema gehörte:

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

2

3 Antworten auf die Frage

2
Anaksunaman

Externe Lösungen

Was muss ich ändern, um über das externe Netzwerk auf meine owncloud vom internen Netzwerk aus zuzugreifen?

Leider habe ich noch nie einen Heimrouter getroffen, der NAT Loopback (auch als Hairpinning bezeichnet ) nicht unterstützt hat. Daher kann ich keine konkrete Antwort darauf geben, wie er mit externem Zugriff auf ihn zugreifen kann .

Andere Lösungen


Eine DNS-basierte Lösung

Wenn Sie davon ausgehen, dass Ihr Ziel nicht komplizierter ist als der Zugriff auf Ihren Medienserver über das interne Netzwerk mit einer von Menschen lesbaren Domäne und Sie bereit sind, BIND-DNS zu konfigurieren, können Sie versuchen, eine Pseudo-Domain auch für Ihr Netzwerk verfügbar zu machen .

Diese Pseudo-Domäne ermöglicht möglicherweise den Zugriff auf Ihren lokalen Server server.ownüber das interne Netzwerk. Diese gefälschte Top Level Domain (TLD) ex . .ownkann im Wesentlichen alles sein, was Sie wollen.

Ich würde vermuten, dass dies auch mit dem NAT-Loopback-Problem funktionieren sollte.

Verwendung einer Pseudo-Domain

Am einfachsten ist es, wenn ein Computer im Netzwerk DNS bereitstellt. Die größten potenziellen Nachteile dieser Anordnung sind:

  • Sie müssen wahrscheinlich sicherstellen, dass Ihr Router auf den Server zeigt, auf dem BIND ausgeführt wird.

  • Der Computer, der als DNS-Server dient, muss eingeschaltet sein, damit dies funktioniert (und Ihre Netzwerkverbindung).

Router DNS Entries Pointing To Local DNS Server

Auch wenn dies in diesem Fall wahrscheinlich weniger wichtig ist, kann das Ausführen eines BIND-Diensts, der Zugriff auf interne und externe Netzwerke bietet, etwas riskant sein. Im Allgemeinen sollten Sie nicht eine nachahmen öffentliche TLD wie .eues sei denn, Sie wissen, was Sie tun. Wenn Sie das doc.selfhostPräfix lieber als etwas anderes behalten möchten, ist das in Ordnung, Sie sollten jedoch eine andere nicht verwendete Erweiterung auswählen (z doc.selfhost.own. B. ).

Apache und Owncloud

Nach der Aktivierung müssen Sie Apache (Ihre Pseudo-Domain wird wahrscheinlich ein VirtualHost sein) und Owncloud einrichten, um auf Anfragen richtig zu antworten und den entsprechenden Inhalt bereitzustellen (z. B. Owncloud).

Arbeitsbeispiele

Im Folgenden finden Sie einige Arbeitsbeispiele für die Konfiguration der Hauptdateien in BIND, um Pseudo-Domänendienste bereitzustellen.

Bitte beachten Sie, dass ich nicht alle notwendigen Schritte darlege, um BIND selbst zum Laufen zu bringen, daher gibt es einige zusätzliche Schritte, die hier nicht explizit erwähnt werden. Beachten Sie auch, dass diese Beispiele technisch für neuere Versionen von BIND 9 unter Windows (BIND 9.10 und höher) sind.

Der tatsächliche Inhalt von db.rev.10.txt und db.example.own.txt sollte zwischen Windows und * nix nicht geändert werden. Das größere Hindernis besteht darin, sicherzustellen, dass die named.conf- Einträge in den richtigen Dateien auf Nicht-Windows-Plattformen angezeigt werden und db.rev.10.txt und db.example.own.txt in den korrekten * nix-Verzeichnissen angezeigt werden .


Referenz für Ubuntu: Sieben einfache Schritte zum Einrichten eines Interal DNS-Servers unter Ubuntu

Beachten Sie, dass bei der Verwendung von Redhat-basierten Distributionen subtile Unterschiede zu Debian / Ubuntu / Mint bestehen.


Angenommen, Sie sind mit all dem einverstanden, hier sind die grundlegenden Arbeitsbeispiele. Dies ist im Wesentlichen eine Zwischenspeicherung der DNS-Konfiguration, falls dies wichtig ist.

  1. BIND einrichten und arbeiten. Ich werde warten. =)

  2. named.conf - Bearbeiten Sie named.conf. (ungefähr) wie unten angegeben. Unter Windows befinden sich alle Einträge in "named.conf" (im Verzeichnis "etc" von BIND). Bei modernen * nix sind diese Einträge häufig auf mehrere Dateien aufgeteilt. Stellen Sie außerdem sicher, dass Sie bei Bedarf alle richtigen Einträge für "rndc-key" und "control" angeben.

    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 ;   # "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 - Unsere Reverse-Zonendatei. Fügen Sie PTR-Einträge für jeden physischen Server hinzu, auf den in Ihrer Forward-Zonendatei verwiesen wird (z . B. db.example.own.txt ). In diesem Beispiel gehen wir davon aus, dass wir als Single Media Server 10.0.0.3anrufen möchten 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 - Unsere Forward-Zone-Datei. In diesem Beispiel gehen wir davon aus, dass wir als Single Media Server 10.0.0.3anrufen möchten example.own. Natürlich können Sie auch MX und CNAMEs hinzufügen. Wenn Sie weitere Server hinzufügen (z. B. media IN A 10.0.0.4), fügen Sie der Reverse-Zone auch den entsprechenden PTR-Datensatz hinzu (z. B. db.rev.10.txt4 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 

Krimskrams

  • Stellen Sie sicher, dass Sie die Seriennummer jedes Mal in den Forward- und Reverse-Zonen aktualisieren, wenn Sie Änderungen daran vornehmen.

  • Stellen Sie ebenfalls sicher, dass Sie die Bindung neu laden, nachdem Sie ANY Änderungen an Ihren BIND-Konfigurationsdateien vorgenommen haben. Im Allgemeinen möchten Sie wahrscheinlich alle Originale vor dem Basteln sichern.

  • Unter der Annahme, alles richtig eingerichtet ist, jedes fähiges Gerät (einschließlich Android) im Netzwerk sollte die Lage sein, den Zugriff example.ownohne weitere Konfiguration (dh wie das reguläre Netz).

  • Beachten Sie, dass Sie bei der Verwendung von Chrome einen nachgestellten Schrägstrich in der Adressleiste anhängen müssen (z. B. example.own/). Andernfalls werden Sie möglicherweise zur Google-Suche weitergeleitet. Diese Anforderung wird in zukünftigen Versionen wahrscheinlich nicht geändert .

  • In eher traditionellen Setups zeigen diese beiden Artikel für Ubuntu und Centos 7 (Redhat) einige Unterschiede bei der Konfiguration von BIND zwischen den beiden.

Danke für die ausführliche Antwort. Nur ein paar Klarstellungen: selfhost ist ein Dienst, der Ihnen einen Domänennamen gibt, der in meinem Fall `doc.selfost.eu` ist und ihn in eine IP-Adresse auflöst. Andere erhalten `othername.selfhost.eu`. Ich habe keinen Einfluss auf die Namensgebung, außer auf das "doc". Das Wichtigste ist nicht, dass ich mit einem für Menschen lesbaren Zugriff auf meinen Server zugreifen kann, sondern auf den Server von * überall * mit * einer * Domäne zugreifen muss. Es ist mir egal, ob es sich um eine IP oder eine Zeichenkette handelt. Ich möchte die Adresse im owncloud-Client nicht jedes Mal ändern, wenn ich mich einlogge. Ich werde sehen, wie weit ich mit Ihren Tipps komme. Vielen Dank. doc vor 8 Jahren 0
0
Stephen Falken

Ich habe seit dem letzten Monat mit diesem Problem zu kämpfen, seit ich einen brandneuen Linksys WRT1200AC $ 180-Router gekauft habe. Ich habe auch ein dynamisches IP-Konto, mit dem ich von unterwegs auf mein Heimnetzwerk zugreifen kann. Ich habe eine Menge Nachforschungen angestellt, wie Sie es getan haben. Aber etwas so einfaches wie das Sicherstellen, dass meine Websites online sind, ist jetzt unmöglich. Ich habe sogar einen Python-Proxy-Server in der Google-Cloud erstellt, damit ich diese Websites sehen kann. es funktionierte jedoch irgendwann aus unbekannten Gründen.

Meine Umgebung ist Windows, aber das Problem ist identisch. Mein aufrichtiger Rat ist, einfach einen neuen Router zu kaufen und sich viel Frustration und Elend zu ersparen. Ich kaufe jetzt selbst nach einem, aber es ist erwiesen, dass es sehr schwierig ist, einen neuen Router zu finden, der NAT-Loopback unterstützt. Ich habe keinen Weg gefunden, um dieses Problem anders zu umgehen. Viel Glück.

-1
mabra

Ich bin mir nicht sicher, alle Aspekte davon zu verstehen, und bin zufällig hier gestolpert. Für meine eigene Infrastruktur habe ich das Problem gelöst, indem ich die iptables-Regeln verwendete, um die internen Anfragen an die internen Server umzuleiten. Ich verwende jedoch einen Linux-Computer als Firewall. Trotzdem scheint es nützlich zu sein, diesen Link zu lesen: Zugriff auf einen DNAT-Server vom lokalen LAN aus über die öffentliche IP-Adresse