ウェブサイト検索

LFCA: 基本的なネットワーク トラブルシューティングのヒントを学ぶ – パート 12


場合によってはシステムに問題が発生した場合、問題を回避する方法を理解し、システムを通常の機能状態に復元する必要があります。このセクションでは、Linux システム管理者が持つべき基本的なネットワーク トラブルシューティング スキルに焦点を当てます。

ネットワークのトラブルシューティングの基本的な理解

ほとんどの場合、ネットワーク管理者とシステム管理者の間には大きな隔たりがあります。ネットワークの可視性が不足しているシステム管理者は、通常、機能停止やダウンタイムをネットワーク管理者のせいにする一方、サーバーの知識が不十分なネットワーク管理者は、エンドポイント デバイスの障害をシステム管理者の責任にすることがよくあります。しかし、責任のなすり合いは問題の解決には役立たないため、職場環境では同僚間の関係が悪化する可能性があります。

システム管理者として、ネットワークのトラブルシューティングの基本を理解していれば、問題をより迅速に解決し、まとまりのある作業環境を促進するのに役立ちます。このような理由から、ネットワーク関連の問題を診断する際に役立つ、基本的なネットワーク トラブルシューティングのヒントをいくつか紹介するためにこのセクションをまとめました。

TCP/IP モデルの要約

LFCA シリーズの前回のトピックでは、コンピューター内のデータ送信と各層にあるプロトコルを示す TCP/IP 概念モデルについて説明しました。

もう 1 つ同様に重要な概念モデルはOSI モデル (オープン システム相互接続) モデルです。これは、ネットワーク システムを分解する 7 層の TCP/IP フレームワークであり、コンピューティングは各層として機能します。

OSI モデルでは、これらの機能は下から順に次の層に分割されます。物理層、データリンク層、ネットワーク層、トランスポート層、セッション層。プレゼンテーション層、そして最後にアプリケーション層が一番上にあります。

OSI モデルを参照せずにネットワークのトラブルシューティングについて語ることはできません。このため、各層について説明し、使用されるさまざまなネットワーク プロトコルと、各層に関連する障害のトラブルシューティング方法を確認します。

レイヤ 1: 物理層

これはおそらく最も見落とされている層の 1 つですが、あらゆるコミュニケーションが行われるために必要な最も重要な層の 1 つです。物理層には、ネットワーク カード、イーサネット ケーブル、光ファイバーなどの PC の物理 PC ネットワーク コンポーネントが含まれます。ほとんどの問題はここから始まり、主に次のことが原因で発生します。

  • ネットワーク/イーサネット ケーブルが抜かれている
  • ネットワーク/イーサネット ケーブルの損傷
  • ネットワークカードがないか破損している

