ipコマンド入門

連載ナビ

この連載は「Linuxを使えるようになる」ではなく、「Linuxがどう動いているのか」を理解するための実践シリーズです。

今回は Linuxを理解する 〜 LFSで学ぶLinux内部構造 〜 の Part 6 / 第2回として、仕組みのつながりを意識しながら学びます。

• 前回: Linuxネットワーク基礎
• 次回: SSHサーバーを構築する

—

いま覚えるべきは ifconfig ではなく ip コマンド

ネットワークの入門記事では、いまだに ifconfig や netstat を見かけます。しかし結論から言うと、現在のLinuxで標準なのは iproute2 パッケージに含まれる ip コマンド（と ss）であり、新しく覚えるならこちら一択です。

ip コマンドは「オブジェクト + 操作」という統一された文法を持っています。

ip <オブジェクト> <操作>

ip addr  show   … IPアドレス（addressの略。ip a でも可）
ip route show   … ルーティングテーブル（ip r でも可）
ip link  show   … NICのリンク状態（L2レベル）

前回学んだ「インターフェース・経路」の確認が、この1コマンド系統で完結します。確認（show）だけでなく、アドレスの付与（ip addr add）や経路の追加（ip route add）まで同じ文法で書けるのが特徴です。

net-tools は開発が停滞し、カーネルの新機能に追従できていないから

なぜ ifconfig から ip へ移行が進んだのか。理由は歴史的な経緯と技術的な限界の両方にあります。

• ifconfig / route / netstat は net-tools というパッケージのコマンド群で、開発が長く停滞しています。多くのディストリビューションでは既定でインストールされず、Debian/Ubuntu系では ifconfig を打つと Command 'ifconfig' not found になることも珍しくありません
• 一方 iproute2 は、カーネルと netlink というインターフェースで通信する現行世代のツール群で、ポリシールーティング、1つのNICへの複数アドレス付与、ネットワーク名前空間（network namespace）といった、いまのカーネルが持つ機能を正しく扱えます

3つ目の点は、この連載の読者に特に関係があります。Dockerのコンテナネットワークは、ネットワーク名前空間と仮想インターフェース（veth）で実現されており、これを操作・観測できるのは ip コマンド側だからです（ip netns、ip link で veth や docker0 が見えます）。コンテナ時代のインフラを触るなら、ip コマンドは避けて通れません。

対応関係を整理しておきます。

旧（net-tools）	新（iproute2）	確認できるもの
ifconfig	ip addr / ip link	IPアドレス、インターフェース状態
route -n	ip route	ルーティングテーブル
netstat -ltnp	ss -ltnp	ソケット（待ち受けポートなど）
arp -a	ip neigh	ARPテーブル（近隣キャッシュ）

ip link と ip addr — レイヤーを分けて読む

ip コマンドの良さは、L2（リンク）とL3（IP）を別のオブジェクトとして見られることです。まずL2から。

ip link show

2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 96:3c:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

注目点は2つです。

• state UP と LOWER_UP — 「管理上有効」かつ「物理的（仮想的）にリンク確立」。ケーブル抜けや仮想NICの障害では LOWER_UP が消え、state DOWN になります
• link/ether — MACアドレス。IPアドレスはここには出ません（L2の情報だけを表示するため）

次にL3です。

ip addr show enp0s1

L2の情報に加えて inet 192.168.64.5/24 のようなIPアドレス行が表示されます。「リンクはUPなのにIPアドレスが付いていない」と分かれば、原因はDHCPやネットワーク設定側だと即座に絞れます。ifconfig はこの2層を混ぜて表示していたため、こうした切り分けの視点が持ちにくいコマンドでした。

ip route get — 「この宛先に、実際どう出ていくか」をカーネルに聞く

ip route show はテーブル全体を表示しますが、実務でより便利なのが ip route get です。

# 8.8.8.8 宛のパケットが、どの経路・どのインターフェース・どの送信元IPで出ていくか
ip route get 8.8.8.8

8.8.8.8 via 192.168.64.1 dev enp0s1 src 192.168.64.5 uid 1000

これは「ルーティングテーブルを人間が読んで推測した結果」ではなく、カーネルが実際に行う経路選択の結果そのものです。読み方は次の通りです。

• via 192.168.64.1 — ゲートウェイ経由で出ていく
• dev enp0s1 — 使われるインターフェース
• src 192.168.64.5 — パケットに載る送信元IP

NICが複数あるサーバーや、VPN接続時に「どっちの経路で出ているのか分からない」場面で、一発で答えが出ます。経路が全く無い宛先を指定した場合は RTNETLINK answers: Network is unreachable と表示され、これ自体が「defaultルートが無い」ことの診断になります。

観測は ip addr / ip route / ip link の3系統に統一する

現在のLinuxのネットワーク観測は iproute2（ip と ss）が標準であり、ip link（L2）→ ip addr（L3）→ ip route（経路）とレイヤーを分けて確認することで、問題の層を素早く特定できる——これが今回の結論です。

道具が揃ったので、次回はいよいよ実際のサービスを立てます。Linuxサーバー運用の入り口であるSSHサーバーを構築し、ss で待ち受けを確認しながら、接続までの流れを内部構造から理解します。

図解テキスト

ip link   デバイス状態（L2: state UP / MACアドレス）
ip addr   インターフェースのIP（L3: inet x.x.x.x/24）
ip route  経路（default via ... が外向きの生命線）

ip route get <宛先IP> = カーネルの経路選択をその場で確認

この回で実行するコマンド

上から順番に実行すれば、この回の内容を体験できます。

まずはそのままコピペして実行し、次に1行ずつ意味を確認してください。

ip link show
ip addr show
ip route show
ip route get 8.8.8.8

ハンズオン手順

1. ターミナルを開いて、上のコマンドを1行ずつ実行する

2. ip link show の出力から、自分の主要NICの名前と state をメモする

3. ip route get 8.8.8.8 の出力を via / dev / src に分解して読む

4. ifconfig と netstat を打ってみて、インストールされているかどうかも確認する

5. エラーが出たら、そのエラーメッセージをそのまま残す

チェックポイント

• コマンドが最後まで実行できた
• ip link と ip addr が見ているレイヤーの違いを説明できる
• ifconfig → ip addr、route -n → ip route、netstat → ss の対応を言える
• 次の回に進む前に、分からない単語を1つ調べた

今回理解できたこと

• 現在の標準は net-tools ではなく iproute2（ip / ss）
• ip は netlink 経由でカーネルと通信し、名前空間などの現行機能を扱える
• ip route get でカーネルの実際の経路選択を直接確認できる