web-dev-qa-db-ja.com

内部ルート53 DNS over VPNをオンプレミスのActive Directoryに公開する

状況

ウェブアプリケーションをAWSに移行しています。オンプレミスネットワークとAWSを接続するために、VPN接続を作成しました。これは問題なく動作します。

オンプレミスでは、MS AD（2008 R2）があり、（特に）ourcompany.tld（実際のドメイン名ではありません）に対する権限のあるサーバーです）

AWSでは、すべての内部サービスに* .dev.ourcompany.tldのような名前を付けます。このDNSは、内部route53によって解決される必要があります。

AWSでは、パブリックリソースの名前は* .ourcompany.tldです。このDNSは、弊社のネームサーバーによって解決されます。 （ワーキング）

問題

オンプレミスネットワークでは、someserver.dev.saa.nlを解決できるようにしたいと考えています。これを実現するには、MS ActiveDirectoryに、このドメイン名をAWSで検索するように指示する必要があります。

AWS内部route53には、AWS VPC内からのみアクセスできます。 ADはこれに直接到達できません。

AWS内部route53には、権限のないVPC DNSフォワーダーを介してのみアクセスできます。

MS ADでは、スタブゾーンと条件付きフォワーダーに信頼できるソースが必要です。

私たちがやったこと/試したこと

  • VPCにDNSフォワーダーを作成します。このフォワーダーには権限がありません。 DNSフォワーダーをコンピューター自体のプライマリDNSとしてセットアップするとうまくいきます。 ActiveDirectoryでは、サーバーに権限がないというメッセージを含むスタブゾーンまたは条件付きフォワーダーを作成できません。
  • Amazon VPCでdev.ourcompany.tldのスタブゾーンを使用してDNSサーバーを作成します。スタブゾーンを作成すると、信頼できると報告されますが、VPC DNSフォワーダー（VPC IP + 2上）でしかDNSを解決できないため、ソースが信頼できないため、スタブの作成を拒否します。信頼できるマスターに直接接続すると、状態REFUSEDが返されます。

  • AWSドキュメントを検索しました。私たちが見つけた唯一の正しい解決策は https://aws.Amazon.com/blogs/security/how-to-set-up-dns-resolution-between-on-mise-networks-and-aws- using-aws-directory-service-and-Amazon-route-53 / ただし、フランクフルト地域（規制に拘束される）には単純なADがありません。 AWSでの完全なMS ADも機能しますが、DNSフォワーダーに月額€300以上を支払う準備はありません

  • AWSサポートにお問い合わせください。 1週間の長い待機の後、彼らはまだ問題を理解していないようです。事業支援計画中です。

誰でも、既存のADを使用してこれを解決する方法をいくつか教えていただけますか？

diagram

更新：AWS内部ルート53への別のドメインのルーティングは、条件付き転送でエラーを無視するだけで機能します。ただし、サブドメインの場合は、委任を行う必要があります。委任は照会時にSERVFAILをスローします。

更新2：可能ではないようです。また、AWSテクニカルサポートも中止しました。これで、すべてのサーバーとサービスに別のドメイン名を登録し、ADで固定DNSを使用して、IT部門以外が使用するサービスをセットアップしました。 EC2のプロキシを使用して、プロキシをLB DNS名に変換します。

domain-name-systemamazon-web-servicesvpnamazon-route53authoritative
5
nvanesch

それが正しければ、2つの制約があります。

  1. dev.ourcompany.tldRoute53ゾーンは、VPCからのみ解決でき、VPN経由では解決できません。
  2. オンプレミスADは、dev.ourcompany.tldのauthoritativeネームサーバーと直接通信し、フォワーダーとは通信しないことを望んでいます。

これらの制限により、1）ADにRoute53と直接通信するように考えさせ、2）Route53にDNSリクエストがVPC内のIPからのものであると考えさせるソリューションを設計する必要があります。

考えられる答えの1つはNAT-ネットワークアドレス変換です。これが私が行う方法です。

  1. 小さなEC2インスタンスを起動します。 Amazon Linuxおよびインスタンスのネットワーク設定のDisable "Source/Destination Check"。多分それにも固定プライベートIPアドレスを与えます。また、セキュリティグループで着信TCPおよびUDPポート53を許可します。

  2. /etc/sysctl.confを設定して、net.ipv4.ip_forward=1でIP転送を許可します

  3. インスタンスのiptablesを構成して、ポート53のすべての着信トラフィックをRoute53にリダイレクトします。つまり、VPC-CIDR + 2にリダイレクトします。何かのようなもの：

    iptables -t nat -A PREROUTING -p tcp --dport 53 \
         -s <on-prem-cidr> -j DNAT --to <VPC-CIDR+2>

iptables -t nat -A PREROUTING -p udp --dport 53 \
         -s <on-prem-cidr> -j DNAT --to <VPC-CIDR+2>

  4. ADがこのインスタンスのプライベートIPを指すようにします。 DNSトラフィックはNAT処理され、Route53に転送されます。Route53は、それがVPCからのものであると見なして応答します。また、信頼できるネームサーバーから直接回答が得られるため、ADも満足します。

それが役に立てば幸い:)

2
MLu

権限のあるサーバーはオンプレミスのMS ADではありませんでしたが、同じ状況でした。この問題を解決するために、Amazon VPC DNSをバックエンドとして使用して権威のあるネームサーバーを動作させる CoreDNSのプラグイン を記述しました。現在、私たちの環境で動作しています。

0
Hiroyuki Wada

次のようにして行うことができます。

  1. Ourcompany.tldの権威DNSサーバーで、dev.ourcompany.tldへの委任を作成します。
  2. NSフィールドに、ourcompany.tldに対して権限のある同じDNSサーバーを入力します-これにより、次のステップで条件付きフォワーダーをセットアップするためのブロックが解除されます
  3. Dev.ourcompany.tldの条件付きフォワーダーをセットアップし、「DNSフォワーダーを使用したEC2インスタンス」のIPを指すようにします（イメージに示されています）。

ソース

0
ihaz