はじめに
ネットワークのトラブルシューティングは、各層を一つずつ確認すると容易になります。まずホストの識別情報を確認し、次にインターフェースとアドレス、ルートの選択、基本的な到達性、名前解決、待ち受けソケット、アプリケーションの応答、最後にローカルのファイアウォールポリシーを確認します。
この実験では、Ubuntu ホスト上でこの順序に従って確認を進めます。あらかじめ用意された HTTP サービスがループバックのポート 8088 のみで待ち受けているため、ss、curl、UFW ルールの練習に安全に利用できます。ホストのインターフェース設定、デフォルトルート、DNS 設定、SSH アクセスは変更しません。
ホストを識別する
このステップでは、ホスト名と、このマシンを識別するためにプログラムが利用するローカルの名前レコードを確認します。
実験用ワークスペースに移動します。
cd /home/labex/project/network-lab
現在のホスト名を表示します。
hostname
systemd が認識している静的ホスト名、一時ホスト名、オペレーティングシステムの識別情報を表示します。
hostnamectl
Static hostname は設定済みのホスト名です。クラウドのトレーニングマシンでは、起動時に一時ホスト名が割り当てられることがあります。
ローカルのホスト名マッピングを確認します。
cat /etc/hosts
ループバック名 localhost、127.0.0.1、::1 は、外部ネットワークを経由せずにこの同じホストを示します。ホストに割り当てられた IP アドレスを簡潔に表示します。
hostname -I
ホスト名とアドレス一覧を保存します。
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
インターフェースと IP アドレスを確認する
このステップでは、ネットワークインターフェース、リンク状態、IPv4 アドレス、プレフィックス、アドレスのスコープを確認します。
リンク情報を簡潔に表示します。
ip -brief link
lo はループバックインターフェースです。eth0 や ens... という名前の別のインターフェースは、通常、仮想マシンをネットワークに接続します。UP は、そのインターフェースが管理上有効になっていることを示します。
アドレス情報を簡潔に表示します。
ip -brief address
192.0.2.10/24 のようなアドレスは、IPv4 アドレスとプレフィックス長を組み合わせたものです。プレフィックスは、ローカルネットワークを識別する先頭ビットの範囲を表します。
ループバックの詳細を確認します。
ip address show dev lo
IPv4 アドレス 127.0.0.1/8 の scope host は、このアドレスがホスト内部でのみ有効であることを示します。デフォルトルートで使用されるインターフェースを確認します。
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
ifconfig は古いインターフェースツールですが、既存の運用手順書やトラブルシューティング資料では今も使われています。先ほど確認した最新の ip 出力と比較します。
ifconfig
従来形式の表示も保存します。
ifconfig > ifconfig-addresses.txt
インターフェースの概要を保存します。
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
ルーティングテーブルを読む
このステップでは、デフォルトゲートウェイを確認し、特定の宛先に対して Linux がどのルートを使用するかを調べます。
メインのルーティングテーブルを表示します。
ip route
接続済みルートは、直接接続されたネットワークを示します。default via で始まる行は、より具体的なルートが一致しない場合に使用されます。
パブリックな宛先へ到達する場合にカーネルが使用するルートを確認します。このコマンドはパケットを送信せず、選択されたゲートウェイ、インターフェース、送信元アドレスを表示します。
ip route get 1.1.1.1
デフォルトゲートウェイとインターフェースを抽出します。
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
ルートの概要を保存します。
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
ネットワーク到達性を確認する
このステップでは、ping を使って、より遠い境界へ段階的に到達性を確認します。ただし、ネットワークによっては診断用パケットがブロックされる場合があることにも注意してください。
まずループバックを確認します。-c 2 は 2 回の要求を送信し、-W 2 は各応答を最大 2 秒待機します。
ping -c 2 -W 2 127.0.0.1
ループバックのテストに成功すると、ローカルの IP スタックが応答していることを確認できます。次に、デフォルトゲートウェイを取得して確認します。
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
代替メッセージが表示されても重要な意味があります。ルーターはトラフィックを転送できても、ping には応答しない場合があるためです。DNS に依存せず、パブリック IP アドレスを確認します。
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
外部ネットワークのポリシーに左右されない、安定したローカル接続結果を保存します。
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
ホスト名の名前解決を確認する
このステップでは、リゾルバーの設定を確認し、ホスト名をアドレスに変換します。
標準的な Linux アプリケーションが使用するリゾルバー設定ファイルを表示します。
cat /etc/resolv.conf
通常は、1 行以上の nameserver 行が含まれています。systemd-resolved を使用するホストでは、そのアドレスが外部 DNS サーバーそのものではなく、ローカルのスタブリゾルバーを示している場合があります。
システム全体の名前サービス設定を通じて、ローカル名を解決します。
getent hosts localhost
getent は /etc/nsswitch.conf に従うため、/etc/hosts、DNS、その他の設定済みソースを組み合わせて利用できます。外部名を解決し、IPv4 ソケットアドレスを取得します。
getent ahostsv4 example.com
IP アドレスへの ping に成功してもこの名前解決に失敗する場合は、リゾルバーの設定または DNS への到達性を確認します。最初に解決された IPv4 レコードを保存します。
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
待ち受けポートと HTTP 応答を確認する
このステップでは、待ち受け中の TCP ソケットと、それを所有するプロセスの対応関係を確認し、アプリケーションプロトコルをテストします。
用意されたデモサービスは、ループバックのポート 8088 で待ち受けています。ss を使って待ち受け中の TCP ソケットを確認します。-l、-t、-n、-p は、それぞれ待ち受け、TCP、数値形式のアドレス、プロセス情報を意味します。
sudo ss -ltnp | grep ':8088'
127.0.0.1:8088 を探します。ループバックにバインドされているため、このサービスに到達できるのはこのホストからだけです。
ソケットの背後で動作しているサービスプロセスを確認します。
systemctl status labex-network-demo.service --no-pager
curl -i を使って、HTTP 応答のヘッダーと本文を表示します。
curl -i http://127.0.0.1:8088/
HTTP の 200 OK ステータスは、ポートが開いているだけでなく、アプリケーションが HTTP リクエストを受け付け、コンテンツを返したことを示します。サイレントモード -s を使い、応答本文だけを保存します。
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
アクセスを維持して UFW を有効化する
このステップでは、UFW の状態を確認し、リモート管理アクセスを維持し、練習用サービスのポートを許可してからファイアウォールを有効化します。
UFW は Linux のパケットフィルタリングルールを管理するフロントエンドです。現在の状態を確認します。
sudo ufw status verbose
準備スクリプトにより、UFW は無効でルールが初期化された状態になっています。ホストのファイアウォールをリモートから有効化する前に、利用中の管理経路を許可してください。この VM は SSH に TCP ポート 22 を使用します。
sudo ufw allow 22/tcp
次に、練習用サービスのポートへの受信 TCP 通信を許可します。
sudo ufw allow 8088/tcp
有効化する前に、準備した変更を確認します。
sudo ufw show added
対話式の確認を省略して UFW を有効化します。
sudo ufw --force enable
ファイアウォールが有効で、両方の許可ルールが存在することを確認します。
sudo ufw status verbose
サービスはループバックにバインドされているため、ファイアウォール変更後にローカルからテストします。
curl -fsS http://127.0.0.1:8088/
有効な状態を確認可能な結果として保存します。
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
順序が重要です。管理経路を維持し、必要なサービスルールを追加し、ファイアウォールを有効化したら、ポリシーとアプリケーションの到達性をすぐに確認します。本番ホストでは別の SSH ポートを使用する場合があるため、ポート 22 と決めつけず、実際の管理経路を確認してください。
まとめ
ホストの識別情報、インターフェースと IP アドレス、ルートの選択、到達性、名前解決、待ち受けソケット、HTTP 応答という、構造化された Linux ネットワーク診断の流れを確認しました。各層が異なる問いに答えること、そしてある境界で問題が発生すると、次に調べるべき範囲を絞り込めることを学びました。
また、UFW の状態を確認し、リモートアクセスを危険にさらすことなく、ループバックに限定したルールを安全に管理しました。これらの習慣は、広範囲で影響の大きい変更を避けながら、ネットワークサービスの診断と保護を行うための基礎になります。