この層では、次のような疑問が浮かびます。

    ネットワーク インターフェイスのステータスを確認するには、ip コマンドを実行します。

    ip link show
    

    上記の出力から、インターフェイスが 2 つあることがわかります。最初のインターフェイス – lo – はループバック アドレスであり、通常は使用されません。ネットワークとインターネットへの接続を提供するアクティブなネットワーク インターフェイスは、enp0s3 インターフェイスです。出力から、インターフェイスの状態がUPであることがわかります。

    ネットワーク インターフェイスがダウンしている場合は、状態がダウンしているという出力が表示されます。

    その場合は、次のコマンドを使用してインターフェイスを起動できます。

    sudo ip link set enp0s3 up
    

    あるいは、以下に示す ifconfig コマンドを実行することもできます。

    
    sudo ifconfig enp0s3 up
    ip link show
    

    PC がルーターまたは DHCP サーバーから IP アドレスを選択したことを確認するには、ifconfig コマンドを実行します。

    ifconfig
    

    IPv4 アドレスには、示されているように inet パラメータが接頭辞として付けられます。たとえば、このシステムの IP アドレスは 192.168.2.104 で、サブネットまたはネットマスクは 255.255.255.0 です。

    
    ifconfig
    

    あるいは、次のように ip address コマンドを実行して、システムの IP アドレスを確認することもできます。

    
    ip address
    

    デフォルト ゲートウェイの IP アドレスを確認するには、次のコマンドを実行します。

    
    ip route | grep default
    

    デフォルト ゲートウェイ (ほとんどの場合、DHCP サーバーまたはルーター) の IP アドレスは、次のように示されます。 IP ネットワークでは、デフォルト ゲートウェイに ping できる必要があります。

    使用している DNS サーバーを確認するには、systemd システムで次のコマンドを実行します。

    
    systemd-resolve --status
    

    使用中の DNS サーバーを確認するより良い方法は、次の nmcli コマンドを実行することです。

    
    ( nmcli dev list || nmcli dev show ) 2>/dev/null | grep DNS
    

    ご覧のとおり、ネットワークのトラブルシューティングの大部分はここで行われます。

    レイヤ 2: データリンク層

    基本的に、データリンク層はネットワーク上のデータ形式を決定します。ここで、ホスト間のデータ フレームの通信が行われます。この層の主なプロトコルはARP (アドレス解決プロトコル) です。

    ARP はリンク層アドレスの検出を担当し、層 3 上の IPv4 アドレスから MAC アドレスへのマッピングを実行します。通常、ホストがデフォルト ゲートウェイに接続するとき、ホストの IP はすでにわかっていますが、MAC アドレスはわかっていない可能性があります。

    ARP プロトコルは、レイヤー 3 の 32 ビット IPv4 アドレスをレイヤー 2 の 48 ビット MAC アドレスに、またはその逆に変換することにより、レイヤー 3 とレイヤー 2 の間のギャップを埋めます。

    PC が LAN ネットワークに参加すると、ルーター (デフォルト ゲートウェイ) によって識別用の IP アドレスが割り当てられます。別のホストが PC 宛てのデータ パケットをデフォルト ゲートウェイに送信すると、ルーターは IP アドレスに対応する MAC アドレスを探すようARPに要求します。

    すべてのシステムには独自のARP テーブルがあります。 ARP テーブルを確認するには、次のコマンドを実行します。

    ip neighbor show
    

    ご覧のとおり、ルーターの MAC アドレスが入力されています。解像度に問題がある場合、コマンドは出力を返しません。

    レイヤ 3: ネットワーク/インターネット層

    これは、システム管理者がよく知っているIPv4 アドレスのみを扱う層です。ここで説明したICMPARP などの複数のプロトコルや、RIP (ルーティング情報プロトコル) などの他のプロトコルを提供します。 )。

    一般的な問題には、デバイスの構成ミスや、ルーターやスイッチなどのネットワーク デバイスの問題が含まれます。トラブルシューティングを始めるには、次のようにシステムが IP アドレスを選択しているかどうかを確認することから始めます。

    ifconfig
    

    また、ping コマンドを使用して ICMP エコー パケットを Google の DNS に送信することで、インターネット接続を確認することもできます。 -c フラグは、送信されるパケットの数を示します。

    ping 8.8.8.8 -c 4
    

    出力には、パケット損失がゼロで Google の DNS からの肯定的な応答が示されています。接続が断続的に発生している場合は、 次のようにtraceroute コマンドを使用して、どのポイントでパケットがドロップされているかを確認できます。

    traceroute google.com
    

    アスタリスクは、パケットがドロップまたは損失するポイントを示します。

    nslookup コマンドは、DNS にクエリを実行して、ドメインまたはホスト名に関連付けられた IP アドレスを取得します。これは、フォワード DNS ルックアップと呼ばれます。

    例えば。

    
    nslookup google.com
    

    このコマンドにより、google.com ドメインに関連付けられた IP アドレスが表示されます。

    
    Server:		127.0.0.53
    Address:	127.0.0.53#53
    
    Non-authoritative answer:
    Name:	google.com
    Address: 142.250.192.14
    Name:	google.com
    Address: 2404:6800:4009:828::200e
    

    dig コマンドは、ドメイン名に関連付けられた DNS サーバーにクエリを実行するために使用されるさらに別のコマンドです。たとえば、DNS ネームサーバーにクエリを実行するには、次のコマンドを実行します。

    
    dig google.com
    

    レイヤ 4: トランスポート層

    トランスポート層は、TCP および UDP プロトコルを使用してデータ送信を処理します。要約すると、TCP はコネクション型のプロトコルであるのに対し、UDP はコネクションレス型です。実行中のアプリケーションは、ポートと IP アドレスで構成されるソケットをリッスンします。

    アプリケーションに必要な TCP ポートのブロックなど、発生する可能性のある一般的な問題。 Web サーバーがあり、その実行状態を確認したい場合は、netstat または ss コマンドを使用して、Web サービスがポート 80 をリッスンしているかどうかを確認します。

    sudo netstat -pnltu | grep 80
    OR
    ss -pnltu | grep 80
    

    場合によっては、システム内で実行中のサービスによってポートが使用されている可能性があります。別のサービスでそのポートを使用する場合は、別のポートを使用するようにそのサービスを構成することが必要になる場合があります。

    それでも問題が解決しない場合は、ファイアウォールをチェックして、対象のポートがブロックされているかどうかを確認してください。

    トラブルシューティングのほとんどは、これら 4 つのレイヤーにわたって行われます。セッション層、プレゼンテーション層、アプリケーション層ではトラブルシューティングはほとんど行われません。これは、ネットワークの機能においてそれらがあまり積極的な役割を果たしていないためです。ただし、これらの層で何が起こっているかを簡単に見てみましょう。

    レイヤ 5: セッション層

    セッション層は、セッションと呼ばれる通信チャネルを開き、データ送信中にチャネルが開いたままであることを保証します。また、通信が終了すると閉じます。

    レイヤ 6: プレゼンテーション層

    構文層としても知られるプレゼンテーション層は、アプリケーション層で使用されるデータを合成します。これは、相手側で確実にデータを受信できるようにするために、デバイスがデータを暗号化、エンコード、圧縮する方法について詳しく説明しています。

    レイヤ 7: アプリケーション層

    最後に、エンドユーザーに最も近く、エンドユーザーがアプリケーション ソフトウェアと対話できるようにするアプリケーション層があります。アプリケーション層には、いくつか例を挙げると、HTTP、HTTPS、POP3、IMAP、DNS、RDP、SSH、SNMP、NTP などのプロトコルが豊富にあります。

    結論

    Linux システムのトラブルシューティングを行う場合は、OSI モデルを使用した階層化アプローチを最下層から開始することを強くお勧めします。これにより、何が問題なのかがわかり、問題を絞り込むのに役立ちます。