Linux ネットワーキングの必須コマンド

現代の Linux では、ネットワーキングの必須コマンドは iproute2 スイートに含まれています。ip はインターフェースとルートを調べ、ss はソケットとリッスン中のポートを一覧表示し、ip neigh は ARP キャッシュを読み取ります。

新しいコンテナに shell で入り、まったくの習慣で ifconfig と打ち込んで command not found が返ってきた経験があるなら、理由はこれです。マッスルメモリがバイナリよりも 10 年以上長生きしているわけです。

これらは古い net-tools のバイナリ（ifconfig、route、netstat、arp）を置き換えるものです。net-tools は Red Hat が「もう手を伸ばすべきではないコマンド」として挙げているもので、現行のディストリビューションではそもそもインストールされていないことも少なくありません。本リファレンスでは、コマンドを作業内容（インターフェースの確認、ルーティング、疎通確認、DNS、ポート、トラフィック）ごとに整理し、最後に症状からコマンドへとたどれるトラブルシューティングフローを一通り紹介します。

Linux で ifconfig、netstat、route を置き換えたものは何か？

net-tools は 2000 年代初頭から陳腐化した扱いとなっており、iproute2 が活発に開発されている後継です。openSUSE の net-tools-deprecated パッケージには、標準的な 1 対 1 の対応表が記載されています。

iproute2 形式を優先してください。最小構成のコンテナや新規サーバーではレガシーバイナリが存在しない場合があるため、ifconfig や netstat を呼び出すスクリプトは command not found で動作しなくなります。

インターフェースとアドレス

ip addr（エイリアスは ip a）は、すべてのインターフェースと割り当てられた IPv4／IPv6 アドレスを表示します。ifconfig の現代版に相当します。インターフェースの up／down には ip link を、マシンの IP アドレスだけを出力するには hostname -I を使います。

ip addr                       # all interfaces + addresses (alias: ip a)
ip addr show eth0             # one interface only
sudo ip link set eth0 down    # take an interface offline
sudo ip link set eth0 up      # bring it back online
hostname -I                   # print all IP addresses, space-separated

単一のバイナリである ip が、アドレス、インターフェース、ルーティング、トンネルまでをカバーします。hostname -I は、ip addr の出力をパースせずにスクリプトでアドレスを取得する最短の方法です。

ルーティング

ip route はカーネルのルーティングテーブルを表示・編集するコマンドで、レガシーな route コマンドを置き換えます。引数なしで実行すれば、トラフィックの行き先とデフォルトゲートウェイが確認できます。

ip route                                      # view the routing table
ip route get 1.1.1.1                          # show which route a destination uses
sudo ip route add 10.0.0.0/24 via 192.168.1.1 # add a static route

ip route get は「この宛先はどのインターフェースとゲートウェイを使うのか？」に素早く答える手段です。あるネットワークからは到達できるのに別のネットワークからは到達できない、といった場面で役立ちます。

疎通確認と経路

ping はホストが応答するかどうかをテストし、traceroute と mtr はパケットがどこを通り、どこで途絶えるのかを示します。ping は必ず回数を指定して実行してください。ping -c 5 example.com は 5 パケットを送信して終了し、延々と実行され続けることはありません。

ping -c 5 example.com     # send 5 ICMP echoes, then stop
traceroute example.com    # trace the hop-by-hop path
sudo traceroute -T -p 443 example.com  # trace using TCP to port 443
mtr example.com           # live ping + traceroute in one view

何も指定しなければ、traceroute は 30 ホップで打ち切り、各プローブのサイズは IPv4 で 60 バイト、IPv6 で 80 バイトになります。-T を付けるとデフォルトの UDP プローブが TCP に切り替わり、デフォルトのプローブを破棄するファイアウォールも通過できます。mtr example.com は ping と traceroute を 1 つのライブビューに統合するため、ホップごとのパケットロスがリアルタイムに更新される様子を観察できます。なお、traceroute と mtr はプリインストールされていないことが多いため、sudo apt install mtr traceroute（Debian／Ubuntu）または sudo dnf install mtr traceroute（RHEL／Fedora）で追加してください。

DNS ルックアップ

dig は DNS クエリの主力ツールです。+short は出力を回答部分だけに絞り込み、-x は逆引き、@server は特定のリゾルバを指定します。nslookup と host はより簡潔に同じ領域をカバーします。

dig +short example.com            # just the resolved A record(s)
dig -x 8.8.8.8                    # reverse lookup: IP -> hostname
dig +short example.com @8.8.8.8   # query Google's public resolver directly
host example.com                  # terse forward/reverse lookup
nslookup example.com              # interactive-capable lookup

リゾルバを明示的に指定してクエリすることが、切り分けの決め手になります。DNS の障害とローカルリゾルバの不具合を区別するには dig +short example.com @8.8.8.8 を実行します。これで名前解決できるのにデフォルトのリゾルバではできない場合、問題はドメイン側ではなくリゾルバ側にあります。

Linux でポートを使用しているプロセスを特定するには？

ポートを掴んでいるプロセスを見つけるには、ss -tulnp | grep :8080 を実行します。-p フラグは、そのソケットを所有する PID とプロセス名を出力します。サーバーやコンテナが bind できないときの「port already in use」エラーは、これで解決できます。

ss -tlnp                    # all listening TCP sockets + owning process
ss -tulnp | grep :8080      # what's bound to port 8080 (TCP + UDP)

