検証環境では、本番へ影響を与えず正常構成と障害構成を再現し、設定・通信・パケットの違いを比較することが重要です。

ip.addrを使うと、指定したIPアドレスが送信元または宛先に含まれるIPv4パケットを絞り込めます。

問い合わせ対象のMACアドレスがまだ分からないため、ARP RequestはEthernetブロードキャストで送信されます。

クライアントのSYN、サーバーのSYN/ACK、クライアントのACKの順で接続を確立します。パケット解析では、このどこで応答が止まるかを確認します。

SYN再送が続く場合は、接続開始に対する応答が戻っていません。送信経路だけでなく、サーバーの待受状態、FW、戻り経路なども候補になります。

DNSではTransaction IDを確認すると、どのQueryに対するResponseかを対応付けやすくなります。問い合わせ名、レコード種別、RCODEも合わせて確認します。

NXDOMAINは、問い合わせたドメイン名が存在しないことを示すDNS応答です。「応答がない」のとは異なり、DNSサーバーから明確な応答が返っています。

フレームが送信元から宛先へ進む順番に確認します。設定の一点だけを見るのではなく、物理からL2転送へ段階的に絞るのが基本です。

別スイッチ間の同一VLAN通信では、そのVLANがTrunkを通過できる必要があります。Allowed VLANから除外されていると、VLAN 10のフレームは対向へ届きません。

STPでは、どの装置がルートブリッジか、各ポートがどの役割・状態か、想定外のトポロジー変化がないかを確認します。

経路表に行き先があっても、ネクストホップへ到達できない、または戻り経路がないと通信は成立しません。行きと戻りを分けて確認します。

IPで到達できるなら、少なくとも基本的なIP経路は成立している可能性が高く、ホスト名だけ失敗する場合は名前解決の正常動作を分けて確認します。

DHCP・DNS・NATは役割が異なります。IP取得、名前解決、アドレス変換を分け、どこまで正常かを確認すると原因候補を絞れます。

「遅い」は原因が広いため、ネットワーク遅延、損失、帯域逼迫、装置負荷、アプリ側応答時間などに分解して比較します。

第4章の中心は「正常系を基準に比較し、証拠を積み上げて原因候補を絞る」ことです。思い込みで設定変更するのではなく、どこまで正常かを確認します。