Linuxシステムにおけるネットワークの設定確認、変更、監視、および接続検証は、運用保守の基盤となる重要な作業です。本稿では、従来のifconfigやnetstatから現代的なipコマンドとssツールへと移行する実践的手法を中心に、構成ファイルの編集からリアルタイム診断までを体系的に解説します。
1. ネットワークインターフェースの状態確認
現在のネットワークデバイス情報を取得するには、ipコマンドが推奨されます:
ip link show # リンク層の状態(UP/DOWNなど)
ip address show # IPv4/IPv6アドレス、サブネットマスク
ip -br addr show # 簡潔な一覧表示(例:ens33 UP 192.168.10.9/24)
従来のifconfigはnet-toolsパッケージに含まれ、CentOS/RHEL 8以降では非推奨です。必要に応じてインストール可能ですが、代替としてipの使用が標準化されています。
特殊なインターフェース例:
lo:ループバックデバイス(127.0.0.1)。ローカルサービスのテストに利用。virbr0:libvirtによるNATブリッジ。仮想マシンの外部通信を仲介し、デフォルトで192.168.122.0/24網を提供します。
2. 永続的なネットワーク設定の編集
RHEL/CentOS系では、各NICの設定は/etc/sysconfig/network-scripts/ifcfg-<名前>ファイルで管理されます。以下はens33の静的IP設定例です:
DEVICE=ens33
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.10.9
PREFIX=24
GATEWAY=192.168.10.1
DNS1=8.8.8.8
DNS2=114.114.114.114
NM_CONTROLLED=no
注意点: NM_CONTROLLED=no を明示することで、NetworkManagerによる干渉を抑制し、systemctl restart networkによる即時適用を確実にします。また、PREFIX(例: 24)はNETMASKのCIDR表記への置換であり、より現代的な記述です。
3. 実行時ネットワーク制御
3.1 インターフェースの有効化/無効化
ip link set ens37 down # 物理リンクを停止
ip link set ens37 up # 再起動
# または
nmcli connection down ens37
nmcli connection up ens37
3.2 仮想サブインターフェースの追加
既存IPを維持したまま追加アドレスを割り当てる場合:
ip address add 192.168.10.20/24 dev ens37 label ens37:0
この方法は、単一NIC上で複数のサービスを異なるIPでホストする際に有用です。
3.3 ホスト名の管理
# 一時変更(再起動で戻る)
hostname temp-host
# 永続変更(systemd環境)
hostnamectl set-hostname prod-server
echo "prod-server" > /etc/hostname
ホスト名解決には/etc/hostsファイルも併用可能です:
127.0.0.1 localhost localhost.localdomain
192.168.10.9 prod-server
3.4 ルーティングテーブルの操作
デフォルトゲートウェイと静的ルートを直接操作します:
# 現在のルート表示
ip route show
# 新規静的経路追加(192.168.3.0/24へは192.168.10.1経由)
ip route add 192.168.3.0/24 via 192.168.10.1 dev ens33
# デフォルトゲートウェイ設定
ip route replace default via 192.168.10.1
# 削除
ip route del 192.168.3.0/24
4. 接続状態の詳細監視
4.1 ssコマンドによる高速ソケット分析
ssはnetstatの後継であり、カーネルのtcp_diagモジュールを直接利用するため、大量接続時でも高速です:
# 監視中のTCPポート一覧(プロセス名付き)
ss -tlnp
# SSH接続中のESTABLISHED状態のみ抽出
ss -tn state established | grep ':22'
# タイムアウト・再送信情報付き表示
ss -tio state established
主なオプション:
-t: TCPのみ-u: UDPのみ-n: 名前解決をスキップ(数字表示)-l: LISTEN状態のみ-p: 所有プロセス表示(root権限必須)-o: タイマー情報(RTT, retransmission countなど)
4.2 netstatとの比較(補足)
互換性のために残るnetstatは、以下の組み合わせが定番です:
netstat -tuln # 全LISTENポート
netstat -anp | grep :80 # 特定ポートの全接続
ただし、ssが同等以上の機能を提供し、パフォーマンスも優れるため、新規導入時はssを優先すべきです。
5. 接続性の検証とトラブルシューティング
5.1 pingによる基本接続確認
ping -c 4 192.168.10.1 # 4回送信
ping -c 3 -W 2 www.google.com # タイムアウト2秒
ping -I ens33 192.168.10.1 # 特定インターフェース経由
応答がない場合の主な原因:
Destination Host Unreachable→ L2/L3到達不可(ARP失敗、物理障害)Network is unreachable→ ルーティングテーブルに該当経路なしRequest timeout→ ファイアウォールによるICMP遮断、中間ノードの過負荷
5.2 tracerouteによる経路可視化
traceroute -n 192.168.3.10 # DNS解決を回避
mtr --report 8.8.8.8 # 連続モニタリング(mtrパッケージ必要)
tracerouteは、各ホップのRTTとパケットロス率を示すため、どこで遅延や遮断が発生しているかを特定するのに不可欠です。
3.3 DNS解決の検証
resolv.confの設定確認と、実際の名前解決動作の検証を行います:
# 設定確認
cat /etc/resolv.conf
# DNSサーバーへの直接問い合わせ(dig)
dig +short www.baidu.com A
# 逆引き
dig -x 119.75.218.70 +short
# 高度な診断(名前解決フローのトレース)
nslookup -debug www.example.com
DNS解決順序は通常:/etc/hosts → resolv.confに記載されたDNSサーバー。そのため、/etc/hostsへのエントリ追加は、頻繁にアクセスする内部ホストの解決遅延を削減する有効な手段です。