![あなたの仕事を自動化するための10のベストZapierの選択肢](/f/8b64d5bbb394ff37515fcc34f8e6e939.jpg?width=100&height=100)
システムで問題が発生した場合は、問題を回避する方法を知って、通常の機能状態に戻す必要があります。 このセクションでは、Linuxシステム管理者が持つべき基本的なネットワークトラブルシューティングスキルに焦点を当てます。
ほとんどの場合、ネットワーク管理者とシステム管理者の間には大きなギャップがあります。 ネットワークの可視性が不足しているシステム管理者は通常、責任を負います 停止のためのネットワーク管理者 また、ネットワーク管理者がサーバーの知識を十分に活用できない場合のダウンタイムは、エンドポイントデバイスの障害に対するシステム管理者の責任になります。 ただし、非難ゲームは問題の解決には役立ちません。職場環境では、これは同僚間の関係に敵対する可能性があります。
システム管理者として、ネットワークのトラブルシューティングの基本を理解することは、問題をより迅速に解決し、まとまりのある作業環境を促進するのに役立ちます。 このため、このセクションをまとめて、いくつかの 基本的なネットワークトラブルシューティングのヒント これは、ネットワーク関連の問題を診断するときに役立ちます。
の前のトピックでは LFCAシリーズ、私たちは見ました TCP / IP概念モデル これは、コンピューターでのデータの送信と、各レイヤーにあるプロトコルを示しています。
もう1つの同様に重要な概念モデルは、 OSIモデル (オープンシステム相互接続) モデル。 これは、ネットワークシステムを分解する7層のTCP / IPフレームワークであり、コンピューティングはすべての層として機能します。
の中に OSI モデルでは、これらの関数は下から順に次のレイヤーに分割されます。 物理層、データリンク層、ネットワーク層、トランスポート層、セッション層。 プレゼンテーション層、そして最後に最上部のアプリケーション層。
OSIモデルを参照せずに、ネットワークのトラブルシューティングについて話すことは不可能です。 このため、各レイヤーについて説明し、使用されているさまざまなネットワークプロトコルと、すべてのレイヤーに関連する障害のトラブルシューティング方法について説明します。
これはおそらく最も見過ごされているレイヤーの1つですが、コミュニケーションを行うために必要な最も重要なレイヤーの1つです。 物理層には、ネットワークカード、イーサネットケーブル、光ファイバーなど、PCの物理PCネットワークコンポーネントが含まれます。 ほとんどの問題はここから始まり、主に次の原因で発生します。
このレイヤーで頭に浮かぶ質問は次のとおりです。
ネットワークインターフェイスのステータスを確認するには、 ipコマンド:
$ ip linkshow。
上記の出力から、2つのインターフェイスがあります。 最初のインターフェース– lo
–はループバックアドレスであり、通常は使用されません。 ネットワークとインターネットへの接続を提供するアクティブなネットワークインターフェイスは、 enp0s3
インターフェース。 出力から、インターフェイスの状態が次のようになっていることがわかります。 上.
ネットワークインターフェースがダウンしている場合は、 状態ダウン 出力。
その場合は、次のコマンドを使用してインターフェイスを起動できます。
$ sudo ip link set enp0s3up。
または、を実行することもできます ifconfigコマンド 下に示された。
$ sudo ifconfig enp0s3up。 $ ip linkshow。
PCがルーターまたはDHCPサーバーからIPアドレスを選択したことを確認するために、 ifconfigコマンド.
$ ifconfig。
NS IPv4 示されているように、アドレスの前にはinetパラメーターが付いています。 たとえば、このシステムのIPアドレスは次のとおりです。 192.168.2.104 のサブネットまたはネットマスクを使用 255.255.255.0.
$ ifconfig。
または、を実行することもできます IPアドレス 次のようにコマンドを実行して、システムのIPアドレスを確認します。
$ IPアドレス。
デフォルトゲートウェイのIPアドレスを確認するには、次のコマンドを実行します。
$ ip route | grepのデフォルト。
デフォルトゲートウェイ(ほとんどの場合、DHCPサーバーまたはルーター)のIPアドレスは、次のように示されます。 IPネットワークでは、デフォルトゲートウェイにpingを実行できるはずです。
使用しているDNSサーバーを確認するには、systemdシステムで次のコマンドを実行します。
$ systemd-resolve--status。
使用中のDNSサーバーを確認するためのより良い方法は、 nmcliコマンド 示されている
$(nmcli dev list || nmcli dev show)2> / dev / null | grepDNS。
ご覧のとおり、ここではネットワークのトラブルシューティングのかなりの部分が発生します。
基本的に、データリンク層はネットワーク上のデータ形式を決定します。 これは、ホスト間のデータフレームの通信が行われる場所です。 この層の主なプロトコルは ARP ( アドレス解決プロトコル).
ARP リンク層アドレスの検出を担当し、層3のIPv4アドレスからMACアドレスへのマッピングを実行します。 通常、ホストがデフォルトゲートウェイに接続する場合、ホストのIPはすでにあるが、MACアドレスは持っていない可能性があります。
NS ARP プロトコルは、レイヤー3の32ビットIPv4アドレスをレイヤー2の48ビットMACアドレスに、またはその逆に変換することにより、レイヤー3とレイヤー2の間のギャップを埋めます。
PCがLANネットワークに参加すると、ルーター( デフォルトゲートウェイ )識別用のIPアドレスを割り当てます。 別のホストがPC宛てのデータパケットをデフォルトゲートウェイに送信すると、ルーターは要求します ARP IPアドレスと一致するMACアドレスを探します。
すべてのシステムには独自の機能があります ARP テーブル。 ARPテーブルを確認するには、次のコマンドを実行します。
$ ipネイバーショー。
お気づきのとおり、ルーターのMACアドレスが入力されています。 解像度に問題がある場合、コマンドは出力を返しません。
これは、排他的に使用するレイヤーです IPv4 システム管理者に精通しているアドレス。 次のような複数のプロトコルを提供します ICMP と ARP 私たちがカバーした他の RIP (ルーティング情報プロトコル).
一般的な問題には、デバイスの設定ミスやルーターやスイッチなどのネットワークデバイスの問題などがあります。 トラブルシューティングを開始するのに適した場所は、システムが次のようにIPアドレスを選択したかどうかを確認することです。
$ ifconfig。
また、あなたは使用することができます pingコマンド を送信してインターネット接続を確認するには ICMP GoogleのDNSにパケットをエコーします。 NS -NS
フラグは、送信されるパケットの数を示します。
$ ping 8.8.8.8 -c4。
出力は、パケット損失がゼロのGoogleのDNSからの肯定的な応答を示しています。 断続的な接続がある場合は、を使用してパケットがドロップされているポイントを確認できます。 tracerouteコマンド 次のように。
$ traceroutegoogle.com。
アスタリスクは、パケットがドロップまたは失われるポイントを示します。
NS nslookupコマンド DNSにクエリを実行して、ドメインまたはホスト名に関連付けられたIPアドレスを取得します。 これは、フォワードDNSルックアップと呼ばれます。
例えば。
$ nslookupgoogle.com。
このコマンドは、google.comドメインに関連付けられているIPアドレスを明らかにします。
サーバー:127.0.0.53。 住所:127.0.0.53#53権限のない回答:名前:google.com。 住所:142.250.192.14。 名前:google.com。 アドレス:2404:6800:4009:828:: 200e。
NS digコマンド ドメイン名に関連付けられたDNSサーバーを照会するために使用されるさらに別のコマンドです。 たとえば、DNSネームサーバーを照会するには、次のコマンドを実行します。
$ diggoogle.com。
トランスポート層は、を使用してデータ送信を処理します TCP と UDP プロトコル。 要約すると、 TCP UDPはコネクションレス型ですが、はコネクション型プロトコルです。 実行中のアプリケーションは、ポートとIPアドレスで構成されるソケットでリッスンします。
アプリケーションで必要になる可能性のあるブロックされたTCPポートなど、発生する可能性のある一般的な問題。 Webサーバーがあり、その実行状態を確認する場合は、 netstat また ssコマンド Webサービスがポート80をリッスンしているかどうかを確認します
$ sudo netstat -pnltu | grep80。 また。 $ ss -pnltu | grep80。
システムで実行中のサービスがポートを使用している場合があります。 別のサービスでそのポートを使用する場合は、別のポートを使用するようにサービスを構成する必要がある場合があります。
それでも問題が解決しない場合は、ファイアウォールを確認し、目的のポートがブロックされているかどうかを確認してください。
トラブルシューティングのほとんどは、これらの4つのレイヤーで行われます。 セッション、プレゼンテーション、およびアプリケーションの各レイヤーで行われるトラブルシューティングはほとんどありません。 これは、ネットワークの機能においてあまり積極的な役割を果たしていないためです。 ただし、これらのレイヤーで何が起こるかについて簡単に説明しましょう。
セッション層は、セッションと呼ばれる通信チャネルを開き、データ送信中にそれらが開いたままになるようにします。 また、通信が終了すると閉じます。
構文層とも呼ばれるプレゼンテーション層は、アプリケーション層で使用されるデータを合成します。 これは、デバイスがデータを暗号化、エンコード、および圧縮する方法を詳しく説明しており、相手側でデータが確実に受信されるようにすることを目的としています。
最後に、エンドユーザーに最も近く、アプリケーションソフトウェアと対話できるようにするアプリケーション層があります。 アプリケーション層には、HTTP、HTTPS、POP3、IMAP、DNS、RDP、SSH、SNMP、NTPなどのプロトコルが豊富に含まれています。
Linuxシステムのトラブルシューティングを行うときは、OSIモデルを使用した階層型アプローチを最下層から始めることを強くお勧めします。 これにより、何が問題になっているのかを把握し、問題を絞り込むことができます。