【実務・中級編】サブネットマスクの計算とネットワークアドレス/ブロードキャストアドレスの算出 – ネットワーク基礎とWebセキュリティ実践ガイド

「そのサブネット、本当にあっていますか？」―ネットワークの境界を読み解くビット演算の極意

ネットワークエンジニアとして現場を歩いていると、いまだに「なんとなく」でサブネットマスクを決めている設計に出くわすことがあります。クラウド時代になり、VPCやサブネットの設計は自動化が進みましたが、パケットがどの境界線を越え、どこでドロップされるのかという「論理的な地図」を描けないエンジニアは、ひとたび障害が起きると迷子になります。

今日は、Web APIの疎通トラブルやインフラ設計の根幹となる「サブネット計算」を、単なる暗記ではなく、現場で使える武器として解説します。

—

1. ビット演算という「境界線」の正体

IPアドレスは単なる数字の羅列ではありません。192.168.1.0/24 と書いたとき、そこには「どこまでが身内（同一ネットワーク）で、どこからが外部（ルーターを越える先）か」という強固な境界線が引かれています。

なぜビット演算が必要か

コンピュータは10進数を理解しません。すべては0と1の世界です。例えば 255.255.255.0（/24）というマスクは、32ビットのうち最初の24ビットが「ネットワーク部」であることを示しています。

もしネットワークアドレスを求めたいなら、IPアドレスとサブネットマスクで AND 演算を行います。これがルーターのルーティングテーブルの裏側で行われている「住所特定」のメカニズムです。

—

2. 実践：ホスト数計算とネットワーク境界の特定

設計時に必ず直面するのが「このCIDRで何台のホストが収まるのか？」という問いです。

計算式は非常にシンプルです。

ホスト数 = 2^(32 - CIDR) - 2

なぜ -2 するのか？それは、ネットワークの先頭（ネットワークアドレス）と最後（ブロードキャストアドレス）をホストとして使えないからです。

Pythonで計算ツールを自作する

現場でサッと計算を確認したいとき、私はこんな小さなスクリプトを書いてコンテナ内で走らせます。

import ipaddress

def get_network_info(cidr):
    # ipaddressモジュールを使えば手計算のミスを防げる
    network = ipaddress.ip_network(cidr, strict=False)
    
    print(f"ネットワークアドレス: {network.network_address}")
    print(f"ブロードキャストアドレス: {network.broadcast_address}")
    print(f"利用可能なホスト数: {network.num_addresses - 2}")
    print(f"ホスト範囲: {list(network.hosts())[0]} - {list(network.hosts())[-1]}")

# 実行例: 10.0.0.0/27 の場合
get_network_info("10.0.0.0/27")

—

3. Web API設計におけるサブネットの勘所

APIサーバーを構築する際、セキュリティグループやACL（アクセスコントロールリスト）を絞ることは「ゼロトラスト」への第一歩です。しかし、境界の設定ミスは往々にして「なぜかAPIが叩けない」という悲劇を招きます。

curl で疎通確認をする際のTips

疎通確認を行う際、単に curl を叩くだけでなく、-v (verbose) オプションと --interface を併用して、意図したインターフェースからパケットが出ているかを確認しましょう。

# 特定のネットワークインターフェースを指定してAPIを叩く
# 意図しないサブネット経由になっていないか確認する重要な手順
curl -v --interface eth0 https://api.internal.example.com/health

もしここで Connection timed out が出るなら、それはパケットがサブネットの境界（ルーターやACL）で遮断されている可能性が高いです。その時こそ、先ほどの計算ロジックを思い出し、「この送信元IPは本当に許可されたネットワーク範囲内にあるか？」を確認してください。

—

4. 現場のシニアからのアドバイス：トラブルシューティングの作法

最後に、トラブルシューティングの現場で私が必ず守っている鉄則を伝授します。

1. 「デフォルトゲートウェイ」を疑え: ネットワークアドレスの計算が合っていても、ゲートウェイが間違っていればパケットは永遠に迷子になります。ip route コマンドでネクストホップを確認する癖をつけましょう。
2. バイナリで考える: 障害調査時、192.168.1.128/25 と 192.168.1.129/25 が同じネットワーク内にあるか即答できますか？これが即答できるエンジニアは、運用現場で圧倒的な信頼を得ます。
3. 自動化ツールを盲信しない: Terraformの cidrsubnet 関数などは非常に便利ですが、生成された結果が意図したセグメントに収まっているか、一度は手元で確認（検算）する余裕を持ってください。

ネットワークは「魔法」ではありません。すべてはパケットが辿る物理的・論理的なパスの積み重ねです。この基礎を疎かにせず、一つひとつのビットと向き合うことが、堅牢なシステムを作る唯一の道だと私は信じています。

皆さんの設計が、今日も完璧なルーティングでありますように。