疎通トラブルシュート

「繋がりません」と言われて、いきなり curl を叩いても何も分かりません。通信は下の層が成り立って初めて上の層が動くので、調べる順番も下から上です。この順番そのものが出題されます。

下の層から順に7段

リンクが下りているのに curl を何度叩いても、返ってくるのは同じエラーだけです。逆に1から3までが正常だと分かっていれば、疑う範囲は一気に狭まります。

ip link show の出力に NO-CARRIER が出ていたら、設定ではなく物理層、つまりケーブルやスイッチを疑います。state DOWN だけなら ip link set <名前> up で上がる可能性があります。アドレスがまったく付いていないなら、DHCP で取得する設定なのに応答が無い、という筋を疑います。169.254 で始まるリンクローカルアドレスが付いていたら、それが DHCP に失敗した証拠です。

ping が通らないことは、相手が落ちている証拠にならない

ping は ICMP を使います。ICMP をファイアウォールで落としている相手には届かないので、応答が無いことと相手が停止していることは別です。この誤解は試験でも狙われます。

ping -c 4 192.168.1.1        # 4回だけ送る
traceroute 192.168.1.1       # 経路上のルーターを順に表示
tracepath 192.168.1.1        # traceroute の権限不要版

順番としては、まず自分のアドレス、次にデフォルトゲートウェイ、そして外部、と近いところから遠くへ広げます。どこで止まるかで故障箇所が絞れます。なお、この学習環境には ping も traceroute も入っていません。

アドレス指定なら通るのに名前だと通らない場合は名前解決の問題です。/etc/resolv.conf の nameserver 行、/etc/nsswitch.conf の hosts 行、/etc/hosts の中身を順に確かめます。

外から繋がらないのに、ローカルからは通る

最もよく使う組み合わせが ss -tuln で、TCP と UDP の待ち受けを数値で一覧します。-l を付けないと確立済みの接続も混ざり、-n を付けないと名前解決に時間がかかることがあります。プロセス名まで知りたければ -p を足します。

出力の Local Address と Port の列を見てください。全インターフェースで待ち受けているなら 0.0.0.0 から始まり、ループバックだけなら 127.0.0.1 から始まります。外から繋がらないのにローカルからは通る、という症状なら、この待ち受けアドレスがループバックに限定されていないかを疑います。

ポートが開いていないなら、サービスを見る

ポートが開いていない場合、そもそもサービスが起動していない可能性が高くなります。systemctl status <unit> で状態と直近のログが見え、journalctl -u <unit> でログを追えます。停止していれば systemctl start、次回起動時にも上げたいなら systemctl enable です。

ポートが開いているなら、正しい応答を返すかを確かめます。curl の -s は進捗表示を消すオプション、-f は HTTP エラー時に終了ステータスを 0 以外にするオプションで、この2つの組み合わせがスクリプトから疎通を確かめるときの定番です。-I ならヘッダだけ、-v なら通信の詳細が見られます。

サービスが動いていてポートも開いているのに外から繋がらない場合は、ufw status verbose や iptables -L -n -v でファイアウォールの現在のルールを確認します。ローカルからは通るという切り分けができていれば、原因はファイアウォールかバインドアドレスのどちらかです。

試験で狙われるところ

調べる順番は下の層からです。ping が通らないことは相手が落ちている証拠になりません。ss の -l は LISTEN だけで、付けないと確立済みの接続も混ざります。169.254 で始まるアドレスは DHCP に失敗した印です。そして netstat は非推奨で、現行は ss です。