
172.31.0.0/16
今日、サブネット内のアドレスに ping して ICMP 応答を得られることを偶然発見しました。ランダムにいくつか試してみましたが、常に応答がありました。ルーティング テーブルと暫定的な を確認した後traceroute
、関連するパケットがローカル ネットワークから出ている、つまり ISP に向かっているように見えます。私のローカル ネットワークは、サブネットの一部である異なる IP 範囲を使用しており、と192.168.0.0/16
には Docker 関連のインターフェイスがありますが、 はありません。172.17.0.0/16
172.19.0.0/16
172.31.0.0/16
私の理解では、それは依然としてIANA 予約済みアドレス空間172.31.0.0/16
の一部であるはずです。172.16.0.0/12
このサブネットの範囲が世界的な IP アドレス不足またはその他の理由により短縮された可能性があるかどうかを確認するために Web 検索を試みましたが、その仮説を裏付けるものは何も見つかりませんでした。
今は、単に睡眠不足で基本的なことを見落としているだけなのか、それともネットワーク設定に深刻な問題があるのか疑問に思っています。
答え1
172.31.0.0/16 が RFC1918 IP アドレス空間の一部であることは正しいです。ルーターは、おそらく、接続されていないルートへのトラフィックをデフォルト ゲートウェイである ISP にダンプするように設定されています。トラフィックはそこで停止するはずです。
ただし、ISP がこのアドレス範囲をルーティング可能にしているようです。過去に他の ISP でもこのようなことがありました (たとえば、Tele2 は IANA によって割り当てられる前にバックボーンとして 1.0.0.0/8 を使用していました)。
いずれにせよ、あなた(およびあなたのISP)はおそらく実装する必要があるでしょうボゴンフィルタリングおよび/または火星のフィルタリングネットワークの境界で。一般家庭の消費者にとっては許容範囲ですが、ISP はもっとよく理解しているはずです。
この問題を回避するには、ルーターのファイアウォールに基本的な送信フィルタを設定します(例10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16
:)。別の方法としては、ヌルルートまたはブラックホールルートこれらのアドレス範囲。ルータはパケットをドロップします。