Linuxのネットワーク疎通・DNS・待受ポートを切り分ける手順

Linuxで「接続できない」ときは、interface、IPアドレス、route、待受ポート、名前解決、ICMP、HTTP(S)を層ごとに分けて確認します。一つの結果だけで原因を決めず、読み取り中心の観測結果をそろえて次の調査対象を絞ります。

原因確認と復旧操作を分け、調査を許可されたhostとserviceだけを対象にしてください。commandのoptionや表示は環境ごとに異なるため、導入されている版のman pageを優先します。大量・連続実行やport scanへ手順を広げません。

最初に対象と時刻を整理する

接続元と接続先のhost、調査対象service、protocol、port
最初に異常を確認した時刻、タイムゾーン、直前まで正常だった時刻
timeout、名前解決失敗、接続拒否、HTTP statusなど、実際に観測した症状
同じ時刻帯の監視通知、直近変更、影響を受けた利用者や拠点

次の例にあるexample.comは説明用です。実環境では、調査対象として許可されたhostへ置き換え、対象を増やさず一つずつ確認します。

1. interfaceとIPアドレスを確認する

ip -br addr

interface名、状態、割り当てられたIPv4/IPv6アドレスとprefixを簡潔な表示で確認します。想定interfaceが見えているか、期待するaddressとprefixがあるかを構成資料と照合します。表示だけで上流経路や接続先serviceへの到達性までは証明できません。

IP addressとprefixからnetwork範囲を確認する場合は、IPv4 CIDR計算を利用できます。このツールはaddress範囲を計算するもので、network疎通自体を診断するものではありません。

2. routeを確認する

ip route

kernelのrouting tableを表示し、接続先networkに対応するroute、default route、next hop、出力interfaceを構成資料と照合します。routeが表示されることは経路選択の材料ですが、next hop以降の到達性や戻り経路まで保証しません。policy routingやVRFなどを使う環境では、この表示だけで全routing tableを確認したことにはならないため、構成資料と導入環境のman pageを優先します。

3. TCP/UDPのlistening socketを確認する

ss -lntup

TCP/UDPのlistening socket、local address、portを確認します。-pのprocess情報は権限やnamespaceによって一部表示されない場合があり、表示がないことだけでprocess不在とは断定しません。

local hostでlisteningしていることと、外部から到達可能であることは同じではありません。bind先address、routing、firewall、upstream経路、接続元側の条件は別に確認が必要です。

4. hostnameの名前解決を確認する

getent ahosts example.com

getent ahosts はGNU C LibraryのName Service Switch（NSS）を通じ、/etc/nsswitch.conf などの設定に従ってhosts databaseを検索します。filesやDNSなど複数のsourceを利用し得るため、「DNS serverだけ」を直接問い合わせるcommandとは限りません。

hostnameからaddressを得られても、そのaddressの対象portやserviceへ接続できることは証明できません。返されたaddress familyとaddressを記録し、後続の疎通結果と対応させます。

5. ICMP echoの疎通を限定回数で確認する

ping -c 4 example.com

ping はICMP ECHO_REQUESTを送り、-c 4で4回送信した後に終了します。ICMPが遮断・制限される環境もあるため、pingが通らないことだけで対象service停止やnetwork断とは断定しません。応答がある場合も、その時点のICMP echo経路を確認できたのであり、TCP/UDPの対象portやアプリケーション応答まで保証しません。

6. HTTP(S)をHEAD requestで確認する

curl -I --connect-timeout 5 https://example.com/

curl -I はHTTP HEAD requestを実際に送信してresponse headerを表示します。--connect-timeout 5 はDNS lookupとTCP/TLSなどのconnection phaseに許す最大時間を5秒にします。requestは接続先のaccess logや監視に記録され得るため、許可されたURLへ必要最小限の回数だけ実行します。接続後を含むrequest全体の所要時間を5秒に制限するoptionではありません。

実行前に、現在の環境でHTTPS_PROXY・ALL_PROXY・NO_PROXYと小文字の対応変数がどのように適用されるかを確認します。proxyが適用される場合、この結果はproxy経路を観測しており、接続元hostから対象への直接の名前解決やrouteを確認したことにはなりません。proxy側で名前解決される構成もあるため、記録にはproxiedかdirectかを明記します。明示的なdirect testが必要な場合は、proxyを回避する影響と許可を確認し、組織の手順に従います。proxy設定値に認証情報が含まれる場合は共有しません。

HEADの応答はGETや実際のアプリケーション操作と同じとは限りません。status、名前解決、connection、TLS、headerという観測事実を分け、認証が必要なURLや状態変更を伴う可能性があるendpointは組織の手順に従います。

一つの地点・時点だけで断定しない

各結果に観測時刻とタイムゾーンを添え、接続元、対象host、許可された別の監視地点の結果を同じ時刻帯で比較します。一度の成功・失敗だけで継続状態を決めず、監視の時系列、対象serviceのlog、変更履歴と照合します。

共有前に出力の機密情報をマスクする

出力にはIP address、hostname、interface名、process名、argument、path、内部portなどが含まれる場合があります。元の記録を保持し、共有用コピーでは組織の規程に従って認証情報、個人情報、内部構成を示す値をマスクしてください。

原因確認と復旧操作を分離する

この手順は状態を観測して原因候補を絞るところまでです。network設定、firewall、route、serviceの状態を変える操作は、影響範囲、承認手順、復旧計画を確認し、権限を持つ管理者が別途判断します。

command仕様の参照先

optionや表示内容は導入環境のman pageを優先し、以下のupstream一次情報も参照してください。