web-dev-qa-db-ja.com

LAN内（複数のサブネット間）からローカルでホストされているWebサーバーを指すインターネットドメイン名のDNS IP解決を取得するにはどうすればよいですか？

話の本題に入る：

私の特定の質問はこれです：10.0.3.X/24ネットワーク上のクライアントはsubdomain.site.comに到達できません。 10.0.2.X/24および10.0.3.X/24のクライアントがsubdomain.site.comを呼び出すときに10.0.1.4を解決できるようにするにはどうすればよいですか？

WAN側のドメイン名を使用してWebサーバーLANでDNS解決を機能させたいのですが。 subdomain.site.comnクライアントのいずれかのLANサブネットワークはsubdomain.site.comまたはsite.comと入力できます。適切にルーティングされます（スケーラブルなので、/etc/hostsは問題外です）。

私のLANには、[〜＃〜] lede [〜＃〜]（ネットワーク.1）およびOpenWRT（ネットワーク.2およびネットワーク.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)

ヘアピンNAT /ループバックは必要ありませんNATソリューション。DNSを使用したソリューションが必要です。理由は次のとおりです。

  1. クライアントからの発信コールは、信頼できるDNSを呼び出して（ルーティング用に）IPを見つけ、その宛先にパケットを送信します。
  2. 到着すると、サーバーにDNATされます。
  3. 送信元IPはクライアントのローカルアドレスであるため、サーバーはクライアントを直接呼び出します（パケットの送信元IPを使用）。
  4. クライアントは、ゲートウェイから間接的にゲートウェイの内線から送信されることを想定しているため、このパッケージを拒否します。 addr。上記のDNSによって提供されます。
  5. A NATループバックは、アウトバウンドソースIPをゲートウェイのLAN側アドレスに変換することで問題を解決します。
  6. 次に、サーバーはクライアントに直接応答するのではなく、ゲートウェイに応答します。かっこいい豆。

このデータフローの問題は、LANを離れてグローバルDNSサーバーにIPアドレスを問い合わせるのは効率的ではないということです。サーバーがローカルピアの場合（NATの同じ側にあり、私の場合は必ずしも同じローカルサブネット内にあるとは限りません）。クライアントとサーバーがローカルピアの場合でも、なぜLANを離れるのですか？Aループバックの優れた説明NATフローはここにあります https://unix.stackexchange.com/a/282094/33386 。

DNS split-horizo​​nsまたは最近一部の人々がそれを呼んでいる流行語を使用して、私が望むことを達成することが可能であることを私は知っています。また、特定のインスタンスでグローバルネームサーバーよりも優先されるローカルネームサーバーがこれを解決します。 複数のサブネット（複数のDHCP + DNSサーバー）を使用している場合、OpenWRTまたはLEDEでこれを実装するにはどうすればよいですか？誰かがすでにこれを行っている必要があります。

現在、10.0.1.X/24のクライアントは対応するdnsmasq設定subdomain.site.comで/etc/config/dhcpに到達できますが、これはサブドメインをカバーしていないと思ったので、理由はわかりません。

config domain
        option name 'site.com'
        option ip '10.0.1.4' # LAN address of web server
dnsopenwrtdnsmasq
1
Jonathan Komar

最初の欠落要素

ファイル/etc/config/dhcpのauxルーターのdnsmasq構成に2つのものを追加する必要がありました。

    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

list serverは、dnsmasqがdnsクエリを10.0.1.1のサーバー（メインルーターのdnsmasqサーバー）に転送します。 list rebind_domainを使用すると、特定のサイトの再バインドが可能になり、dns再バインド保護をオンのままにできます。 ここで「冗談」をありがとう 。別のオプションは、dns再バインド保護を完全に無効にすることです。あるいは、option rebind_localhost 1を使用することも可能かもしれませんが、私はこれをテストしませんでした。この手順がないと、subdomain.site.comにpingを実行できませんでした。

2番目の欠落している要素

メインルーターの/etc/dnsmasq.confに次のエントリを追加します。

address=/.site.com/10.0.1.4

サブドメインのプレースホルダー.に注意してください。この変更は/etc/config/dhcpでも可能かもしれませんが、その方法はわかりません。

オリジナルの2番目の欠落要素（限定）

これは私の最初の解決策でしたが、それ以来私はそれを放棄しました。メインルーターの10.0.1.4 subdomain.site.comファイルにエントリ（/etc/hosts）を追加しました。これには、webdavを使用する場合のように、サブドメインや拡張URLのプレースホルダーがないという制限があります。

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

logqueries 1を/etc/config/dhcpに追加してこれをテストし、すべてのDNSクエリをログに記録します。次のようなものが表示されます。これは、/etc/hostsがソースであったことを示しています。

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

うまくいかなかった

メインルーターでの次の/etc/config/dhcp構成は、10.0.1.X/24サブネット内でのみ機能することに驚きました。

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'

誰かがこれに光を当てることができるなら、私は理由を知りたいです！おそらく問題ですか？

補助ルーターのoption dns 10.0.1.1に/etc/config/networkを追加しても、私の状況はあまり役に立たなかったようです。

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'

このオプションを追加すると、エントリがcat /tmp/resolv.conf.autoに表示されます。ただし、list server 10.0.1.1は、上記で説明したように、WANインターフェイスにnameserver 10.0.1.1を追加します。

補助ルーターのdhcp_optionに/etc/config/dhcpsを追加しても効果はありませんでした。

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
1
Jonathan Komar

スプリットホライズンまたはローカルネームサーバーのいずれかが必要です。

10.0/16の背後にあるクライアントを、subdomain.example.comゾーンに対して権限のあるローカルネームサーバーにポイントし、それ以外の場合は再帰します。これは、スタンドアロンネームサーバーまたはスプリットホライズンで可能です。

以下の両方の例には、タスクを実行するための最小要件が含まれています。セキュリティ上の懸念やその他の構成の詳細は、この質問の範囲外です。

DNS HOWTO と DNSとBIND の順に読むことを強くお勧めします。

スプリットホライズン

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

スタンドアロンネームサーバー

これは通常のBINDインスタンスですが、内部ゾーンに対して権限を持つように構成されています。

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";
};
1
Ben Stern