ネットワークの問題解決
Linuxホストでネットワークがうまく機能しないとき、原因の切り分けは大きく次の3つの観点で行います。
- ネットワークインターフェースの設定は正しいか:IPアドレスが割り当てられているか、インターフェースが有効になっているか。
- ルーティングの設定は正しいか:適切な経路(特にデフォルトルート)が設定されているか。
- 実際に通信できるか:相手先まで到達できるか、途中のどこで止まっているか。
この主題では、これらを確認・修正するための現行のコマンド(ip系)と、従来から使われてきたコマンド(ifconfig・route等、いわゆる「レガシーツール」)の両方を扱います。試験では現行のコマンドだけでなく、レガシーツールについても出題される点に注意してください。
設定を変更するip・ifconfig・ifup・ifdown・route・hostnameの操作は、通常、root権限などの管理権限が必要です。
ネットワークインターフェースの管理:ip・ifconfig・ifup・ifdown・hostname
ip addr・ip link(現行のツール)
ipコマンドは、iproute2パッケージに含まれる、ネットワーク設定全般を扱う現行の標準的なコマンドです。インターフェース関連の操作は主にip link(インターフェース自体の状態)とip addr(IPアドレスの割り当て)のサブコマンドで行います。
| 目的 | コマンド例 |
|---|---|
| インターフェース一覧の表示 | ip link show |
| インターフェースの起動 | ip link set eth0 up |
| インターフェースの停止 | ip link set eth0 down |
| IPアドレスの割り当て | ip addr add 192.0.2.10/24 dev eth0 |
| IPアドレスの削除 | ip addr del 192.0.2.10/24 dev eth0 |
| 割り当て済みアドレスの一覧表示 | ip addr show |
IPアドレスの追加・削除は、通常、インターフェースを停止せずにip addrで行えます。インターフェース自体を再起動する必要がある場合は、ip link set eth0 downで一旦停止し、必要な設定変更を行った上で、ip link set eth0 upで再度起動します。インターフェースの削除(仮想インターフェースの取り外し等)や新規追加も、ip linkのサブコマンドで行います。
ip addr・ip linkで行う変更は、通常は実行中のカーネルの状態に対する一時的な変更です。再起動時やネットワーク管理サービスによる再設定時にも維持するには、使用しているディストリビューションやネットワーク管理方式に応じた恒久設定が必要です。
ifconfig・ifup・ifdown(レガシーツール)
ifconfigは、ip addr・ip linkが担う役割の多くを1つのコマンドでまとめて行える、従来から使われてきたコマンドです。net-toolsパッケージに含まれ、現在はipコマンドへの移行が進んでいますが、試験範囲としては現在も対象です。
ifconfig eth0 192.0.2.10 netmask 255.255.255.0 upifup・ifdownは、ifconfigのようにその場でパラメーターを直接指定するのではなく、あらかじめディストリビューションのネットワーク設定ファイルに記述された内容に基づいて、指定したインターフェースを起動・停止するコマンドです。「設定ファイルに書いてある内容どおりに起動・停止する」という点が、ifconfig・ipとの使い方の違いです。参照する設定ファイルや実際の動作は、ディストリビューションやネットワーク管理方式によって異なります。
hostname:ホスト名の確認と変更
hostnameコマンドは、システムのホスト名を表示・変更します。オプションなしで実行すると、現在のホスト名が表示されます。
| コマンド/オプション | 説明 |
|---|---|
hostname 新しいホスト名 | ホスト名を一時的に変更 |
hostname -s | ドメイン部分を除いた短縮名を表示 |
hostname -i | ホスト名を名前解決して得たIPアドレスを表示 |
hostname -I | ローカルに設定されたIPアドレスを表示(通常はループバックを除く) |
hostname -b -F ファイル | ファイルが空の場合、localhostを使用して設定 |
hostnameによる変更は通常、一時的であり、再起動すると元に戻ることがあります。
hostnamectl:systemd環境での確認と変更
hostnamectlは、systemdを使用するシステムでホスト名を確認・変更するコマンドです。
$ hostnamectl status
# hostnamectl set-hostname web01statusでは、現在のホスト名やOS情報などを確認できます。 set-hostnameで設定したホスト名は、直ちに反映され、通常は/etc/hostnameにも保存されるため再起動後も維持されます。
$ hostname
web01ホスト名の変更には、通常はroot権限が必要です。また、ホスト名をローカルで名前解決する場合は、必要に応じて/etc/hostsの登録内容も確認します。
ルーティングテーブルの参照・変更:ip routeとroute
ip route(現行のツール)
ip routeは、Linuxのルーティングテーブルを参照・変更するためのコマンドです。
$ ip route show
default via 192.0.2.1 dev enp0s3 proto dhcp src 192.0.2.10 metric 100
192.0.2.0/24 dev enp0s3 proto kernel scope link src 192.0.2.10 metric 100default:どの個別経路にも一致しない宛先に使用するデフォルトルートvia 192.0.2.1:パケットを次に渡すルータ(ネクストホップ)dev enp0s3:パケットを送信するネットワークインターフェースsrc 192.0.2.10:送信元として優先的に使用するIPアドレスmetric 100:経路の優先度。同じ宛先なら、通常は小さい値が優先される192.0.2.0/24:同一ネットワークへ直接到達できることを示す経路
| 目的 | コマンド例 |
|---|---|
| ルーティングテーブルの表示 | ip route showまたはip route |
| 宛先までの経路確認 | ip route get 198.51.100.10 |
| デフォルトルートの追加 | ip route add default via 192.0.2.1 |
| デフォルトルートの削除 | ip route del default via 192.0.2.1 |
| 既存経路の置換または追加 | ip route replace default via 192.0.2.254 |
# ip route replace default via 192.0.2.254 dev enp0s3 metric 100
# ip route show default
default via 192.0.2.254 dev enp0s3 metric 100同一条件の経路をaddで重複追加すると、RTNETLINK answers: File existsと表示されます。
複数のデフォルトルートがある場合は、metricやtableも確認し、変更対象と同じ条件を指定します。
# ip route replace default via 192.0.2.254 dev enp0s3 metric 100 table main条件の異なるデフォルトルートまでは置換されないため、変更後もip route show table allで確認します。
route(レガシーツール)
routeはnet-toolsパッケージに含まれる従来のコマンドです。
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.0.2.1 0.0.0.0 UG 100 0 0 enp0s3
192.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3-nはホスト名を名前解決せず、IPアドレスを数値で表示します。Uは経路が有効、Gはゲートウェイ経由を表します。
# route add default gw 192.0.2.1
# route del default gw 192.0.2.1これらの変更は通常一時的です。再起動後も維持するには、NetworkManagerなど利用中の管理方式で恒久設定を行います。
NetworkManagerとnmcliによるネットワーク管理
NetworkManagerは、Linuxのネットワーク設定を管理するサービスです。 nmcliを使うと、接続状態の確認やIPアドレスの設定をコマンドラインから行えます。
1. NetworkManagerの状態確認
systemctl status NetworkManager
nmcli general status停止している場合は、次のように起動・自動起動を設定します。
sudo systemctl enable --now NetworkManager2. デバイスと接続プロファイルの確認
nmcli device status
nmcli connection show- デバイス:
enp0s3などの実際のネットワークインターフェース - 接続プロファイル:IPアドレスやDNSサーバーなどを保存した設定
特定デバイスの詳細は次のコマンドで確認できます。
nmcli device show enp0s33. 接続できない場合の操作例
enp0s3がdisconnectedの場合は、対応する接続プロファイルを確認して有効化します。
nmcli connection show
sudo nmcli connection up "Wired connection 1"一時的にデバイスを切断・再接続する場合は次のようにします。
sudo nmcli device disconnect enp0s3
sudo nmcli device connect enp0s34. 固定IPアドレスの設定例
sudo nmcli connection modify "Wired connection 1" \
ipv4.method manual ipv4.addresses 192.168.1.10/24 \
ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.1 8.8.8.8"
sudo nmcli connection up "Wired connection 1"DHCPへ戻す場合は、IPアドレスなどの固定設定を削除します。
sudo nmcli connection modify "Wired connection 1" \
ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
sudo nmcli connection up "Wired connection 1"5. 設定後の確認
ip address show enp0s3
ip route
ping -c 3 192.168.1.1
ping -c 3 8.8.8.8
getent hosts example.comゲートウェイには届くが名前解決できない場合は、nmcli device showでDNS設定を確認します。
到達性・経路の確認:ping・ping6
pingはICMPの「エコー要求」を送信し、応答が返ってくるかどうかで、相手先とのICMPレベルでの到達性を確認するコマンドです。
ただし、応答が返らない場合でも、宛先または途中の機器でICMPエコー応答がフィルタリングされていることがあります。そのため、応答がないことだけで、相手先や経路に障害があるとは断定できません。
pingはIPv4、ping6はIPv6を対象にしたコマンドとして出題範囲に挙げられています現行のiputilsでは、pingコマンド自体が指定した宛先に応じてIPv4・IPv6を扱う実装があり、ping6が別の実行ファイルとして存在しない、またはpingへの互換用リンクとなっている場合もあります。出題範囲としてはping・ping6は別々の用語として挙げられています。[1]。
IPv4で到達性を確認する
次の例では、IPv4アドレスが192.168.1.1のホストに対して、ICMPエコー要求を4回送信しています。
$ ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.421 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.387 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.402 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.395 ms
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3068ms
rtt min/avg/max/mdev = 0.387/0.401/0.421/0.012 mspingは、オプションを指定しなければICMPエコー要求を繰り返し送信します。停止するにはCtrl+Cを入力します。-cオプションを指定すると、送信回数を制限できます。
ping -c 4 192.168.1.1主な表示項目は次のとおりです。
| 表示項目 | 説明 |
|---|---|
64 bytes | 受信したICMP応答のサイズ |
icmp_seq | ICMPエコー要求・応答の通し番号 |
ttl | パケットが通過できる残りのルーター数を表す値 |
time | エコー要求を送信してから応答を受信するまでの往復時間 |
packets transmitted | 送信したパケット数 |
received | 応答を受信したパケット数 |
packet loss | 応答が得られなかったパケットの割合 |
rtt min/avg/max/mdev | 往復時間の最小値、平均値、最大値、ばらつき |
この例では、送信した4パケットすべてに応答があり、パケット損失率は0%です。したがって、少なくとも確認時点では、対象ホストとの間でICMPによる通信ができています。
ホスト名を指定して確認する
pingにはIPアドレスだけでなく、ホスト名も指定できます。
$ ping -c 3 server.example.com
PING server.example.com (192.0.2.10) 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=57 time=11.8 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=57 time=12.1 ms
--- server.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 11.800/12.100/12.400/0.244 msホスト名を指定した場合は、ICMPによる到達性の確認に加えて、DNSなどによる名前解決も行われます。
名前解決に失敗すると、次のようなエラーが表示されます。
$ ping unknown.example.invalid
ping: unknown.example.invalid: Name or service not knownこの場合、ICMPエコー要求は送信されていません。DNSサーバーの設定や、指定したホスト名が正しいかを確認します。
トラブルの切り分けでは、次のようにIPアドレスとホスト名の両方で確認する方法が有効です。
$ ping -c 3 192.0.2.10
$ ping -c 3 server.example.comIPアドレスでは応答がある一方、ホスト名ではエラーになる場合、ネットワーク経路ではなく名前解決に問題があると考えられます。
応答が返らない場合
ICMPエコー要求に対する応答が返らない場合、次のような結果になります。
$ ping -c 4 192.0.2.10
PING 192.0.2.10 (192.0.2.10) 56(84) bytes of data.
--- 192.0.2.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3068ms4 packets transmitted, 0 receivedは、4パケットを送信したものの、応答を1つも受信できなかったことを示します。
主な原因として、次のようなものが考えられます。
- 相手先ホストが停止している
- 相手先までのネットワーク経路に障害がある
- 宛先IPアドレスが間違っている
- ファイアウォールなどがICMPを遮断している
- 相手先がICMPエコー要求に応答しないよう設定されている
- 応答パケットが途中で破棄されている
応答がないという結果だけでは、原因を一つに特定できない点に注意が必要です。
到達不能メッセージが表示される場合
送信元ホストや途中のルーターが宛先へ到達できないと判断した場合、Destination Host Unreachableなどのメッセージが表示されることがあります。
$ ping -c 3 192.168.1.200
PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.
From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.200 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2045msこの例では、192.168.1.100からDestination Host Unreachableが返されています。同一ネットワーク上のホストを確認している場合は、宛先ホストが停止している、IPアドレスが誤っている、ARPによるアドレス解決ができない、といった原因が考えられます。
宛先に対する経路が存在しない場合は、次のようなエラーが表示されることもあります。
$ ping -c 3 203.0.113.10
ping: connect: Network is unreachableこの場合は、ルーティングテーブルやデフォルトゲートウェイの設定を確認します。
IPv6で到達性を確認する
IPv6ではping6を使用します。
$ ping6 -c 3 2001:db8::10
PING 2001:db8::10(2001:db8::10) 56 data bytes
64 bytes from 2001:db8::10: icmp_seq=1 ttl=64 time=0.538 ms
64 bytes from 2001:db8::10: icmp_seq=2 ttl=64 time=0.492 ms
64 bytes from 2001:db8::10: icmp_seq=3 ttl=64 time=0.507 ms
--- 2001:db8::10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms
rtt min/avg/max/mdev = 0.492/0.512/0.538/0.019 ms環境によっては、ping6の代わりにpingの-6オプションを使用します。
$ ping -6 -c 3 2001:db8::10反対に、IPv4の使用を明示する場合は-4オプションを指定できます。
$ ping -4 -c 3 192.0.2.10IPv6のリンクローカルアドレスは、同じアドレスが複数のインターフェース上で使用される可能性があります。そのため、%に続けてインターフェース名を指定することがあります。
$ ping6 -c 3 fe80::1%eth0この例では、eth0を使用してリンクローカルアドレスfe80::1へICMPv6エコー要求を送信しています。
pingを使った基本的な切り分け
ネットワークの問題を確認するときは、近い範囲から順番にpingを実行すると、問題の発生箇所を絞り込みやすくなります。
- ループバックアドレス
- 自分自身のIPアドレス
- デフォルトゲートウェイ
- 外部ホストのIPアドレス
- 外部ホストのホスト名
IPv4の例は次のとおりです。
$ ping -c 3 127.0.0.1
$ ping -c 3 192.168.1.100
$ ping -c 3 192.168.1.1
$ ping -c 3 192.0.2.10
$ ping -c 3 server.example.com例えば、デフォルトゲートウェイまでは応答があるものの、外部ホストから応答がない場合は、ゲートウェイより先の経路や外部側の設定を確認します。
外部ホストのIPアドレスでは応答があり、ホスト名では確認できない場合は、DNSなどの名前解決に問題があると判断できます。ただし、ICMPがフィルタリングされている可能性があるため、必要に応じてip route、traceroute、ssなど、ほかのコマンドの結果と組み合わせて判断します。
到達性・経路の確認:traceroute・tracepath
tracerouteとtracepathは、宛先までに通過するルーター(ホップ)を調べるコマンドです。
IPv4ではTTL、IPv6ではHop Limitを1から順番に増やしたパケットを送信します。
ルーターはTTLまたはHop Limitを1ずつ減らし、値が0になると通常はICMPの時間超過メッセージを返します。
この応答を利用して、送信元から宛先までの経路を確認します。
コマンドの違い
| 項目 | traceroute | tracepath |
|---|---|---|
| 実行に必要な権限 | 実装やプローブ方式による。生のパケットを扱う方式ではroot権限などが必要 | 通常は一般ユーザーで実行可能 |
| パスMTUの表示 | 実装やオプションによる | 経路上のMTUを表示可能 |
| 主なプローブ方式 | UDP、ICMP、TCPなど | 主にUDP |
| IPv4用コマンド | traceroute | tracepath |
| IPv6用コマンド | traceroute6 | tracepath6 |
tracerouteによるIPv4経路の確認
$ traceroute example.net
traceroute to example.net (203.0.113.80), 30 hops max, 60 byte packets
1 192.168.1.1 0.612 ms 0.543 ms 0.518 ms
2 198.51.100.1 4.820 ms 4.731 ms 4.690 ms
3 * * *
4 198.51.100.34 12.284 ms 11.942 ms 12.103 ms
5 203.0.113.80 18.561 ms 18.420 ms 18.397 ms行頭の数字はホップ数です。通常、各ホップに対して複数回プローブを送信するため、応答時間が3つ表示されます。
この例では、5ホップ目で宛先の203.0.113.80に到達しています。
3ホップ目の*は、制限時間内に応答を受信できなかったことを表します。
ただし、*が表示されても、そのルーターや経路が故障しているとは限りません。次のような原因が考えられます。
- ルーターがICMP時間超過メッセージを返さない
- ファイアウォールで応答がフィルタリングされている
- 一時的な輻輳やパケット損失が発生している
- ルーターが応答パケットの送信を制限している
後続のホップや宛先から応答があれば、*のホップもパケット自体は通過している可能性があります。
プローブ方式の変更
Linuxのtracerouteは、通常UDPプローブを使用します。
環境に応じてICMPやTCPへ変更できます。
# ICMP Echoを使用
$ traceroute -I 203.0.113.80
# TCP SYNを使用して宛先ポートを443に指定
$ sudo traceroute -T -p 443 203.0.113.80UDPやICMPがフィルタリングされている環境でも、TCPの443番ポートなどを使用すると経路を確認できる場合があります。
必要な権限は、tracerouteの実装やバイナリに設定された権限・Capabilityによって異なります。
tracepathによるIPv4経路とパスMTUの確認
$ tracepath example.net
1?: [LOCALHOST] pmtu 1500
1: 192.168.1.1 0.520ms
2: 198.51.100.1 4.812ms
3: no reply
4: 198.51.100.34 12.107ms pmtu 1400
5: 203.0.113.80 18.433ms reached
Resume: pmtu 1400 hops 5 back 5pmtuはパスMTU(Path MTU)を表します。
パスMTUとは、送信元から宛先まで、IPフラグメント化なしで転送できる最大パケットサイズです。
この例では、送信元インターフェースのMTUは1500バイトですが、経路上で1400バイトに縮小しています。
最後のreachedは宛先へ到達したことを示し、Resumeには確認結果の要約が表示されます。
backは応答が戻ってきた経路の推定ホップ数です。通信経路は往路と復路で異なる場合があるため、hopsと一致しないことがあります。
IPv6経路の確認
IPv6では、traceroute6またはtracepath6を使用します。
$ traceroute6 2001:db8:100::80
traceroute to 2001:db8:100::80, 30 hops max, 80 byte packets
1 2001:db8:1::1 0.731 ms 0.665 ms 0.642 ms
2 2001:db8:10::1 5.203 ms 5.174 ms 5.121 ms
3 * * *
4 2001:db8:100::80 16.842 ms 16.731 ms 16.708 ms$ tracepath6 2001:db8:100::80
1?: [LOCALHOST] pmtu 1500
1: 2001:db8:1::1 0.701ms
2: 2001:db8:10::1 5.186ms
3: no reply
4: 2001:db8:100::80 16.791ms reached
Resume: pmtu 1500 hops 4 back 4IPv6ではIPv4のTTLに相当するHop Limitを利用します。
また、IPv6ルーターはパケットを途中でフラグメント化しないため、パスMTUの確認が特に重要です。
よく使用するオプション
$ traceroute -n 203.0.113.80 # 名前解決を行わずIPアドレスで表示
$ traceroute -m 10 203.0.113.80 # 最大ホップ数を10に指定
$ traceroute -w 2 203.0.113.80 # 応答待ち時間を2秒に指定
$ tracepath -n 203.0.113.80 # 名前解決を行わずに表示名前解決に時間がかかる場合は、-nを指定すると経路確認をすばやく行えます。
> 注意: 表示される経路は、その時点のルーティング結果です。負荷分散や経路変更により、実行するたびに異なるルーターや応答時間が表示されることがあります。
netcat(nc・ncat)
netcatは、TCP・UDP通信を手軽に確認できる汎用ツールです。
実装によってコマンド名やオプションが異なり、一般的にはnc、Nmap版ではncatを使用します。
TCPポートへの接続確認
-zはデータを送らずに接続だけを確認し、-vは詳細を表示するオプションです。
$ nc -zv www.example.com 80
Connection to www.example.com 80 port [tcp/http] succeeded!この結果は、名前解決が成功し、対象ホストのTCPポート80へ接続できたことを示します。
ポートが待ち受けていない場合は、次のように表示されます。
$ nc -zv 192.0.2.10 22
nc: connect to 192.0.2.10 port 22 (tcp) failed: Connection refusedConnection refusedは、ホストには到達できたものの、ポートが待ち受けていない、または接続が拒否されたことを示します。
$ nc -zv -w 3 192.0.2.20 443
nc: connect to 192.0.2.20 port 443 (tcp) timed outタイムアウトする場合は、経路上のファイアウォールによる破棄や、ホストに到達できない可能性があります。 -w 3はタイムアウト時間を3秒に設定する指定です。
待ち受けとデータ送信
一方の端末でTCPポート12345を待ち受けます。
$ nc -l 12345
hello別の端末から接続して文字列を送信します。
$ echo "hello" | nc 127.0.0.1 12345待ち受け側にhelloと表示されれば、TCP通信ができています。
実装によっては待ち受けにnc -l -p 12345を使用します。
UDPポートの確認
$ nc -zvu -w 2 192.0.2.53 53
Connection to 192.0.2.53 53 port [udp/domain] succeeded!-uはUDPを使用する指定です。ただしUDPにはTCPのような接続確立がありません。
そのため、成功表示や無応答だけでは、UDPポートが実際に利用可能とは断定できません。DNSならdigなど、対象プロトコルに対応したコマンドでも確認します。
なお、表示内容や-z、-w、-lなどの動作は、ncやncatの実装によって異なるため、man ncやncat --helpで確認します。
host・dig・netstat・ss(概要のみ)
host・digはDNSサーバーへの問い合わせを行うコマンド、netstat・ssは自ホストのソケット(待ち受け中・接続中の通信)の状態を確認するコマンドです。ネットワークの問題解決という文脈では、「名前解決自体ができているか(host・dig)」「そもそも自ホスト側で必要なポートが待ち受けられているか(netstat・ss)」を確認する目的で使われます。詳しい書式・オプションは、それぞれ「クライアント側のDNS設定」「開いているポートの調査」の技術解説記事を参照してください。
補足
- 現行のiputilsでは、
pingコマンド自体が指定した宛先に応じてIPv4・IPv6を扱う実装があり、ping6が別の実行ファイルとして存在しない、またはpingへの互換用リンクとなっている場合もあります。出題範囲としてはping・ping6は別々の用語として挙げられています。 ↩