午前2時。スマートフォンが鳴った。リードエンジニアからメッセージ:「サーバーがデータベースに接続できない、ネットワーク確認してくれ」。跳び起きてjump hostにSSH接続 — 基本的なマシンで、bash以外のツールは何も入っていない。昨日追加した新しいVLANと既存のIPレンジでsubnet overlapが起きているのではと疑った。
50人規模のオフィスと小規模データセンターのネットワークを管理していると、こういった状況は必ず最悪のタイミングで起こる — 深夜、ツールのないマシン、迫るdeadline。この記事では、ブラウザだけあれば即使えるよう事前にブックマークしているオンラインツールを紹介する。
Quick Start:5分で使える3つのツール
1. Subnet Calculator — CIDRの問題をすぐ解決
subnet conflictが疑われるときに最初に開くのがSubnet Calculatorだ。任意のIP/CIDRからnetwork range、broadcast address、利用可能なhost数を即座に計算できる。
使っているのはToolCraft Subnet Calculator — シンプルなUIで、100%ブラウザ上で動作しサーバーには何も送信しない。production環境のIPを入力する際に内部topologyを漏らしたくないときに重要なポイントだ。
例:データベースサーバーが10.10.20.5/24、アプリサーバーが10.10.20.100/24の場合、入力するとすぐに確認できる:
Network: 10.10.20.0
Broadcast: 10.10.20.255
Host range: 10.10.20.1 — 10.10.20.254
Usable: 254 hosts
どちらも/24、同じsubnet、内部routeだ。つまり問題はここではない。DNSの確認に移る。
2. DNS Lookup — hostnameが誤ったIPにresolveされるとき
コード内のconnection stringはIPではなくhostnameを使っていた。次に開いたのがdnschecker.org — hostnameを入力すると、世界20か所以上のlocationから同時にqueryしてくれる。DNS recordを変更した直後に非常に役立つ。どこまでpropagateされ、どこにまだ古いcacheが残っているかがすぐわかる。
結果:データベースのhostnameは先週のサーバーmigrate後にまだ更新されていない古いIPを指していた。午前2時23分、case closed。
3. IP / Subnet Mask Converter — チームが複数のnotationを使うとき
よくあるシチュエーション:firewall ruleは10.10.20.0/255.255.255.0形式で書かれているのに、AWS security groupはCIDR形式の10.10.20.0/24を要求する。subnet mask ↔ CIDR prefixの変換はcross-platformの設定時によく行う作業だ。
一番早いのはSubnet Calculatorをそのまま使うこと — 一方の形式を入力すれば両方outputされる。タブを追加で開く必要はない。
より深く:各ツールを適切なタイミングと用途で使う
Subnet Calculator — 正しい使い方
/24や/16の計算は最も基本的なuse caseに過ぎない。実際によく遭遇する問題はこちら:
- サブネット分割(subnetting):
192.168.10.0/24のレンジを4つのVLANに分割する必要がある場合。/26を計算 → 各subnet 62 host、ちょうど4 subnets。 - overlap確認:2つのrouteがoverlapしているか?それぞれ入力してhost rangeを比較すればわかる。
- VLSMプランニング:部門ごとに異なるsubnetサイズを割り当てる — 経理部門は10 host、開発部門は50 hostが必要なら、各グループに適切なprefixを選ぶ。
ToolCraftでは、IP + subnet maskまたはCIDR notationを入力すれば、ツールが自動変換して必要な情報をすべて表示する:network address、broadcast、first/last host、wildcard mask、binary representation。
binary表示は余分に見えるかもしれない。しかし、なぜ/24が256ではなく254 hostなのかをジュニアチームに説明するとき — binaryを開いて8 bit hostを直接指せば、口頭で説明するよりずっとわかりやすい。
DNS Lookup — 適切なツールを選ぶ
3つの異なる状況には3つの異なるツールが必要だ — 間違ったツールを使うと無駄に5分間debugしてしまう:
- 特定のrecord確認:terminalから
digまたはnslookupが最速。CLIが使えない場合はnslookup.io — domainを入力し、record type(A、MX、TXT、CNAME)を選択、任意のDNS serverからqueryできる。 - DNS propagation確認:record変更後にpropagateされたか確認したい — dnschecker.orgは複数locationからqueryし、どこがまだ更新されていないか確認できる。
- メールサーバーのデバッグ:MX record、SPF、DKIM、DMARC — mxtoolbox.comが最も充実したsuiteを持ち、blacklistの確認も同時にできる。
troubleshoot中にterminalからDNSをすばやくqueryする場合:
# A recordをquery
dig A db.internal.company.com
# 特定のDNS serverからquery
dig @8.8.8.8 A db.internal.company.com
# MX recordを確認
dig MX company.com +short
# 逆引き(PTR)
dig -x 10.10.20.5
# 残りのTTLを確認
dig A hostname.com +ttlid
IP Converter — よく使う変換
- Subnet mask ↔ CIDR prefix:
255.255.255.0=/24、255.255.254.0=/23、255.255.252.0=/22 - IP decimal ↔ hex:古いデバイスのlogやCisco configのhex出力を読む場合
- IPv4-mapped IPv6:dual-stackサーバーのlogに
::ffff:10.10.20.5が出る — これが実際にはIPv4であることを把握する必要がある
subnet mask ↔ CIDRの変換はToolCraftのSubnet Calculatorに入力するだけで処理できる。hex変換については、Pythonがどのオンラインツールよりも速い:
import ipaddress
# IPをintegerとhexに変換
ip = ipaddress.ip_address('10.10.20.5')
print(int(ip)) # 168497157
print(hex(int(ip))) # 0xa0a1405
# networkをparseしてhost rangeを計算
net = ipaddress.ip_network('10.10.20.0/24')
print(f"Usable hosts: {net.num_addresses - 2}")
print(f"First host: {next(net.hosts())}")
print(f"Last host: {list(net.hosts())[-1]}")
print(f"Broadcast: {net.broadcast_address}")
応用:troubleshoot時のツール組み合わせ
subnet overlapを自動チェックするスクリプト
新しいVLANをシステムに追加するとき、routerを設定する前にoverlapチェックスクリプトを実行する:
import ipaddress
def check_overlap(networks):
"""overlapしているsubnetのペアリストを返す"""
nets = [ipaddress.ip_network(n, strict=False) for n in networks]
conflicts = []
for i, n1 in enumerate(nets):
for n2 in nets[i+1:]:
if n1.overlaps(n2):
conflicts.append((str(n1), str(n2)))
return conflicts
# 使用中のsubnetリスト
existing = [
"10.10.10.0/24", # VLAN10 - オフィス
"10.10.20.0/24", # VLAN20 - サーバー
"10.10.30.0/24", # VLAN30 - DMZ
"192.168.1.0/24", # 管理用
]
new_subnet = "10.10.20.128/25" # 追加する新しいSubnet
conflicts = check_overlap(existing + [new_subnet])
if conflicts:
print("CONFLICT DETECTED:")
for c in conflicts:
print(f" {c[0]} overlaps {c[1]}")
else:
print("No conflicts. Safe to add.")
connectivityのdebug workflow
「接続できない」というチケットを受けたとき、このflowで確認する:
- Layerチェック:IPに直接pingできるか?できる → DNS/app layer。できない → network layer。
- Subnetチェック:sourceとdestinationは同じsubnetか?異なるsubnetの場合、gatewayにrouteがあるか?
- DNSチェック:hostnameはどのIPにresolveされるか?正しいか?複数locationから確認したか?
- Portチェック:serviceがlistenしているか?
#!/bin/bash
# クイックネットワークデバッグ — 結果をファイルに記録
TARGET="db.internal.company.com"
PORT=5432
LOGFILE="/tmp/netdebug-$(date +%Y%m%d-%H%M).log"
{
echo "=== $(date) ==="
echo "--- DNS ---"
dig A $TARGET +short
echo "--- Ping ---"
ping -c 3 $TARGET 2>&1
echo "--- Port $PORT ---"
nc -zv $TARGET $PORT 2>&1
echo "--- Route ---"
ip route get $(dig A $TARGET +short | head -1) 2>&1
} | tee $LOGFILE
echo "Log saved: $LOGFILE"
最後のteeがリアルタイムで確認しながらlogを保存するのに役立つ。翌朝にincident reportを書くときに必要なデータが揃っており、記憶から掘り起こす必要がない。
実践的なTips
必要になる前にブックマークしておく
使い慣れた4〜5つのツールで「Network Tools」ブックマークフォルダを作っておく。深夜2時に広告だらけのGoogle検索をしなくて済む。
筆者のブックマークフォルダ:
- ToolCraft Subnet Calculator — subnet/CIDR/wildcard、オフライン動作、内部IPを漏らす心配なし
- dnschecker.org — 複数locationからDNS propagation確認
- mxtoolbox.com — メールデバッグ、SPF/DKIM/DMARC、blacklist確認
- nslookup.io — カスタムDNS serverからのquery
機密性の高いIPを入力する際はclient-sideツールを優先する
オンラインツールにproductionのIPやhostnameを入力する前に確認すること:そのデータは相手のserverに送信されるのか?ToolCraftはすべての計算をブラウザ上のJavaScriptで実行する — 外部へのrequestは一切発生しない。内部IPレンジや機密topologyを入力する際に適している。
DNS checkerはその逆で — 複数locationからqueryする性質上、hostnameは相手のserverを経由する。public domainなら問題ないが、internal hostnameには使わないようにしよう。
一部の作業はCLIの方が速い
オンラインツールは適切な環境がないときに便利だ。しかしserverにSSH接続済みの場合は、ブラウザのタブを切り替えるよりipcalcの方が速い:
# ipcalcをインストール
apt install ipcalc # Debian/Ubuntu
yum install ipcalc # CentOS/RHEL
# 使用 — オンラインSubnet Calculatorと同等のoutput
ipcalc 10.10.20.5/24
# Output:
# Address: 10.10.20.5
# Netmask: 255.255.255.0 = 24
# Network: 10.10.20.0/24
# HostMin: 10.10.20.1
# HostMax: 10.10.20.254
# Broadcast: 10.10.20.255
# Hosts/Net: 254
どちらも同じ結果を出力する。オンラインツールはCLIが使えないときに、ipcalcはserverの中にいるときに使い分ければいい。

