Linuxのネットワーク確認コマンドまとめ｜ip・ping・ss・ip routeで障害を切り分ける

Linuxサーバを運用していると、 「通信できない」 というトラブルに遭遇することがあります。

たとえば、次のようなケースです。

このようなネットワークトラブルでは、 やみくもに設定を変更するのではなく、 現在のネットワーク状態を順番に確認する ことが重要です。

この記事では、Linuxでよく使用する ip・ping・ss・getent・dig などのコマンドを使いながら、 ネットワークの基本的な確認方法を学習します。

Linuxでは何を確認すればよい？

「通信できない」といっても、 原因は1つではありません。

ip addr：IPアドレスを確認する

まず確認したいのが、 Linuxサーバ自身に設定されている IPアドレスです。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP>
    inet 127.0.0.1/8 scope host lo

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP>
    inet 192.168.10.20/24 brd 192.168.10.255 scope global ens160

この例では、 ens160というネットワークインターフェースに 次のIPアドレスが設定されています。

ip aでも同じように確認できる

addrは省略できるため、 実務では次のように入力することも多くあります。

まずは、 「自分のサーバに想定したIPアドレスが設定されているか」 を確認しましょう。

ネットワークインターフェースの状態も確認する

IPアドレスだけでなく、 インターフェース自体が利用可能な状態かも重要です。

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP>

ここでは UPやLOWER_UP と表示されています。

ip route：ルーティングテーブルを確認する

自分のIPアドレスが正しくても、 宛先までの経路がなければ通信できません。

Linuxのルーティングテーブルは、 次のコマンドで確認できます。

$ ip route
default via 192.168.10.1 dev ens160
192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.20

重要なのが defaultです。

次の部分は、

「個別の経路がない宛先への通信は、192.168.10.1へ送る」 という意味です。

デフォルトゲートウェイがなければどうなる？

同一ネットワーク内とは通信できても、 別ネットワークへ通信できなくなる可能性があります。

ping：相手との疎通を確認する

IPアドレスとルーティングを確認したら、 次に 実際に通信できるか を確認します。

$ ping -c 4 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.621 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.558 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.601 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=64 time=0.574 ms

--- 192.168.10.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

この結果では、 4回送信して4回応答が返っているため、 192.168.10.1とのIPレベルの疎通は確認できた と判断できます。

-cで送信回数を指定できる

-c 4を付けることで、 4回送信したところでpingを終了できます。

スクリプトや障害調査では、 無制限にpingを送信し続けないよう 回数を指定することがあります。

pingは順番に試すと切り分けしやすい

いきなり遠くのサーバへpingするのではなく、 近い場所から順番に確認すると原因を切り分けやすくなります。

pingが通らない＝通信経路が壊れている、とは限らない

ここは初心者が特に注意したいポイントです。

pingでは ICMPというプロトコルを使用します。

サーバやファイアウォール側でICMPを拒否している場合、 Web通信などが正常でもpingには応答しないことがあります。

ss：待ち受けているポートを確認する

ネットワーク経路が正常でも、 サービスがポートを待ち受けていなければ接続できません。

そこで使用するのが ssコマンドです。

$ sudo ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*       users:(("sshd",pid=842,fd=3))
LISTEN 0      511    0.0.0.0:80          0.0.0.0:*       users:(("nginx",pid=1250,fd=6))
LISTEN 0      511    0.0.0.0:443         0.0.0.0:*       users:(("nginx",pid=1250,fd=7))

この例では、 次のTCPポートが待ち受けています。

ss -lntpのオプション

プロセス情報の表示には、 環境や対象によって管理者権限が必要になることがあります。

0.0.0.0:80と127.0.0.1:80の違い

ssでは、 ポート番号だけでなく どのアドレスで待ち受けているか も重要です。

getent hosts：名前解決を確認する

IPアドレスでは通信できるのに、 ホスト名では通信できない場合、 名前解決を確認します。

$ getent hosts example.com
2606:2800:220:1:248:1893:25c8:1946 example.com

getent hostsは、 Linuxシステムが利用する名前解決の仕組みに沿って ホスト情報を確認するときに便利です。

dig：DNSへ問い合わせて詳しく確認する

DNSの問い合わせ結果を詳しく確認したい場合は、 digを使用できます。

$ dig example.com

;; QUESTION SECTION:
;example.com.          IN      A

;; ANSWER SECTION:
example.com.     300   IN      A       192.0.2.50

特に結果だけを簡潔に確認したい場合は、 次のようにできます。

$ dig +short example.com
192.0.2.50

getentとdigはどう使い分ける？

通信できないときの基本的な切り分け手順

ここまでのコマンドを、 実際の障害調査の流れとして整理してみましょう。

ここで実際に試してみよう：通信障害切り分けシミュレーター

あなたはLinuxサーバ web01 を管理しています。

監視から、 「外部サーバへホスト名で接続できない」 というアラートが届きました。

コマンドを使って原因を特定してみましょう。

この演習で身につけたい考え方

理解度チェック：どこに問題がありそう？

初心者が間違えやすいポイント

① pingが通らないだけでネットワーク障害と断定する

ICMPがファイアウォールなどで拒否されている可能性があります。

pingだけではなく、 ルーティングや実際に使用するTCP/UDP通信なども含めて判断しましょう。

② IPアドレスだけ確認して終わる

IPアドレスが正しくても、 デフォルトゲートウェイなどの ルーティング設定が間違っていれば通信できません。

③ サービス起動＝ポート待ち受け、と考える

サービスが起動しているように見えても、 想定したポートやアドレスで待ち受けているとは限りません。

ss -lntpなどで、 実際の待ち受け状態を確認しましょう。

④ IPでは通信できるのにDNSを疑わない

IPアドレスで通信できるのであれば、 ネットワーク経路そのものは正常である可能性が高くなります。

ホスト名だけ失敗する場合は、 DNSや名前解決設定 を確認しましょう。

ネットワーク確認コマンド早見表

確認問題：ネットワーク確認の基本をチェックしよう

まとめ

次はLinuxの処理を自動化してみよう

ここまでのLinux中級講座では、 プロセス・サービス・ログ・パッケージ・ディスク・ネットワークなど、 Linuxサーバを管理するための基本操作を学んできました。

しかし実際のサーバ運用では、 毎日・毎週繰り返す処理を 人が毎回コマンドで実行するとは限りません。

Linuxでは、 cronを使うことで、 指定した日時にコマンドやスクリプトを自動実行できます。