Webサーバーを備えた単一のデモVMに選択するVirtualBoxネットワークシナリオ

これらの要件を備えたWebアプリケーションのデモシステムをセットアップする必要があります。Windowsデバイス（ラップトップ）では、VirtualBox 5.0.40を使用して仮想Ubuntu（16.04）システムをセットアップします。このゲストシステムには、ホストWindowsラップトップと、同じネットワーク内の非常に限られた（1つまたは2つの）他のデバイス/クライアントの両方から到達可能なWebサーバーが含まれています。ホストシステムで実行されている他の仮想マシンはありません。

私が見る限り、2つの異なるアプローチがあります：

• ポート転送でNATを使用します。他のデバイスからの着信HTTP要求は、ホストのIPアドレスを使用し、ゲストシステム内のWebサーバーから処理されます。
• ゲストシステムが作業中に独自のIPを取得するブリッジネットワークアプローチを使用します（他のデバイスが使用します）。

最初のソリューションを支持していると思われる非常に興味深いブログ記事を見つけました：Oracle VM VirtualBox：ネットワークオプションとそれらの管理方法ただし、ゲストに接続しようとする他のデバイス/クライアントを必要としないようです考慮に入れます。

私の主な関心事は信頼性と安定性であり、パフォーマンスが2番目の優先事項であり、セットアップが3番目が簡単かもしれません。それで、どのアプローチを好むでしょうか？

あなたが与えたリンクは、どちらを使用するかに関するいくつかのヒントを与えます：「NATネットワーキングの特性：ゲストがクライアントの場合に最適、サーバーとしてのゲストには適さない」および「ブリッジネットワークの特性：クライアントまたはサーバーのゲストに適しています」。理由は説明されていませんが、いくつかの理由があります。

• 私が知っている唯一の2つの欠点は、1）追加の構成が必要であり、2）ゲスト全体をネットワークに公開するため、ゲストを「内側」にファイアウォールする必要があることです（一方、NATは公開するだけです）明示的に転送するポート）。
• 一方、bridgedを使用すると、ホストと競合するポートも公開できます（たとえば、ホストに既にWebサーバーがある場合、ゲストにポート80/443を転送できませんでした）。理論的には、少なくとも、NATステップが含まれていないため、少し速くなります。または、少なくとも、VirtualBoxのNATモジュールに問題がある場合は、それらを回避します。

一回限りのクライアントまたは純粋なクライアントにはNATを使用し、サービスを公開したい長期滞在ゲストにはブリッジモードを使用します。しかし、トラフィックの少ないシナリオでは、両方ともうまくいくと思います。ブリッジを構成する（ゲストのIPアドレスの取得に対処する）かどうかは、あなた次第です。

ブリッジされたVMに割り当てることができる空きアドレスが利用可能であると仮定すると、ブリッジされた方が良いと思います。

ただし、別のコンピューターはどのようにしてゲストへの接続を開始しますか？たとえば、ゲストで実行されているWebサーバーへの接続。ゲストOSへのルートがないため、NATモードを使用してこれは（通常）不可能です。VBoxはVMから実際のネットワークへのNATを設定しますが、外部ネットワークからVMへの変換を設定する必要があります。 。それだけの価値はありませんが、あなたの答えは、信頼性の安定性やパフォーマンスに影響するとは思いません。