多くの組織が内部から内部へのNATまたは同様のソリューションを使用してNATヘアピンを許可しないのはなぜですか？

内部から内部へのNAT、つまりNATループバックは、内部インターフェイスのコンピューターからASAまたは同様のデバイスの外部インターフェイス上のWebサーバーにアクセスする際のヘアピンNATの問題を解決します。これにより、DNS管理者は、パブリックアドレスにNAT変換されたサーバーに対応するRFC1918アドレスを持つ重複した内部DNSゾーンを維持する必要がなくなります。私はネットワークエンジニアではないので、何かが足りないかもしれませんが、これは設定と実装が簡単なようです。非対称ルーティングは問題になる可能性がありますが、簡単に軽減できます。

私の経験では、ネットワーク管理者/エンジニアは、NATヘアピンを適切に処理するようにファイアウォールを構成するのではなく、システムユーザーがsplit-dnを実行することを好みます。どうしてこれなの？

私がそれをしない理由はいくつかあります：

• 必要がないのに、DMZルーターとファイアウォールに余分な負担をかけるのはなぜですか？ほとんどの内部サービスはDMZではなく、一般的な企業エリアにあり、DMZにはプロキシサービスがあり、リモートアクセスがときどき行われます。内部から内部へのnatを実行すると、DMZにより多くの負荷が追加されます。
• DNAT + SNATを実行しないと、非対称ルーティングが発生しますが、これは正しく実行するのが難しいことで有名です。だからあなたはSNATし、ソースIP情報を失います。ただし、トラブルシューティングの目的でソースIPを人にリンクすることは非常に便利です。または、愚かな場合に時折ナーフシュートの目的。「このIPは、認証されていないサービスXで何かおかしなことをしている」「ああ、imapサーバーのログを見てみましょう」

明らかに、これに対する明確な答えはありませんが、いくつかの理由が考えられます。

1. エレガンス：NATはそもそもそれほどエレガントではありませんが、IPv4の制限されたアドレススペースが必要です。NATを回避できる場合、そうします。IPv6では、問題はとにかく消え去っています。
2. 複雑さ：特に、すべてのセキュリティ境界を作成する単一の「コア」ルーターがない場合、フィルター構成は非常に複雑になる可能性があります。または、ほぼすべてのルーターデバイスにNATルールを分散して維持する必要があります。
3. 参照：ファイアウォール管理者が他のサーバー管理チームとは異なる場所にいる場合は、到達するのが難しいかもしれません。ファイアウォール管理者のバックログ（または休暇）によって変更が遅れないようにするために、同じチームで責任を維持するオプションが選択されます
4. 移植性と一般的な慣行：DNSビューを使用することは、この問題を解決するために「誰もが知っていること」です。すべての境界ルーターが単純な方法でループバックNATをサポートするとは限りません。特定の環境で正しく設定する方法を知っている人は少ないでしょう。ネットワークの問題のトラブルシューティングを行う場合、乗組員はヘアピンNAT構成とその影響をすべて認識する必要があります-明らかに無関係な問題を追跡している場合でも

免責事項-これはフレームベイトの答えです。

このような解決策が避けられると思う一般的な理由は、ネットワークエンジニア側のNATに対する不合理な恐怖/憎しみです。これに関する議論の例をいくつか見たい場合は、これらをチェックしてください：

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/（Tomのブログは、かなり熱烈なNAT / IPv6の議論を集め続けているようです）
• http://libertysys.com.au/blog/nat-i​​s-evil-but-not-bad（私のブログ）

私が知ることができることから、この恐怖の多くはシスコのNATの貧弱な実装に起因しています（その意味でそれは非合理的ではないかもしれません）が、私の心では「古典的な」ネットワークエンジニアは「NATは悪い」世界観、それは彼または彼女が完全に理にかなって実際にソリューションを簡素化するこのような明白な例を見ることができないこと。

どうぞ-心ゆくまで投票してください！:-)

私の推測は：

1. スプリットDNSはより簡単に理解できます。
2. NATヘアピンはルーター上のリソースを使い果たしますが、スプリットDNは使い果たしません。
3. ルーターには、帯域幅の制限がありますが、これはsplit-dnsのセットアップでは実現できません。
4. ルーティング/ NATの手順を回避するため、スプリットDNのパフォーマンスは常に向上します。

ヘアピンNATのプラス側では、

• セットアップが完了すると動作します。
• 職場のネットワークとパブリックインターネットの間で移動するラップトップのDNSキャッシュに関する問題はありません。
• サーバーのDNSは1か所でのみ管理されます。

内部サーバーへのトラフィック要件が少ない小規模ネットワークでは、ヘアピンNATを使用します。サーバーへの接続が多く、帯域幅と遅延が重要な大規模ネットワークの場合は、split-dnを使用します。

私の観点から、これはCisco PixからASAへの移行の間に少し変更されました。aliasコマンドを失った。また、一般に、Ciscoファイアウォールの内部インターフェイスから外部アドレスにアクセスするには、何らかのトリックが必要です。参照：外部IPで内部サーバーにアクセスするにはどうすればよいですか？

ただし、重複した内部DNSゾーンを常に維持する必要はありません。Cisco ASAは、NATステートメントで設定されている場合、外部アドレスのDNSクエリを内部アドレスにリダイレクトできます。しかし、私は、パブリックDNSゾーンの内部ゾーンを保持して、その粒度を確保し、ファイアウォールへのステップではなく1か所で管理できるようにすることを好みます。

通常、環境（メール、Web、いくつかの公共サービス）でこれを必要とするサーバーはわずかであるため、大きな問題ではありません。

いくつかの理由が考えられます。

1. 多くの組織は、すべての内部DNS情報を世界に公開したくないため、すでにDNSを分割しているため、パブリックIPを介して公開されている少数のサーバーを処理するための追加作業はそれほど多くありません。
2. 組織とそのネットワークが大きくなると、多くの場合、内部の人々にサービスを提供するシステムと外部にサービスを提供するサーバーが分離されます。
3. 中間デバイスがパケットに対して行う変更が少ないほど、レイテンシ、応答時間、デバイスの負荷、およびトラブルシューティングに関しては優れています。
4. （非常にマイナー、確かに）NATデバイスがパケットのヘッダーを超えて、新しいIPアドレスでデータを変更しない場合、NATがまだ壊れるプロトコルがあります。たとえそれが制度的記憶の単なる事例であっても、それは人々がそれを避ける正当な理由であり、特に彼らが100％確信がないプロトコルを扱っている場合です。

NATループバックを使用する場合、NATデバイスがスプーフィングされたソースアドレスをどのように処理するか少し心配になります。パケットがどのインターフェイスに入ってきたかをチェックしない場合、WANから内部アドレスをスプーフィングし、内部アドレスを使用してサーバーにパケットを送信できます。返信を受け取ることはできませんでしたが、内部アドレスを使用してサーバーを侵害する可能性があります。

NATループバックをセットアップし、DMZスイッチに接続して、スプーフィングされた内部ソースアドレスでパケットを送信します。サーバーログをチェックして、それらが受信されたかどうかを確認します。次に、コーヒーショップに行き、ISPがスプーフィングされたアドレスをブロックしているかどうかを確認します。NATルーターがソースインターフェイスをチェックしていないことがわかった場合、ISPがチェックしている場合でもNATループバックを使用しないでしょう。