.png)
要約:クラスに割り当てられた仮想マシンでは、エミュレートされた VM との SSH セッションを終了した後、Docker コンテナー/エミュレートされた VM にアクセスするために使用された ping traceroute と元のスクリプトが動作しなくなりました。このプログラムは、クラスに割り当てられたホスト VM 内の Docker コンテナーから実行されました。ホスト VM は Ubuntu 上で実行されます。
学校から割り当てられたリモート デスクトップを修復し、授業を続けるには、ping、traceroute、および元のスクリプトとエミュレートされた VM にアクセスする機能を修正する必要があります。デスクトップ環境を完全にリセットしても問題は解決しませんでした。SSH は接続され、ブラウザーは機能し、traceroute は実行されますが、結果は 30 ホップで、ホップごとに 3 つのアスタリスクが表示されます。
これらの問題はすべて、エミュレートされた VM との SSH セッションを終了した後に一度に現れました。まだ絞り込んでいないことがいくつかあります (ARP テーブルとソケット インターフェイス - 明日戻って更新します)。これで少なくとも質問がより簡潔になることを願っています。
コンテクスト
私はクラスに割り当てられた仮想マシンで作業していますが、そのクラスに割り当てられたデスクトップ環境で別の仮想マシンをエミュレートするために使用されるプログラムを終了しているときに問題が発生しました。次の詳細は、私が取り組んでいた宿題の一部であり、すべて元のクラスに割り当てられた VM 内のエミュレートされた VM で実行されました。
ホスト マシン上でエミュレートされた SSH サーバー/VM/Docker コンテナーをセットアップするスクリプトが起動しないため、ターゲット マシンで変更した正確なファイルと設定を評価することができません。
ホスト VM に戻る前にエミュレートされた VM で実行した操作は次のとおりです。
ホームフォルダがなく、ルート権限があり、UID と GID が 1000 未満のユーザーを作成しました。
パスワードなしでルートアクセスを許可するように sudoers ファイルを設定しました。
sshd_configポート 22 以外のポートへの ssh アクセスを許可するようにファイルを変更しました。sshd_configターゲット マシンでファイルをフォーマットしているときに、ポート 22 をポート 2222 に上書きするというミスを犯しました。
これは、現在のポート リストの下に行を追加することで実行され、sshd_config次のようになります。
#Port 22
#Port 2222
ファイルを編集したときにポート 22 がコメント アウトされており、ポート 22 経由で問題なくターゲット マシンにアクセスできたため、その時点では何も考えませんでした。
コメント付きポートがなぜまだ機能するのかについては答えがありません。また、これがホスト VM で現在発生している問題の原因となる可能性もわかりません。
ホスト VM 上のポートは開いており、機能しています。
これはおそらく無視できるほどの追加情報かもしれませんが、これらの変更を行ってターゲット マシンを終了した直後にホスト マシンで問題に気付きました。これらの問題は、ターゲット マシンの操作を開始する前には存在しませんでした。Docker コンテナーとの SSH セッションを不適切に開始または終了するだけで問題が発生する可能性がある場合、セッション自体を現在の問題に関連付けるよりも、それがはるかに可能性の高い解決策です。
Docker/エミュレートされたVMの起動に関する問題
この場合、Docker はスクリプトから実行される SSH サーバーのエミュレーションであるため、ターゲット マシンにアクセスする必要があります。この機能がないと、ターゲット マシンにアクセスできず、ターゲット マシンで行った変更がホスト マシンの問題とどのように相関しているかをトラブルシューティングできません。
エミュレートされた VM の起動メッセージは、Docker が実行中であることを示していますが、ターゲット マシンにアクセスするために必要なスクリプトが起動されていません。エラー メッセージは次のとおりです。
アプリが起動しません。何か問題があります。
VM を再起動してから、Docker を再起動してください。
その後、スクリプトを再度実行します。
Dockerを再起動してもこのメッセージのステータスは変わりません。またはマシンをリセットします。ターゲット マシンで実行されているスクリプトに問題がある可能性がありますが、自分で調べたところ、問題は見つかりませんでした。ましてや、完全なリセットでも問題が解決しないほどホスト VM に支障をきたすような問題は見つかりませんでした。
PingとTracerouteに関する問題
ほとんどの IP に ping を実行しようとすると、最初の行で停止し、失敗メッセージが表示されないため、プロセスを手動で終了する必要があります。
ping -c 3 -w 12 1.1.1.1ping 要求の回数と期限を制限するために使用すると、次のようになります。
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
12 packets transmitted, 0 received, 100% >packet loss, time 11249ms
私午前localhost と 127.0.0.1 に ping でき、0.0.0.0 に ping しても正常に動作します。内部ファイアウォールは無効になっており、ICMP は有効になっています。
インターフェースpingコマンドの例を使用すると、ping -I interface google.com次のような出力が表示されます。
ping: SO_BINDTODEVICE interface: No such device
ソケット プログラミングの経験がある方なら、ここでのアドバイスは非常に貴重だと思います。ここが問題の原因になっている可能性があると思うからです。
Traceroute は実行されますが、出力は 30 ホップのみで、それぞれに 3 つのアスタリスクが表示されます。
試みられた解決策
ローカル マシン上の構成ファイルには、ターゲット マシンで記録した構成ファイルの変更が反映されていないため、ターゲット マシンの設定を改ざんしてもローカル マシンには影響しないはずであり、ターゲット マシンだと思い込んで誤ってローカル マシンの構成を変更したこともありません。
私午前localhost と 127.0.0.1 に ping を実行でき、0.0.0.0 に ping を実行しても正常に動作します。
内部ファイアウォールは無効になっており、ICMP が有効になっています。
ローカル VM のシステムを完全にリセットしましたが、ping、traceroute、Docker/エミュレートされた VM はまだ正常に動作しません。システムを完全にリセットした後も構成の問題が残っているという事実は非常にわかりにくいのですが、原因を絞り込むことができるかもしれません。システムを完全にリセットしても変わらないシステム設定またはネットワークの不具合はありますか?
仮想マシンの代替手段はありますが、特定のプロジェクトではバックアップ VM を使用できないため、これは時間的に敏感な問題であると考えています。質問を編集し、考えられるオプションを検討しながら、すでに試した解決策をさらに詳しく説明します。
まだ試みられていない潜在的な解決策
ソケット構成。
ARP テーブルの構成。
エミュレートされた VM の起動プロセスと、どこで失敗しているのかについてさらに調査します。
システムを完全にリセットしたにもかかわらず、問題が同じままであった理由をさらに調査します。
包括的な回答は必要ありません。正しい方向を指し示すヒントだけが必要です。明日も更新を続けます。まだ除外すべきことがたくさんあります。
答え1
この質問は解決済みで、個人的な後世のために残しておきます。ホスト VM は ping を適切に実行するように構成されていませんでしたが、構成ファイル内の基本的な部分を壊したと思いながら、ping に使用できるさまざまなトラブルシューティングの角度を試すのに忙しかったため、これを考慮しませんでした。
私はクラスの講師に連絡し、ホスト VM をリセットして、エミュレートされた VM を起動するために使用される Docker コンテナを修正し、ping と traceroute の問題がシステム自体の一部であることを明確にしてもらいました。
後でソケット プログラミングについてさらに質問するかもしれませんが、結局、現在の状況とは無関係になりました。