クラウドホスティング/専用サーバー環境のVPN、IPSecトンネルとTINC

クラウドホスティング環境用の仮想プライベートネットワークのセットアップを設計しています。私たちの要件を考えると、これが実際に専用サーバー環境と異なるとは思わない。考えられるのは、顧客が特定の仮想マシンまたは専用のサーバーにVPNを使用して接続することを要求できるようにすることです。これにより、補助暗号化を提供できます（たとえば、顧客ネットワークに送信される印刷ジョブの場合）。

私たちはホスト間IPSec（ESPとAH）ともちろんSSHトンネルのサポートを検討していますが、これらのどちらも実際にはVPNアダプターを使用する機能を提供していません。結果として、次の少なくともいくつかを追加することを検討していますが、スペースが非常に限られているため、これらのうちの1つまたは2つだけで標準化したいと考えています（1つでよい）。

1. 仮想または専用ホストでのIPSecトンネルサポート
2. ティンク
3. PPTP

バックアップなどを取得するサーバーは異なるデータセンターにある可能性があるため、ここではVPNアプローチを再利用できるようにしたいと考えています。これはPPTPを除外するようです。私の現在の考えでは、標準のVPNアダプターを使用できるため、IPSecの方が優れていると思われますが、（顧客の要件に基づいて）ルーティングを設定することは非常に困難になる可能性が高いため、tincも検討しています。

これら2つのうちどちらが望ましいですか？IPSecが正当化されない場合、ルーティング管理が深刻な頭痛の種になる可能性があるという私の恐れはありますか？これを回避する簡単な方法はありますか？私が見逃しているティンクに関する他の落とし穴はありますか（つまり、別のクライアントを必要とする以外）？

@Wintermuteの回答に応じて更新：

はい、この質問はサーバーの観点からです。その理由は、これらはクライアントのネットワークから事実上切断されたサーバーだからです。はい、私たちのターゲット市場は中小企業ネットワークです。はい、私たちはクライアントサーバーごとにパブリックIPを使用することを期待しています。ただし、クライアントが別の何かを必要とする場合を除きます（それから、話すことができます）。

私たちが頼りにしているソリューションは、クライアントがIPトンネルとそれらのトンネルでアクセス可能なネットワーク範囲を定義し、これらを独自の管理ツール（開発中）と組み合わせて、顧客の要求を構成変更に結び付けるものです。問題は、vmsとサーバーでルーティングソフトウェアを実行する可能性が低いため、ルーティングテーブルを静的に管理して、VPNが正しく機能しないことに気づくようにすることです。

また、独自の内部操作（バックアップなど）にネットワーク経由でESPを使用する可能性もあります。全体の設定はかなり複雑で、サーバー中心（クライアントのvpnからホストされたインスタンス）からネットワーク中心（内部のもの）、データベース中心（ツール）まで、さまざまな視点があります。だから私はその質問が私たちの全体的なアプローチの代表であるとは言いません（そして質問は多くのSEサイトで尋ねられています）。

ただし、これは実際には質問全体に影響を与えるものではありません。それはおそらく役に立つコンテキストかもしれません。

tincについては不明ですが、IPSECはほぼ必須です。真面目な企業はPPTPを信頼しません。

IPSECがルーティングにどのように影響するかわかりません。トンネルは、暗号化に関係なくトンネルです。同じ問題が再発生します。スプリットトンネルかどうかにかかわらず、顧客にコンセプトを理解してもらいます。特定の顧客のLAN IPが、選択したVPNプールと競合しているなどです。

SME市場（個々のサーバー、直接ログインなど）を目指しているように聞こえるので、より洗練されたソリューションを除外しますが、とりあえず2つの可能なアプローチを挙げます。

• プロファイルを許可するある種のVPNコンセントレータ。すべての顧客がVPNコンセントレータにログインし、プロファイル/グループ/ベンダーの技術に応じて、プロトコルXからIP Y（つまり、独自のサーバー）を使用する権限を取得します。

• Cisco ASR1000V仮想ルーター-各顧客が1つ取得すると、直接IPSECトンネル（VTIを使用してルーティングが簡単に見えるようにする）を実行したり、MPLSを顧客に直接送信して、ルーターをトポロジ内の別のブランチとして表示したり、VNICを割り当てたりできます。内部にVLANなどがあるため、仮想の「分岐」ができます。

• 上記の小規模バージョンでは、モノウォールを使用してこの目的に大きな効果をもたらしています（つまり、各顧客はルーター/ファイアウォールとして機能するレイヤー3仮想デバイスを取得し、このデバイスにVPN接続し、VLANにのみアクセスします）。ただし、各ルーター/ファイアウォールには独自のパブリックIPアドレスが必要です。

再：現在のアプローチでは、各サーバーにパブリックIPが必要であるか、NATの複雑で複雑なシステムがあり、各顧客のVPNパスに単一のポートなどが割り当てられていることに気付きます。

私はフルタイムのネットワーカーにあなたが持っているデザイン/提案を見直すことを勧めます、それはあなたがサーバーのバックグラウンドからやってきたように思えます。

はい、あなたが正しい。VPNコンセントレーターを介して集約しない限り、個別のIPを扱う必要があるようです。TBHコンセントレーターがおそらく最善の策です。すべてのVPN接続に必要なIPは1つだけですが、その外部インターフェースは、パブリックIPホストとは異なるサブネット/ VLANに存在する必要があります。それ以外の場合は、個別のサーバーごとにIPSEC VPNを直接構成することになります。