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


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

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

ほとんどの場合、ネットワーク管理者とシステム管理者の間には大きなギャップがあります。ネットワークの可視性を欠くシステム管理者は通常、ネットワーク管理者の停止とダウンタイムを非難しますが、ネットワーク管理者はサーバーの知識が不十分であるため、エンドポイントデバイスの障害についてシステム管理者の責任を負うことがよくあります。ただし、非難ゲームは問題の解決には役立ちません。職場環境では、これは同僚間の関係に敵対する可能性があります。

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

コンピュータでのデータの送信と各層にあるプロトコルを示すTCP/IP概念モデルの前のトピックで。

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

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

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

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

  • ネットワーク/イーサネットケーブルが接続されていない
  • ネットワーク/イーサネットケーブルの損傷
  • ネットワークカードの紛失または破損

このレイヤーで頭に浮かぶ質問は次のとおりです。

  • 「ネットワークケーブルが接続されていますか?」
  • 「物理ネットワークは接続されていますか?」
  • 「IPアドレスはありますか?」
  • 「デフォルトゲートウェイIPにpingを送信できますか?」
  • 「DNSサーバーにpingを実行できますか?」

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

$ ip link show

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

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

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

$ 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

ご覧のとおり、ここではネットワークのトラブルシューティングのかなりの部分が発生します。

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

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

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

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

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

$ ip neighbor show

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

これは、システム管理者に精通しているIPv4アドレスのみを使用するレイヤーです。これは、私たちがカバーしたICMPやARPなどの複数のプロトコルと、RIP(Routing Information Protocol)などの他のプロトコルを提供します。

一般的な問題には、デバイスの設定ミスやルーターやスイッチなどのネットワークデバイスの問題が含まれます。トラブルシューティングを開始するのに適した場所は、システムが次のように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

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

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

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

システムで実行中のサービスがポートを使用している場合があります。別のサービスでそのポートを使用する場合は、別のポートを使用するようにサービスを構成する必要がある場合があります。

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

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

セッション層は、セッションと呼ばれる通信チャネルを開き、データ送信中にそれらが開いたままになるようにします。また、通信が終了すると閉じます。

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

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

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