フラグの意味は t=TCP、u=UDP、l=listening（リッスン中）、n=numeric（名前解決なし）、p=process です。自分が所有していないソケットのプロセス名を表示するには root 権限が必要なので、sudo を付けてください。ss は netstat の現代版であり、netstat の man ページ自体が、このコマンドはほぼ陳腐化していると述べ、多数のソケットを列挙する必要がある高負荷サーバーでは netlink ベースの ss を使うよう案内しています。速度差はここから生じます。ss は netlink 経由でカーネルに問い合わせるのに対し、netstat は /proc/net 配下のテキストファイルを読み取るためです。PID が判明したら、kill <pid> で停止します。

トラフィックと転送

tcpdump はライブでパケットをキャプチャし、curl、wget、nc は到達性のテストとファイル転送を担います。上位レイヤのツールで答えが得られないときは、tcpdump で回線上に実際に何が流れているのかを確認しましょう。

sudo tcpdump -i eth0 port 80    # capture HTTP traffic on eth0
curl -v https://example.com     # verbose HTTP request, headers and TLS
wget -O out.html https://example.com  # download to a file
nc -zv example.com 443          # check if a port is open (no data sent)

tcpdump でインターフェースからパケットを取得するには昇格した権限が必要で、実際には sudo で実行する（あるいはバイナリに CAP_NET_RAW を付与する）ことになります。nc -zv host port は最速の 1 行ポートチェックです。-z はデータを送らずにスキャンし、-v は結果を報告します。Docker Desktop では host.docker.internal がそのまま名前解決されるため、nc -zv host.docker.internal 8080 でコンテナ内部からホストに到達できます。Linux 版 Docker Engine では自分でマッピングする必要があり、コンテナ起動時に --add-host=host.docker.internal:host-gateway を指定します（Docker Engine 20.10 以降でサポート）。

トラブルシューティングフロー：症状からコマンドへ

症状を判断経路に対応づけ、自分のマシンから外側へ向かって切り分けていきます。

• ホストに到達できない → ping -c 5 host で到達性をテストし、次に traceroute host または mtr host でパケットが途絶える箇所を特定し、ip route で有効なルートとゲートウェイがあることを確認します。
• 「Port already in use」 → ss -tulnp | grep :<port> で所有プロセスの PID を見つけ、kill <pid> するか別のポートにバインドします。
• DNS が失敗する → 自分のリゾルバに対して dig +short example.com を実行し、続いてパブリックリゾルバに対して dig +short example.com @8.8.8.8 を実行します。パブリック側のクエリだけが解決するなら、原因はローカルリゾルバです。
• 回線が遅い、または飽和している → sudo iftop または bmon で接続ごとの帯域幅をリアルタイムに確認します（sudo apt install iftop bmon でインストール）。

これらの連鎖に含まれる各コマンドは、1 つのレイヤ（リンク、ルート、名前解決、ソケット）を確認または除外していきます。推測に頼らずに障害箇所を絞り込めます。

まずは iproute2 のツール（ip、ss、ip neigh）に手を伸ばし、net-tools はそれがまだ同梱されているシステムでのフォールバックに留めましょう。そして次に bind が失敗したりホストが応答しなくなったりしたときは、上記の症状からコマンドへの経路をたどってください。

FAQ

ss と netstat の違いは何ですか。互換的に使えますか？

互換的には使えません。ss が現代の後継であり、netstat の man ページ自体がこのコマンドをほぼ陳腐化していると説明し、代わりに ss を案内しています。ss は netlink 経由でカーネルにソケットデータを問い合わせるのに対し、netstat は /proc/net 配下のテキストファイルを読み取ります。そのため、ソケット数の多いサーバーでは ss のほうが安定して性能を発揮します。どちらも接続とリッスン中のポートを一覧表示しますが、netstat はインストールされていない可能性があるため、スクリプトでは ss を呼び出すべきです。

Linux で特定のポートを使用しているプロセスを見つけて終了させるには？

ss -tulnp | grep :8080 を実行して、そのポートにバインドされているソケットを見つけます。-p フラグは所有者の PID とプロセス名を出力します。自分が所有していないソケットのプロセス名を表示するには root 権限が必要なので、sudo を付けてください。PID が判明したら、kill に続けて PID を指定して停止します。これにより、サーバーやコンテナが bind できないときの「port already in use」エラーが解消されます。

サーバーで ifconfig が command not found を返すのはなぜですか？

ifconfig は net-tools パッケージに含まれており、多くの現代的なディストリビューションではデフォルトでインストールされなくなったためです。Red Hat は iproute2 が置き換えるコマンドとして ifconfig と route を挙げており、RHEL はバージョン 7 以降、Debian は Debian 9 以降、デフォルトインストールから net-tools を外しています。インターフェースとアドレスの確認には代わりに ip addr を使うか、レガシーなスクリプトが旧バイナリを必要とする場合は net-tools を手動でインストールしてください。

DNS の問題がドメイン側なのかローカルリゾルバ側なのかを見分けるには？

dig +short example.com @8.8.8.8 でパブリックリゾルバに直接クエリし、デフォルトのリゾルバを使う dig +short example.com の結果と比較します。パブリック側のクエリは解決するのにデフォルトでは解決しない場合、原因はドメインではなくローカルリゾルバです。@server 構文は dig に設定済みリゾルバをバイパスさせるため、システム設定を一切変更せずに障害箇所を片側に切り分けられます。

traceroute や mtr がシステムにインストールされていないのはなぜですか？

traceroute、mtr、whois、nmap、iftop は最小構成やデフォルトのインストールに含まれていないことが多く、そのため command not found が返ります。Debian と Ubuntu では sudo apt install mtr traceroute、RHEL と Fedora では sudo dnf install mtr traceroute でインストールしてください。デフォルトで iproute2 に同梱される ip や ss とは異なり、これらの経路調査・スキャン系ツールは通常パッケージマネージャーで追加する必要があります。