/ dev / nullと同等のIPアドレス
無視されるように送信されたパケットの原因となるIPアドレスはありますか（ブラックホール）。
私はいつもIPアドレスを使ってルーターを設定し、それからそれに送られたすべてのパケットを無視させることができることを知っています、しかしそのようなことは私の悩みを救うために存在しますか？
RFC 6666 で説明されているように、IPV6には特にブラックホールプレフィックスがあります。これは100 ::/64です。 IP4にはそのような明示的なブラックホールはありませんが、予約済みブロックの1つに存在しないHostがその効果を持ちます。 （たとえば、240.0.0.0/4は「将来の使用のために予約されています」ので、何もルーティングされません。）
ネットワーク ブラックホール のようなものがあります。
IPアドレス192.168.0.10を持つデバイスがネットワークに存在しない場合、このIPアドレスは一種のブラックホールであり、それが存在しないという理由だけで、それに対するすべてのトラフィックを「破棄」します。
接続状態（ＴＣＰ）を追跡するプロトコルは、行方不明の宛先ホストを検出することができる。それはUDPでは起こりませんし、送信側ホストにそれについて知らされない間にパケットはただ死ぬでしょう。
あなたはそれを静かに drop（拒否しない）特定の（あるいは多くの）アドレスから設定することでファイアウォールでブラックホールを設定できます。
私の知る限りでは、TCP/IPバージョン4ではブラックホールとなるようなネットワーク標準アドレスはありません（ Bandrami に感謝します）。
だからあなたは2つのオプションがあります：
- どのホストにも割り当てられていないIPアドレス。
- （
netcat：を使用して）パケットやそのバリエーションを暗黙のうちにドロップするファイアウォールを備えたホスト（ ultrasawblade で提案されているように）。
nc -vv -l 25 > /dev/nullはTCPポート25で受信接続を待ち受け、結果を/dev/nullにパイプ処理します。その他の例 はこちら 。
サブネット全体をブラックホールにすることもできます（ NULLルート ）。
これはブラックホールではありませんが、特に目標が「安全に機能しないデフォルト」の値である場合は、IP をテスト用/サンプル用 に確保することを検討してください。 。
192.0.2.0/24（TEST-NET-1）、198.51.100.0/24（TEST-NET-2）203.0.113.0/24（TEST-NET-3）
ネットワーク事業者は、これらのアドレスブロックをルーティング不可能なアドレス空間のリストに追加すべきであり（SHOULD）、パケットフィルタが展開されている場合、このアドレスブロックはパケットフィルタに追加されるべきである（SHOULD）。
ギャランティがそれらのアドレスへのパケットをブロックするということはありません（それはあなたのISPなどに依存します）が、誰もそれらを既に使っているべきではありません。
「標準的なブラックホールアドレス」というものは存在しませんし、それに対する要件も実際にはありません。あなたが実際に達成しようとしていることを言っているわけではないので、私はあなたがそうするのを助けることはできません、しかしあなたがそれを求めたときあなたの質問に答えるであろうあなたの問題に対する間違った解決策はここにあります：
- あなたはあなたのネットワークで使われていない RFC1918アドレス を使うことができ、あなたに代わってそれを落とすためにあなたのISPに頼ることができます。たとえば、192.168の一部のみを使用している場合、10.255.255.1はISPによってヌルルートされます（これはデフォルトゲートウェイのおかげです）。
- 将来使用するために予約されているIPアドレスを使用することができます（そしておそらく使用されることはないでしょう）。それが古い " クラスE "の範囲です。上記と同じように動作しますが、すべてのプライベートアドレス範囲をすでに使用している場合でも機能します（必要以上に広いネットマスクを使用することで、何百万もの接続デバイスがあるとは思わないでしょう）。たとえば、254.0.0.1は（合法的に）実際のデバイスを参照することはありません。
- これが必要なマシンでは、ドロップオンリーターゲットを追加できます。たとえば、上記のような未使用のアドレスを使用すると、
iptables -I OUTPUT -d 254.0.0.0/8 -j DROPによって、ゲートウェイに迷惑をかけたり、実際のネットワークインターフェイスでトラフィックが発生したりすることなく、その「ネットワーク」に送信されたものが確実に破棄されます。
繰り返しになりますが、便利だと思う場合でも、実際にはこれらのいずれも必要としないことが多々あります。そうではなく、混乱を招き、自明ではないため、問題を解決するための良い解決策ではありません。
あなたの質問を脇に置いて、 「プロトコルを破棄する」 を使うのはどうですか？
テスト範囲
私はおそらく文書や例で使うために "TEST-NET"アドレス範囲の1つ を提案するでしょう。それは公に使われるべきではありません " 。
192.0.2.0/24 198.51.100.0/24 203.0.113.0/24
"Bogon"（偽/偽）の範囲
ここでどこを言うべきかわからない、これはインターネットゲートウェイが提供するであろう慣習ではないように思われる。
ローカルレンジ
ループバックアドレス範囲127.0.0.0/8、例えば127.0.0.255もあります。そこに物事、特にローカルマシン上のサービスが存在する可能性はありますが、少なくともネットワーク上のどのマシンにも干渉しません（他のネットワークサービスによって裏付けされているネットワークサービスがない限り）。
127.0.0.0/8
違法な目的地の範囲
おそらく、不正なアドレス0.0.0.0を使用することもできますが、0.0.0.0/8は 「現在へのブロードキャストメッセージに使用される（ "this"）」 のために予約されています。その上で。
0.0.0.0/8
Null Route のWikipediaページには、次のように記載されています。
ヌルルートは通常、特別なルートフラグを使用して設定されますが、パケットを0.0.0.0などの不正なIPアドレス、またはループバックアドレスに転送することによっても実装できます。
考慮すべき1つの事柄（特定のシナリオでは問題になる場合もあれば、そうでない場合もあります）は、存在しないIPアドレスにトラフィックをリダイレクトすると、ルーターやホストがになる可能性があります。そのアドレスを継続的にARP処理しようとします。これは悪いことになる可能性があります。
このファントムアドレスにスタティックARP - > IPバインディングを設定すると、システムは常に解決されたARPエントリを持ち、そのARPアドレスでパケットを送信するだけです（これは偽物です）。トラフィックは実際にはどこにも上陸しません。
繰り返しますが、これはあなたが実際に望んでいることではないかもしれませんが、検討する価値があります。