開発環境として重宝される仮想マシンのVirtualBox、たとえばテスト環境や開発環境で使用しているマシンを振り分けたい場合は、クローンという便利な機能があります。
ところが、このvdiのマシンをクローンしてipアドレスを振り分けても、ネットワークに接続できない現象が発生します。本記事は、この解決方法です（vmdxでは問題ないようです）。
この75@Nginx with Nodejsがクローンで生成した仮想マシンとなります。
接続設定
まずは、クローン元のipアドレスを調べてみると192.168.11.76でした。なので、現状ではクローンされた仮想マシンのアドレスも192.168.11.76のままのはずなので、これを手動で192.168.11.75に切り替えてみます。
# nmcli c modify enp0s3 ipv4.addresses 192.168.11.75
ところがftpやブラウザに接続できなかったのでipアドレスを調べてみると、192.168.11.39と全く別のアドレスが表示されていることがわかりました。
不思議に思い、GUIで確認してみます。すると、このように表示されていました。nmtui（network manager text user interface）でネットワーク接続用のGUIを起動することができます。
#nmtui
とりあえず、この文字化けしているものが気になりますが、enp0s3というネットワークを確認してみると、設定した通りになっているようです。
手動設定の反映にはネットワークの再起動が必要なのか（後述しますが、今はNetworkManagerとなっています）と思い、再起動してみるとエラーが表示されました。
これをjournalctl -xeコマンドで確認してみます。どうも赤く表示されている警告があります。
そこを読んでいるとこうあります。
failed to start lsb bring up/down networking
つまりは、ネットワークに接続できないというエラーです。
原因は？
しばらく原因を考えてみると、ふと気になるものがありました。さっきの文字化けしたネットワーク情報の中身を確認します。
DHCPによって自動でipアドレスが振り分けられ、MACアドレスが設定されているようです。このMACアドレスをメモ帳にでも控えておきます。改めて、元のターミナルからip addrで調べてみると、どうやらこの文字化けしたノッペラボウのネットワークにつながっていたようです。
結論
クローンのマシンがipアドレスを変えただけで接続できないのは、仮想マシンの標準エンコードが異なるためにネットワーク名が文字化けしてしまい、ネットワーク名が曖昧になってしまう現象が発生することと、それによって本来接続すべきMACアドレスが異なってしまうためです。
原因１：仮作成されたネットワーク
vdiのクローンを作成すると、エンコードのせいでネットワーク名は新規で仮作成されることになり、DHCPによってipも自動生成されます。とはいえ、名前がノッペラボウ状態なので、このままでは何もできませんし、従来のネットワークを妨害しているためネットワークの再起動もできません。なので、この仮作成されたネットワークを削除しておく必要があるのですが、今回は既存のネットワーク名を使用するので、MACアドレスの情報だけメモ帳などに控えておきます（万が一、すぐに消してしまってもip addrコマンドでわかるので大丈夫です）。
MACアドレスを控えたら、この仮ネットワーク名は不要なので削除しておきます（再作成される場合もありますが、構わず削除してしまってください）。
原因２：MACアドレス
ネットワークが自動生成されるということは、それに合わせてMACアドレスも自動的に割り振られます。そして、ネットワークはそのアドレスを探そうとします。なので、接続させたいネットワーク名の方のMACアドレスを、割り振られたアドレスに書き換えます。
あとはネットワークを再起動するだけで、晴れてネットワーク接続が可能になります。
応用
VMwareからovftoolエクスポートしたvmxファイルをVirtualBoxにインポートした場合やマシンを別の場所に移行した場合もネットワーク接続できない現象が発生しますが、この対応で解決します。
ですが誤ってvmdkファイルをインポートしようとすると、起動時にカーネルパニックが発生してマシンが停止しますので間違わずに（内部破損は起きないですが、起動不可になります）。
その他の理由
1:ネットワーク再起動パッケージが古い
このRedditのメッセージを読んでいくとnetwork.serviceはRhel8で廃止され、NetworkManager.serviceに代替されているとあります。なので
#systemctl restart network
としてもnot foundとなります（そんなパッケージはないと返される）。
なので
#systemctl restart NetworkService
としましょう。再起動できたらステータスを確認するといいです。
2:外部ネットワークにつながらない
ネットワークアダプタの確認
ここが一番引っかかりやすい場所で、pingを叩いても外部ネットワークにつながらない（すなわちdnf、SSH、ftpなどにも接続できない）ことがよくあります。これはネットワークアダプタに対し、プロトコル使用を許可していないために起きる現象で、特にVirtualBoxとVMWareを同一ネットワーク環境で併用していたりすると、このネットワークアダプタの占有権が混用され、間違ったアダプタに設定されてしまっている（人為的な場合もある）可能性が高いです。
原因：プロトコル
ネットワークアダプタの設定(win+Rからncpa.cpl)コマンドでコントロールパネルを開き、各アダプタのプロパティからVMWareに接続したいネットワークアダプタに対しVMware Bridge Protocolにチェックが入っているか確認しましょう。チェックが漏れている場合はチェックし、マシンを再起動することですんなりとpingを送れると思います（PCの再起動は不要）。
参考になった記事（Noteより）