enp1s0からgateway 192.0.2.1を経由してserver 198.51.100.20のTCP port 443へ接続できない。
設定を変更せず、低いlayerから順に原因範囲を狭める。
適切な確認順はどれか。
network診断はlink、local address、route、近傍gateway、remote serviceの順に観測すると、失敗する境界を変更なしで絞り込める。
詳細解説
remote試験から始め、途中で設定を破壊する順序である。
誤り。remote portから始めると失敗範囲が広く、route削除や再設定で元の障害状態も失われる。
local linkからnetwork、route、next hop、application portへ段階的に進む。
正しい。link、address、route、gateway、remote portと進み、最初に失敗する境界を設定変更なしで特定できる。
IP addressでの接続障害に無関係な確認が中心である。
誤り。宛先はIP literalなのでDNSは主因ではなく、printerやnice値もこのnetwork path診断と無関係である。
現状確認前に設定を変更し、通信経路も停止させる。
誤り。現状を読む前にroute追加とinterface停止を行い、障害原因を増やす順序になっている。
実際に確かめる
一時的な検証環境で実行できる例です。
printf '%s
' 'link -> address -> route -> gateway -> remote TCP port'期待される結果
link -> address -> route -> gateway -> remote TCP port理解のポイント
- 観測を先に行う
- 低いlayerから進む
- remote portは最後に確認
確認時の注意
- 確認環境: 診断順序の表示のみ
- 検証ではnetwork設定変更や外部接続を行わない。
基礎のおさらい
観測優先
変更前のstateと出力を保存すると、原因の再現性を保ち、修正前後を比較できる。
layered diagnosis
linkが失敗なら上位試験へ進まず、gatewayまで成功してremote portだけ失敗するならserviceやfirewallへ範囲を絞る。