リモートITの目的で、VPNまたはWAN？
私は2つのオフィスしかない小さな保険会社で働いています。今のところ、別のオフィスで問題が発生した場合、それはほんの短いロードトリップです。だが...
この会社は拡大しており、年末までに全米に4〜5のオフィスを開設する予定です。私の上司は、サーバーをリモートでホストして、インターネットアクセス用のVPN上にすべてのオフィスを配置することが適切な解決策になると考えています。私の懸念は、VPNが常に接続されているとは限らないため、必要なソフトウェア/ OSの更新をVPNでプッシュできないことです。彼の懸念は、すべてのサテライトオフィスが依存するファイアウォールやネットワーク接続など、社内に何も必要としないことです。
私と上司の両方がポーラアブドゥルと同じくらい多くのネットワーキング経験を持っていることを覚えておいてください。で最適なセットアップは何でしょうか
一般的に言えば、リモートオフィス（ワイドエリアネットワーク（WAN）として知られている）をセントラルオフィスに接続する戦略は、専用接続と非専用接続の線に沿って崩壊します。あなたの会社が実際にリモートオフィスへの配線を自分で実行する可能性は低いため、実際には回線が少しぼやけています。したがって、実際には、リモート接続のために常に他の誰かのネットワークを介したトランジットに依存しています。ただし、その接続がユーザー専用になる程度はさまざまです。
従来のWAN接続は「専用回線」を介して行われました。これらは、通信会社が提供するデータ回線であり、目的上、オフィス間の専用のポイントツーポイント接続であるように見えます。（実際には、データは通常、他のデータと一緒に多重化され、電話会社のネットワーク内の大容量回線を介して送信されます。）これらの回線は通常、かなり信頼性が高く、通常、ダウンタイムの処理方法と内容を説明するサービスレベル契約（SLA）の対象となります。サービスのレベル（帯域幅、待ち時間、稼働時間など）が購入されています。これらの回線は、従来、他のリモート接続方法と比較してかなり高価です。このタイプの接続は厳密にポイントツーポイントデータであり、インターネット接続はありません。多くのプロバイダーは、リモートオフィスを電話会社のネットワーク（Customer Premise Equipment、またはCPEと呼ばれていました）に接続するデバイスを「管理」するオプションを提供しており、WAN conネクションは「ターンキー」と見なすことができます。
スペクトルの遠端では、仮想プライベートネットワーク（VPN）により、インターネット全体に「仮想」ネットワークを作成できます。理論的には、リモートオフィスごとに任意のISPからインターネットサービスを取得できます。インターネットエンドポイントは他のインターネットエンドポイントと通信できるため、VPNハードウェアデバイスまたはソフトウェアを使用してインターネット経由で仮想ネットワークを作成します。コストは非常に高くなる可能性がありますが、サービスの信頼性、帯域幅、遅延などの保証はありません。関係する個々のISPで使用できるSLAは、通常、達成される全体的なサービスレベルに関して何の違いもありません。 VPNが通過するすべてのネットワークオペレータにSLAが存在する可能性は低いため、VPNによって。 VPNシナリオでは、各オフィスは、VPNをサポートするためにインターネットに接続することの副作用として、インターネット接続を使用することになります。ただし、フィルタリングまたはロギングを提供するために、とにかく中央ハブを介してユーザーインターネットアクセスを実行することを選択できます。 VPNは「常にオン」にすることができますが、信頼性は保証されません。
このスペクトルの真ん中には、マルチプロトコルラベルスイッチング（MPLS）（および以前はフレームリレー）のような製品があります。これは、実際には、MPLSプロバイダー自体で実行されているVPNのように動作しながら、専用の接続の外観を提供します。ネットワーク（一般に「クラウド」と呼ばれます）。価格は、MPLSオファリングの従来のWAN接続）の価格に近いですが、SLAは通常、従来のWAN接続）の接続にもはるかに近いです。多くのMPLSオファリング各リモートサイトでインターネットアクセスにバンドルされていますが、VPNソリューションと同様に、ユーザーのインターネット要求を一元的に集約することを選択できます。多くのMPLSプロバイダーは、リモートオフィスでCPEを「管理」するオプションを提供し、保守の責任から解放されます。その機器。
一部の地域では、メトロイーサネットなどのサービスを介して非常に高速なWAN接続を取得できます。通常、これらのサービスは、従来のWANおよびVPN/MPLSスタイルの接続。SLAは、プロバイダーまたは選択した価格ポイントに基づいて大きく異なる可能性があります。
あなたの会社の具体的な答えは、帯域幅、遅延、信頼性、予算、および将来の成長/アプリケーションのニーズによって異なります。 「1つのサイズですべてに対応」するソリューションはありません。さまざまなベンダーから見積もりを入手し、多くの質問をすることをお勧めします。選択したソリューションが契約期間中のビジネスに適していると確信できない限り、長期契約には注意が必要です。
「WANシミュレーター」ハードウェアまたはソフトウェアを使用して、既存のソフトウェアアプリケーションをテストできるさまざまなタイプのWAN接続をシミュレートするためにコンサルタントを関与させることを検討することをお勧めします。ソフトウェアが稼働していることを知っているさまざまなタイプのWAN接続を処理することは、接続のタイプを選択する前に重要だと私が考えるものです。前もって少しお金を費やしますが、最終的なWAN接続の選択はビジネスに適しています。
彼の懸念は、すべてのサテライトオフィスが依存するファイアウォールやネットワーク接続など、社内に何も必要としないことです。
さて、あなたはある種のネットワーク接続のために何かを持っている必要があるでしょう。オフィスの規模にもよりますが、10人未満の場合はASA5505のようなものをお勧めします。またはより多くの人々のためのより大きなモデル。次に、最善の策は、すべてのオフィス間でポイントツーポイントVPNを設定することです。
インターネットにアクセスするために依存しなければならない機器があるので、P2PVPNをセットアップできるものにしてみませんか？
サイト間VPNとVPNクライアントの実行の違いを調査する必要があるようです。サイト間を使用すると、ネットワーク上と同じようになり、WAN上での実行速度は遅くなりますが、起動アクション（GPで開始されたインストールなど）は機能します。最初に、セントラルオフィスの帯域幅がこれに十分であるかどうかを確認する必要があります。リモートオフィスの場合、サイト間が最適です。 VPN機能を備えた互換性のあるルーターを購入します。
上司の要件がわかりません。本社と何らかのファイル共有を行っている場合は、本社に依存する必要があります。ハイブリッドアプローチは、各ローカルにある小さなファイルサーバーであり、セントラルオフィスへのネットワークマッピングがあります。その速度は速く、彼らはまだセントラルオフィスにアクセスできます。もちろん、このサーバーをローカルNASまたはテープドライブなどの何かにバックアップする必要があります。
最後に、何かをプッシュするために「常にVPNをオンにする」必要はありません。これは、更新をプッシュするために使用しているものに完全に依存します。これを行うには多くの方法がありますが、その多くは常にオンにする必要はありません。更新のサイズによっては、これらをリモートファイルサーバーに保存し、WAN経由でダウンロードするのではなく、そこからインストールするスクリプトを作成することをお勧めします。
ハブ/スポークトポロジでサイト間IPSecトンネルによってリモート接続された広範囲のオフィスを持つ複数のクライアントの世話をします-各スポーク（リモートオフィス）はハブ（HQ）のリソースに接続できますが、相互には接続できません。各場所にはインターネット接続（T1とADSL）があり、IPSecトンネルを維持し、オフィスにインターネットアクセスを提供する小型で安価なファイアウォール/ルーターアプライアンスです。
各リモートロケーションのニーズは最小限であるため、ターミナルサーバーはそれらのニーズによく適合します。そのため、主にスプリットトンネリングを実行します。つまり、VPNトンネルを介してルーティングされるトラフィックは、本社のオフィスに物理的に配置されているターミナルサーバークラスターへのトラフィックのみであり、それ以外はすべてインターネットを介して直接送信されます。これは非常にうまく機能します。ファイアウォールルールは十分に厳しく、HQの場所で許可されるトラフィックはターミナルサーバー（ほとんどの作業を行う場所）に直接関連しているため、HQの帯域幅について心配する必要はありません。どこかのトレントクライアントまたはファイル共有を介して広がるウイルスによって消費されます。適切なエンドユーザーポリシー/施行などにより、ソースでのこれらのリスクが排除されると指摘する人もいますが、私たちの場合、これらのリモートオフィスはある程度の自律性を持って運営されており、定期的/毎日提供する人材/リソースがありません。監視またはサービスコール。
ただし、私が説明したこのシナリオは、うまく機能しない可能性があります。本社とより緊密に結合され、「LANのような」ネットワーク条件を必要とする/予期するアプリケーション、プロセス、およびポリシーがある場合があります。そのためには、Evanによって提案されたようなより堅牢なWANサービス/サービスレベルを調べる必要があるかもしれません。