web-dev-qa-db-ja.com

背後のDNSサーバーNAT

NATファイアウォールの背後にあるBind 9 DNSサーバーがあり、インターネットに面したIPが1.2.3.4であると仮定します

発信トラフィックに制限はなく、ポート53（TCP/UDP）は1.2.3.4から内部DNSサーバー（10.0.0.1）に転送されます。 VPSまたは内部Bind 9サーバーのいずれにもIPテーブルルールはありません。

インターネット上の他の場所にあるリモートLinux VPSから、nslookupは正常に動作します

# nslookup foo.example.com 1.2.3.4
Server:    1.2.3.4
Address:   1.2.3.4#53

Name:      foo.example.com
Addresss:  9.9.9.9

ただし、リモートVPSでHostコマンドを使用すると、次の出力が表示されます。

# Host foo.example.com 1.2.3.4
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; connection timed out; no servers could be reached.

VPSから、（telnetを使用して）1.2.3.4:53への接続を確立できます。

内部DNSサーバー（10.0.0.1）から、Hostコマンドは正常に表示されます。

# Host foo.example.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

foo.example.com has address 9.9.9.9

VPSのHostコマンドが別のポートからの返信について不平を言っている理由に関する提案と、これを修正するにはどうすればよいですか？

詳細情報：

ネットワーク外部のWindowsホストから

>nslookup foo.example.com 1.2.3.4
DNS request timeout
    timeout was 2 seconds
Server: UnKnown
Address: 1.2.3.4

DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
*** Request to UnKnown timed-out

これは、Ubuntu 12.04 LTSからのバインドのデフォルトインストールであり、約11のゾーンが構成されています。

$ named -v
BIND 9.8.1-P1

内部DNSサーバーからのTCPダンプ（フィルター）

20:36:29.175701 IP pc.external.com.57226 > dns.example.com.domain: 1+ PTR? 4.3.2.1.in-addr.arpa. (45)
20:36:29.175948 IP dns.example.com.domain > pc.external.com.57226: 1 Refused- 0/0/0 (45)
20:36:31.179786 IP pc.external.com.57227 > dns.example.com.domain: 2+[|domain]
20:36:31.179960 IP dns.example.com.domain > pc.external.com.57227: 2 Refused-[|domain]
20:36:33.180653 IP pc.external.com.57228 > dns.example.com.domain: 3+[|domain]
20:36:33.180906 IP dns.example.com.domain > pc.external.com.57228: 3 Refused-[|domain]
20:36:35.185182 IP pc.external.com.57229 > dns.example.com.domain: 4+ A? foo.example.com. (45)
20:36:35.185362 IP dns.example.com.domain > pc.external.com.57229: 4*- 1/1/1 (95)
20:36:37.182844 IP pc.external.com.57230 > dns.example.com.domain: 5+ AAAA? foo.example.com. (45)
20:36:37.182991 IP dns.example.com.domain > pc.external.com.57230: 5*- 0/1/0 (119)

クエリ中にクライアントからのTCPダンプ

21:24:52.054374 IP pc.external.com.43845 > dns.example.com.53: 6142+ A? foo.example.com. (45)
21:24:52.104694 IP dns.example.com.29242 > pc.external.com.43845: UDP, length 95
domain-name-systembindnatport-forwardingubuntu-12.04
7
Bryan

以前にコメントで記述されたことといくつかの詳細な説明を要約するには：

NAT UDPのルールが壊れていたようです。エラーメッセージreply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53と、クライアントから取得したトレースで、応答はdns.example.com.29242 > pc.external.com.43845: UDP, length 95のようになります。 。応答パケットのソースポートは53である必要があります。これは、DNSサーバーから取得したダンプでは正しいです（表示目的でdomainに解決されます）。

一部の（特に歴史的な）リゾルバーは異なるポート/ IPからのDNS応答を受け入れる場合がありますが、ほとんどは受け入れません-主にセキュリティ上の理由により DNSスプーフィングとキャッシュポイズニング攻撃 。

とにかく、コネクションレス型UDPの場合NATトラフィックの場合、ルーターは以前に受信したUDP DNSクエリからの状態データを保持する必要があります応答パケットのIP：portタプルを1.2.3.4:53に再度マッピングします-これは明らかにそうではありません。これは、ルーターがポートのUDP状態テーブルを処理する方法のバグである可能性がありますケースの転送-最善の策は、製造元のカスタマーサポートにケースをオープンすることです（コードを事前に最新/最大にアップグレードしておくこと）。このような問題は他のユーザーが以前に気づいていた可能性が高く、すでに修正されている可能性があります。 ）。

5
the-wabbit

OK ... ...これは一度だけ言います... ... NATがDNSでない限り、NATを介してプライベートDNSに到達することはできません。デバイスに到達するには、ポートフォワードする必要があります。デバイスは、そのポートで応答するように構成する必要があります。たとえば、内部ネットワーク上の任意のDNSに任意のポートでDNSクエリを送信します。ポート番号は必要ありません。それらがNATの背後にないため、メッセージは直接であり、デフォルトのDNSポートで実行されているローカルDNSサーバーからDNSルックアップを取得します。特定のポートでクエリを外部ネットワークに送信しました。そのポートはデフォルトのDNSですか応答ポート？そうでない場合は、どちらかを知っていると思います。エラーメッセージで指定されています。可能であれば、特定のポート番号で応答するようにDNSサーバーを設定してください。例のように53で応答するように設定してください。それでもうまくいかない場合、NATはメッセージを送信ポート番号に再ルーティングしています。ポート番号を介して特定のマシンにデータを送信したからといって、データがs ameポート番号。 DNS応答ポートが異なる可能性があります。これは問題Aであり、ルーターは、NATの後に応答を返信アドレスに沿って開いているポートに送信します。ポートは必ずしも同じではありません。受信ポート。最初にメッセージがルーターに送信され、次に目的のポートに送信され、次にポートの転送先のマシンに送信され、次に応答ポートに沿ってルーターに送信され、ルーターがアドレスとポートを変換して送信します。 DNS側のルーターでポートトリガーを試します。NATの背後からポート53がオンになっているときにポート53を開くように設定します。それが機能しない場合は、DNSサーバーを確認し、ポートで応答するように設定します53 Shouldメッセージングが機能することを許可します。これがVPNスタイルのネットワークのDNSである場合、VPNがアクティブであり、DNSが静的である間、サーバーはポートを転送する必要があります。 VPNサブネット上のアドレスです。これで、VPNホストサーバーとクライアントサーバーを接続でき、クライアントサーバーの背後にいる誰もがDNSをeプライマリ、インターネットゲートウェイをセカンダリ、ISP DNSをターシャリとします。

0
harley thomas Davis