人々は本当にプライベートネットワークでパブリックIPv6アドレスを使用するのですか？
私は Debianシステム管理者向けハンドブック を読んでいて、ゲートウェイセクションでこの一節に出くわしました。
... NATはIPv4とその限られたアドレス空間にのみ関連していることに注意してください。IPv6では、アドレスの幅広い可用性により、NATすべての「内部」アドレスをインターネット上で直接ルーティングできるようにします（これは、中間ファイアウォールがトラフィックをフィルタリングできるため、内部マシンにアクセスできることを意味しません）。
それは私に考えさせました... IPv6でまだプライベートレンジがあります。参照： RFC419 。企業は本当にすべての内部マシンをパブリックアドレスでセットアップするのですか？それはIPv6がどのように機能することを意図していますか？
それはIPv6がどのように機能することを意図していますか？
要するに、はい。 IPv6でアドレススペースを大幅に増やす主な理由の1つは、NAT）のようなバンドエイドテクノロジーを排除し、ネットワークルーティングをより簡単にすることです。
ただし、パブリックアドレスとパブリックにアクセス可能なホストの概念を混同しないでください。パブリックアドレスがあっても、インターネットにアクセスできない「内部」サーバーは引き続き存在します。 IPv4と同じように、ファイアウォールで保護されます。しかし、今日の内部専用サーバーが特定のサービスを明日インターネットに開放する必要があると判断するのもはるかに簡単です。
企業は本当にすべての内部マシンをパブリックアドレスでセットアップするのですか？
私の意見では、賢い人はそうするでしょう。しかし、おそらくお気づきのように、かなり時間がかかります。
社内ネットワークでは、すべてのデバイスにパブリックIPv6アドレスを使用しています。
ゲートウェイではステートフルファイアウォールを使用しています。
- すべてのicmpv6を許可します
- 内部ネットワークからの新しい接続を許可します
- パブリックから内部への確立された接続を許可します
パブリックトラフィック（ICMPおよび確立された接続を除く）がネットワークに侵入することはありません。
これまでのところ、このセットアップで問題はなく、完全に機能します。
外部接続が必要ない場合は、プライベートネットワークを使用できます。それがIPv6でもプライベートアドレス空間を定義する理由です。
NATは、IPv4アドレス空間の枯渇を遅らせるために発明されたハックです。 NATはアプリケーションに問題を引き起こし、アプリケーションをNATで動作させるには、元のIPの設計と競合するより多くのハックが必要です。
したがって、Yarikが答えたように動作し、ネットワークのエッジで適切なステートフルファイアウォールを使用することをお勧めします。
前述のように、これはIPが機能するように設計された方法であり、適切に機能します。 NATは、時々迷惑な問題を引き起こします。内部IPのNATの「隠蔽」を利点として説明している人もいますが、それは不利な場合もあります。
私は/ 16のある場所で作業し、すべてのデバイス（プリンター、携帯電話、電子時計など）でパブリックにルーティング可能なIPv4アドレスを使用しました。これは問題なく機能し、さらに、不正な動作をしているユーザーとデバイスを簡単に追跡できるようになりました。また、これらのユーザーの影響も制限されたため、誰かがマルウェアを拡散し始めたり、急流に巻き込まれたりした場合でも、ブラックリストに登録されているためにメールサーバーが妨害されずに通信する能力に影響を与える可能性は低くなります。
IPv6プロポネットはNATをIPv4アドレスの枯渇を緩和するための一時的なハックと見なしていたため、IPv6ではNATは必要ありません。
ただし、NATには、アドレスの枯渇を防ぐ以外にもいくつかの利点があります。
- NATは、内部アドレスをインターネット接続から切り離します。
- 少なくともLinuxでは、NATはフェールクローズする傾向があります。 iptablesルールの読み込みに失敗した場合、プライベートIPを持つデバイスはインターネットに接続できなくなります。これはすぐに通知され、修正されます。一方、パケット転送ファイアウォールは、IP転送がオンになっているのにiptablesルールがロードされていない場合、簡単に失敗して開くことができます。
- NATは、要求を行った内部マシンを隠します。プライバシー拡張はこれである程度役立ちますが、サブネットを非表示にせず、クライアント側の機能であるため、ネットワーク管理者ではなく、クライアントOSが使用するかどうかを選択します。
そのため、少なくとも一部の企業は、IPv4の場合と同じ方法でNATを使用してv6を展開することを選択することを期待しています。他の人たちはIPv6支持者の側にいて、ファイアウォールに行くかもしれませんがアドレス変換はしません。
NATの代わりに何をすべきかについてのアドバイスについてRFC 4864を読んだ後、あなた（そしてIPv6でNATを実装することを検討している人）に再考することを強くお勧めします
私はそれを読みましたが、それがNATの完全な置き換えを提供するとは思いません。
- NATは、内部アドレスをインターネット接続から切り離します。
これに対するIPv6の「解決策」は3つあり、複数のアドレスを並行して実行し、プロバイダーから内部ネットワークへの動的アドレスの割り当てを自動化し、ULAを使用して長期的なローカルアドレスを提供します。
異なる有効期間のアドレスを並行して実行すると、非永続アドレスが長期的な構成で不注意になってしまうリスクがあります。 paralellで複数のインターネットアドレスを実行すると、パケットがどのインターネットゲートウェイから送信されるかをクライアントオペレーティングシステムが認識できないという問題があります。
プレフィックスの委任は、単一のCPEルーターがISPにプレフィックスを要求し、それを1つ以上のローカルインターフェイスに割り当てる単一レベルのシナリオにしっかりと実装されていますが、現在のところ、顧客サイト。
- 少なくともLinuxでは、NATはフェールクローズする傾向があります。 iptablesルールの読み込みに失敗した場合、プライベートIPを持つデバイスはインターネットに接続できなくなります。これはすぐに通知され、修正されます。一方、パケット転送ファイアウォールは、IP転送がオンになっているのにiptablesルールがロードされていない場合、簡単に失敗して開くことができます。
IPv6支持者はこれに対する答えを提供していないようです。彼らは単に事故は起こらないと思い込んでいるようです。
- NATは、要求を行った内部マシンを隠します。
プライバシー拡張はこれである程度役立ちますが、サブネットを非表示にせず、クライアント側の機能であるため、ネットワーク管理者ではなく、クライアントOSが使用するかどうかを選択します。
/ 128を個々のマシンに割り当て、IGPエントリを作成してそれらをルーティングするという提案がありますが、実際にこれを実際に実装している人は知りません。