2

Во-первых, я хочу сказать, что я, вероятно, прочитал все, что есть в интернете относительно проблемы.

И проблема в том, что я не могу получить доступ к своему собственному облаку через doc.selfhost.eu, если я нахожусь в той же сети. Но я могу получить к нему доступ изнутри сети через внутренний IP-адрес (192.168.2.200) и извне сети через doc.selfhost.eu.

Моя настройка: домашний сервер под управлением Linux Mint 17.2 Cinnamon, который должен быть предназначен для медиа и запускать owncloud.

Сервер подключен к Speedport 723v, который не поддерживает NAT Loopback. Порты 80 и 443 пересылаются, и для динамического DNS у меня есть учетная запись на selfhost.de, которую я ввел в настройках маршрутизатора.

На моем компьютере с Windows 7 (с которого я пытаюсь получить доступ к серверу) я ввел 192.168.2.200 (внутренний IP-адрес сервера) как DNS.

В Mint я отключил сетевой менеджер (на самом деле я его удалил) и теперь я использую интерфейсы.

Не было бы решения изменить файлы хостов всех клиентов (на некорневых андроидах это даже невозможно).

Вопрос:

  1. Что мне нужно изменить, чтобы получить доступ к своему собственному облаку из внутренней сети через внешний IP?

/ и т.д. / сеть / интерфейсы

# 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

В /etc/dnsmasq.conf это единственное, что я добавил:

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 (читайте где-нибудь, чтобы создать это)

address=/doc.selfhost.eu/192.168.2.200

/ и т.д. / хосты

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

Настройки собственного облака в /var/www/owncloud/config/config.php

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

Конфигурация Apache В /etc/apache2/apache2.conf все довольно стандартно. Я только добавил:

ServerName doc-desktop

/etc/apache2/sites-enabled/owncloud.conf. Никаких изменений на сайтах нет, ссылок нет.

<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>

В случае, если это подходит. с сервера:

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

Из клиента внутри сети (с 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

Я надеюсь, что это все. Благодарю.

Этот вопрос возник отсюда, поскольку он был не по теме:

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

3 ответа3

2

Внешние решения

Что мне нужно изменить, чтобы получить доступ к своему собственному облаку из внутренней сети через внешний IP?

К сожалению, никогда лично не сталкиваясь с домашним маршрутизатором, который не поддерживает NAT Loopback (также известный как шпилька), я не могу дать конкретный ответ о том, как получить к нему доступ с помощью чего-либо внешнего.

Другие решения


DNS-решение

Предполагая, что ваша цель не сложнее, чем доступ к вашему медиасерверу из внутренней сети с понятным для человека доменом, и вы готовы настроить DNS BIND, вы можете попытаться сделать псевдодомен доступным и для вашей сети.

Этот псевдодомен потенциально может позволить вам получить доступ к вашему локальному серверу по адресу server.own во внутренней сети. Этот поддельный домен верхнего уровня (TLD) ex. .own может по существу быть чем угодно.

Я подозреваю, что это должно работать даже с проблемой обратной петли NAT.

Использование псевдо-домена

Самым простым способом является наличие одного компьютера в сети, обеспечивающего DNS. Самые большие потенциальные недостатки этого соглашения:

  • Скорее всего, вам необходимо убедиться, что ваш маршрутизатор указывает на сервер, на котором работает BIND.

  • Компьютер, служащий вашим DNS-сервером, должен быть включен, чтобы это (и ваше сетевое соединение) работали.

DNS-записи маршрутизатора, указывающие на локальный DNS-сервер

Кроме того, хотя это, вероятно, менее важно в этом случае, запуск службы BIND, обеспечивающей доступ как к внутренним, так и к внешним сетям, может быть несколько рискованным. Как правило, вы не должны имитировать общедоступный домен верхнего уровня, например .eu если вы не знаете, что делаете. Если вы хотите сохранить префикс doc.selfhost а не что-то еще, это нормально, но вы должны выбрать другое неиспользуемое расширение (например, doc.selfhost.own).

Apache и Owncloud

После включения вам нужно будет настроить Apache (ваш псевдодомен, скорее всего, будет VirtualHost) и Owncloud, чтобы правильно отвечать на запросы и обслуживать соответствующий контент (например, Owncloud).

Рабочие примеры

Ниже приведены некоторые рабочие примеры того, как настроить основные файлы в BIND для предоставления услуг псевдодомена.

Обратите внимание, что я не покрываю все, что вам может понадобиться, чтобы заставить работать сам BIND, поэтому могут быть некоторые дополнительные шаги, не упомянутые здесь явно. Также обратите внимание, что эти примеры технически для последних версий BIND 9 для Windows (BIND 9.10+).

Фактическое содержимое db.rev.10.txt и db.example.own.txt не должно нуждаться в модификации между Windows и * nix. Большим препятствием является то, что записи named.conf появляются в нужных файлах на платформах, отличных от Windows, и что db.rev.10.txt и db.example.own.txt появляются в правильных каталогах * nix.


Справочник по Ubuntu: семь простых шагов по настройке встроенного DNS-сервера в Ubuntu

Обратите внимание, что при использовании дистрибутивов на основе Redhat между ними и Debian/Ubuntu/Mint есть небольшие различия.


Предполагая, что у вас все в порядке, вот основные рабочие примеры. По сути, это конфигурация кэширования DNS, если она имеет значение.

  1. Настройте BIND и работайте. Я буду ждать. знак равно

  2. named.conf - Изменить named.conf. (примерно), как указано ниже. В Windows все записи находятся в "named.conf" (находится в каталоге BIND "и т.д."). На современном * nix эти записи часто разбиты на несколько файлов. Также убедитесь, что включили все соответствующие записи "rndc-key" и "control" по мере необходимости.

    ех. 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 - Наш обратный файл зоны. Добавьте записи PTR для каждого физического сервера, указанного в файле зоны пересылки (например, db.example.own.txt). В этом примере мы предполагаем, что в качестве единственного медиа-сервера в 10.0.0.3 мы хотим вызвать example.own .

    ех. 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 - файл зоны Forward. В этом примере мы предполагаем, что в качестве единственного медиа-сервера в 10.0.0.3 мы хотим вызвать example.own . Конечно, вы также можете добавлять MX и CNAME. Если вы добавляете дополнительные серверы (например, media IN A 10.0.0.4), добавьте соответствующую запись PTR также в свою обратную зону (например, db.rev.10.txt4 IN PTR media.example.own)

    ех. 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
    

Шансы и Концы

  • Обязательно обновляйте серийный номер в прямой и обратной зонах каждый раз, когда вы вносите в них изменения.

  • Аналогично, убедитесь, что "перезагрузили" связывание после внесения ЛЮБЫХ изменений в ваши конфигурационные файлы BIND. Как правило, вы, вероятно, захотите скопировать любые оригиналы, прежде чем возиться.

  • Предполагая, что все настроено правильно, каждое совместимое устройство (включая Android) в сети должно иметь доступ к example.own без дальнейшей настройки (например, как в обычной сети).

  • Обратите внимание, что если вы используете Chrome, вам необходимо добавить косую черту в адресную строку (например, example.own/), в противном случае вы можете быть перенаправлены на поиск Google. Это требование, вероятно, не будет изменено ни в каких будущих версиях.

  • В то время как для более традиционных установок, эти две статьи для Ubuntu и Centos 7 (Redhat) иллюстрируют некоторые различия в настройке BIND между ними.

0

Я боролся с этой проблемой в течение последнего месяца с момента покупки нового маршрутизатора Linksys WRT1200AC за 180 долларов. У меня также есть динамическая учетная запись IP, которая позволяет мне получить доступ к моей домашней сети с дороги. Я сделал кучу исследований, как и вы. Но сделать что-то простое, например, убедиться, что мои сайты в сети, теперь невозможно. Я даже создал прокси-сервер Python в облаке Google, чтобы я мог видеть эти сайты; однако в конце концов он перестал работать по неизвестной причине.

Моя среда - Windows, но проблема идентична. Мой искренний совет - просто купить новый маршрутизатор и избавить себя от многих разочарований и страданий. Сейчас я покупаю один, но оказалось, что найти новый маршрутизатор, поддерживающий петлю NAT, очень сложно. Я не нашел способ обойти эту проблему иначе. Удачи.

-1

Я не слишком уверен, чтобы понять все аспекты этого, и я застрял здесь более случайно. Для моей собственной инфраструктуры я решил это, используя правила iptables для перенаправления внутренних запросов на внутренние серверы, но в качестве брандмауэра я использую машину linux. В любом случае полезно прочитать эту ссылку:Доступ к серверу DNAT из локальной сети с использованием публичного IP-адреса

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .