スプリット トンネル。 概要: Office 365 の VPN スプリット トンネリング

VPNスプリットトンネリングとは?

スプリット トンネル

注意 これは、リモート ユーザーを対象とした Office 365 の最適化について説明している一連のトピックの中の一つです。 This topic is part of a set of topics that address Office 365 optimization for remote users. リモート ユーザー向けの Office 365 接続を最適化するため、VPN スプリット トンネリングを使用する方法の概要については、「」を参照してください。 For an overview of using VPN split tunneling to optimize Office 365 connectivity for remote users, see. 中国のユーザー向けの Office 365 ワールドワイド テナント パフォーマンスの最適化については、「」を参照してください。 For information about optimizing Office 365 worldwide tenant performance for users in China, see. 企業は長年にわたり、ユーザーのリモートでの環境を支援するため、VPN を使用してきました。 For many years enterprises have been using VPNs to support remote experiences for their users. 中心となる作業領域はオンプレミスにありましたが、企業のネットワーク上のデータセンターを通じてルーティングされるリモート クライアントからの VPN は、リモート ユーザーが企業のリソースにアクセスするための主要な方法でした。 Whilst core workloads remained on-premises, a VPN from the remote client routed through a datacenter on the corporate network was the primary method for remote users to access corporate resources. 接続を保護するため、企業は VPN パスに沿ってネットワーク セキュリティ ソリューションのレイヤを構築します。 To safeguard these connections, enterprises build layers of network security solutions along the VPN paths. これは、内部のインフラストラクチャを保護するとともに、トラフィックを VPN に再ルーティングしてからオンプレミスのインターネット境界に通すことで、外部 Web サイトのモバイル ブラウズを保護するために行われてきました。 This was done to protect internal infrastructure as well as to safeguard mobile browsing of external web sites by rerouting traffic into the VPN and then out through the on-premises Internet perimeter. VPN、ネットワーク境界、および関連するセキュリティ インフラストラクチャは、多くの場合、決められたトラフィック量に合わせて構築および拡張され、通常は大部分の接続が企業のネットワーク内で開始され、その大部分はトラフィックの内部ネットワーク境界に留まります。 VPNs, network perimeters and associated security infrastructure were often purpose built and scaled for a defined volume of traffic, typically with the majority of connectivity being initiated from within the corporate network, and most of it staying withing the internal network boundaries. 長い間、リモート ユーザー デバイスからのすべての接続がオンプレミス ネットワークにルーティングされる VPN モデル いわゆる 強制トンネリング は、リモート ユーザーの同時接続規模を控えめにし、VPN を横断するトラフィック量を少なく済ませる限りは、ほぼ持続可能でした。 For quite some time, VPN models where all connections from the remote user device are routed back into the on-premises network known as forced tunneling were largely sustainable as long as the concurrent scale of remote users was modest and the traffic volumes traversing VPN were low. 一部の企業は、アプリケーションが企業の境界内からパブリック SaaS クラウドに移行した後でも、VPN 強制トンネリングをそのまま使用し続けてきました。 Office365 がその代表的な例です。 Some customers continued to use VPN force tunneling as the status quo even after their applications moved from inside the corporate perimeter to public SaaS clouds, Office 365 being a prime example. 分けられていたり、パフォーマンスに敏感なクラウド アプリケーションへの接続に強制トンネリングされた VPN を使用することは、とても適切とは言えませんが、セキュリティの観点から現状を維持するために、そのマイナスの影響も一部の企業では受け入れられてきたのかもしれません。 The use of forced tunneled VPNs for connecting to distributed and performance sensitive cloud applications is extremely suboptimal, but the negative impact of that may have been accepted by some enterprises so as to maintain the status quo from a security perspective. このシナリオの例となる図を次に示します。 An example diagram of this scenario can be seen below: この問題は年々増加しており、多くの企業がネットワークのトラフィック パターンの大きな変化を訴えています。 This problem has been growing for a number of years, with many customers reporting a significant shift of network traffic patterns. 以前はオンプレミスにあったトラフィックが、外部のクラウド エンドポイントに接続するようになりました。 Traffic which used to stay on premises now connects to external cloud endpoints. Microsoft ユーザーの多くから、以前はネットワーク トラフィックの約 80 %は内部ソース 上記の図の点線で示した部分 に送られるものだったという報告があります。 2020 年には、主要な作業領域をクラウドに移行したことにより、その割合は約 20 %以下になりました。 この傾向は他の企業でも珍しいことではありません。 クラウドへの移行の旅を進めていくほど、上記のモデルはますます扱いにくく、持続不可能になり、組織がすばやくクラウド ファーストの世界へ足を踏み入れることを妨げます。 Over time, as the cloud journey progresses, the above model becomes increasingly cumbersome and unsustainable, preventing an organization from being agile as they move into a cloud first world. 世界的な COVID-19 禍により、この問題に対する即時の対応が必要とされています。 The worldwide COVID-19 crisis has escalated this problem to require immediate remediation. IT 企業には、社員の安全を確保するため、大規模な在宅勤務の生産性を援助しなければいけないというこれまでにない要求が生じています。 The need to ensure employee safety has generated unprecedented demands on enterprise IT to support work-from-home productivity at a massive scale. Microsoft Office 365 は、企業のそういった需要を満たすうってつけの製品ですが、自宅で同時に作業するユーザーの割合が高くなると、Office 365 のトラフィックが大量に生成され、強制トンネリング VPN とオンプレミスのネットワークの境界を介してルーティングされると、急速な飽和を引き起こし、VPN インフラストラクチャが容量不足となります。 Microsoft Office 365 is well positioned to help customers fulfil that demand, but high concurrency of users working from home generates a large volume of Office 365 traffic which, if routed through forced tunnel VPN and on-premises network perimeters, causes rapid saturation and runs VPN infrastructure out of capacity. 現在の状況下では、VPN を使用して Office 365 にアクセスすることは、単なるパフォーマンスの障害になるだけでなく、Office 365、さらに VPN に依存して動作する重要な社内業務に影響を与えます。 In this new reality, using VPN to access Office 365 is no longer just a performance impediment, but a hard wall which not only impacts Office 365 but critical business operations which still have to rely on the VPN to operate. Microsoft は、お客様や幅広い業界と長年にわたって緊密に連携し、これらの問題に対して、当社のサービス内から効果的かつ最新のソリューションを提供し、より最適な業務の実現をサポートしています。 Microsoft has been working closely with customers and the wider industry for many years to provide effective, modern solutions to these problems from within our own services, and to align with industry best practice. Office 365 サービスの「」は、組織がセキュリティを維持し、接続を制御できるようにしつつ、リモート ユーザーに対して効率的に機能するように設計されています。 for the Office 365 service have been designed to work efficiently for remote users whilst still allowing an organization to maintain security and control over their connectivity. このソリューションは、少ない作業量ですばやく対処が可能で、上記で説明した問題に対し大きなプラスの影響を与えます。 These solutions can also be implemented very quickly with limited work yet achieve a significant positive impact on the problems outlined above. リモート ワーカーの接続を最適化するため Microsoft が推進している戦略として、従来のアプローチの問題を迅速に緩和し、簡単な数ステップで高いパフォーマンスを提供することを目指しています。 Microsoft's recommended strategy for optimizing remote worker's connectivity is focused on rapidly alleviating the problems with the traditional approach and also providing high performance with a few simple steps. この段階では、ボトルネックとなる VPN サーバをバイパスする、少数の決められたエンドポイントに対する従来の VPN アプローチを調整します。 These steps adjust the legacy VPN approach for a small number of defined endpoints which bypass bottlenecked VPN servers. 同等、あるいはより優れたセキュリティ モデルを異なるレイヤに適用することで、企業ネットワークの出口ですべてのトラフィックを保護する必要がなくなります。 An equivalent or even superior security model can be applied at different layers to remove the need to secure all traffic at the egress of the corporate network. ほとんどの場合、これは数時間以内に効果的に実現でき、要件と時間が許す限りは、他の作業領域に対しても拡張性があります。 In most cases this can be effectively achieved within hours and is then scalable to other workloads as requirements demand and time allows. 一般的な VPN のシナリオ Common VPN scenarios 以下のリストには、企業での環境で最も一般的な VPN のシナリオを表示しています。 In the list below you'll see the most common VPN scenarios seen in enterprise environments. ほとんどの企業は、従来モデル 1 VPN 強制トンネリング を運用しています。 Most customers traditionally operate model 1 VPN Forced Tunnel. 当項目では、比較的少ない労力で実現可能で、ネットワークのパフォーマンスとユーザー環境に大きなメリットをもたらす「 モデル 2」にすばやく安全に移行するご案内を行います。 This section will help you to quickly and securely transition to model 2, which is achievable with relatively little effort, and which has enormous benefits to network performance and user experience. VPN tunnel is used by default default route points to VPN , with few, most important exempt scenarios that are allowed to go direct VPN トンネルが既定で使用されているものの 既定のルートが VPN を指し示している 、直接アクセスが許可されている例外が広範囲にある すべての Office 365、すべての Salesforce、すべての Zoom など VPN tunnel is used by default default route points to VPN , with broad exceptions that are allowed to go direct such as all Office 365, All Salesforce, All Zoom VPN トンネルは、企業専用サービスにのみ使用される。 VPN tunnel is used only for corpnet based services. 既定のルート インターネットとすべてのインターネット ベースのサービス は直接アクセスとなる。 Default route Internet and all Internet based services goes direct. 2の変化型。 VPN 強制トンネリング 1. VPN Forced Tunnel これは、ほとんどの企業ユーザーにとっては最も一般的なスタート地点になります。 This is the most common starting scenario for most enterprise customers. Office 365 や、インターネットの閲覧などの外部 インターネット に向かうトラフィックは、プロキシなどのオンプレミスのセキュリティ機器から一度出た後戻ってきます。 Any external Internet bound traffic such as Office 365 or Internet browsing is then hairpinned back out of the on premises security equipment such as proxies. 少数の認可された例外を含む VPN 強制トンネル 2. VPN Forced Tunnel with a small number of trusted exceptions このモデルでは、高負荷で遅延の影響を受けやすい、制御され決められた少数のエンドポイントが VPN トンネルをバイパスし、この例ならば Office 365 サービスに直接移動ができます。 企業にとってははるかに効率的な運用になります。 This model is significantly more efficient for an enterprise to operate under as it allows a small number of controlled and defined endpoints which are very high load and latency sensitive to bypass the VPN tunnel and go direct to the Office 365 service in this example. これにより、実行されたサービスのパフォーマンスが大幅に向上し、また、VPN インフラストラクチャの負荷が軽減されるため、リソースの競合を抑えて動作させなければいけない要素も実現可能になります。 This significantly improves the performance for the offloaded services, and also decreases the load on the VPN infrastructure, thus allowing elements which still require it to operate with lower contention for resources. 簡略で決められたアクションをすばやく実行でき、多くのプラスの結果につながるため、当記事ではこのモデルへの移行を支援することに集中しています。 It is this model which this article concentrates on assisting with the transition to as it allows for simple, defined actions to be taken very quickly with numerous positive outcomes. 広範囲な例外を含む VPN 強制トンネリング 3. VPN Forced Tunnel with broad exceptions 3 番目のモデルでは、決められた小さいエンドポイントのグループを直接送信するのではなく、モデル 2 の範囲を広げ、Office 365、SalesForce などの信頼されたサービスにすべてのトラフィックを直接送信します。 The third model broadens the scope of model two as rather than just sending a small group of defined endpoints direct, it instead sends all traffic to trusted services such Office 365, SalesForce etc. direct. これにより、企業の VPN インフラストラクチャの負荷がさらに軽減され、決められたサービスのパフォーマンスが向上します。 This further reduces the load on the corporate VPN infrastructure and improves the performance of the services defined. このモデルは、実現性を評価し、実装するためにはより多くの時間がかかる可能性があるため、モデル 2 の実装に成功してから、後日繰り進むことができる段階に入ることになるでしょう。 As this model is likely to take more time to assess the feasibility of and implement, it is likely a step which can be taken iteratively at a later date once model two is successfully in place. VPN 選択的トンネリング 4. VPN selective Tunnel このモデルは、企業 IP アドレスを持つトラフィックのみが VPN トンネルに送信され、他の全ての既定のルートはインターネット パスになるため、3番目のモデルの逆になります。 This model reverses the third model in that only traffic identified as having a corporate IP address is sent down the VPN tunnel and thus the Internet path is the default route for everything else. このモデルでは、組織がへの道を歩み、安全な実装ができる必要があります。 This model requires an organization to be well on the path to in able to safely implement this model. このモデルや、そこからの変化型は、企業ネットワークからクラウドに移行するサービスが増えるにつれて、既定のモデルとなることが求められてくるでしょう。 It should be noted that this model or some variation thereof will likely become the necessary default over time as more and more services move away from the corporate network and into the cloud. Microsoft では、このモデルを内部で使用しています。 Microsoft の VPN スプリット トンネリングの実装の詳細については、「」をご覧ください。 Microsoft uses this model internally; you can find more information on Microsoft's implementation of VPN split tunneling at. VPN なし 5. No VPN モデル番号 2 のより高度なバージョンであり、内部サービスは最新のセキュリティ アプローチまたは Azure AD プロキシ、MCAS、Zscaler ZPA などの SDWAN ソリューションを通じて公開されます。 A more advanced version of model number two, whereby any internal services are published through a modern security approach or SDWAN solution such as Azure AD Proxy, MCAS, Zscaler ZPA etc. スプリット トンネル VPN の実装 Implement VPN split tunneling 当項目では、「」項目から、お使いの VPN クライアントのアーキテクチャを 「 VPN 強制トンネリング」から「 少数の認可された例外を含む VPN 強制トンネリング」、「」 に移行するための簡単な手順について説明します。 In this section, you'll find the simple steps required to migrate your VPN client architecture from a VPN forced tunnel to a VPN forced tunnel with a small number of trusted exceptions, in the section. 次の図は、推奨している VPN スプリット トンネリング ソリューションのしくみを示しています。 The diagram below illustrates how the recommended VPN split tunnel solution works: 1. 最適化するエンドポイントを決める 1. Identify the endpoints to optimize 「」のトピックでは、Microsoft は最適化する必要のある主要なエンドポイントを明確に識別し、それらを「 最適化」として分類しています。 In the topic, Microsoft clearly identifies the key endpoints you need to optimize and categorizes them as Optimize. 現在、最適化が必要な URL は 4 つ、IP サブネットは 20 のみです。 There are currently just four URLS which need to be optimized and twenty IP subnets. これは、元々私たちが特別に注意を払わなければいけないトラフィックであり、従来のネットワーク パスと VPN インフラストラクチャに激しい圧力をかけるトラフィックでもあります。 Essentially this is the traffic that we need to take special care of and is also the traffic which will put incredible pressure on traditional network paths and VPN infrastructure. このカテゴリの URL には、次のような特性があります。 URLs in this category have the following characteristics:• Microsoft インフラストラクチャにホストされている Microsoft が所有および管理するエンドポイントである Are Microsoft owned and managed endpoints, hosted on Microsoft infrastructure• IP が提供されている Have IPs provided• 変化率が低く、数も少ないと予想される 現在 20 の IP サブネット Low rate of change and are expected to remain small in number currently 20 IP subnets• 必要なセキュリティ要素をネットワーク上で、インラインではなくサービスで提供することができる Are able to have required security elements provided in the service rather than inline on the network• Microsoft has committed to suspending changes to Optimize endpoints for Office 365 until at least June 30 2020, allowing customers to focus on other challenges rather than maintaining the endpoint whitelist once initially implemented. 当記事は、今後の変更を反映して更新されます。 This article will be updated to reflect any future changes. Office 365 エンドポイント、およびその分類と管理方法の詳細については、「」の記事を参照してください。 For more information about Office 365 endpoints and how they are categorized and managed, see the article. URL を最適化する Optimize URLs 現在の最適化 URL は次の表に記載されています。 The current Optimize URLs can be found in the table below. ほとんどの状況では、エンドポイントがプロキシにではなく直接送信されるように設定されているの URL エンドポイントのみを使用する必要があります。 Under most circumstances, you should only need to use URL endpoints in a where the endpoints are configured to be sent direct, rather than to the proxy. This is one of the primary URLs Outlook uses to connect to its Exchange Online server and has a high volume of bandwidth usage and connection count. クイック検索、その他のメールボックス 予定表、空き時間の検索、ルールと通知の管理、Exchange オンラインのアーカイブ、送信トレイからのメール送信などといったオンライン上の機能では、ネットワークの遅延を少なくしておく必要があります。 TCP 443 TCP 443 このURLは Outlook Online Web Access が Exchange Online のサーバーに接続するために使用され、ネットワーク遅延の影響を受けやすくなっています。 This URL is used for Outlook Online Web Access to connect to Exchange Online server, and is sensitive to network latency. SharePoint Online での大きなファイルのアップロードとダウンロードには、特に接続性が必要です。 Connectivity is particularly required for large file upload and download with SharePoint Online. sharepoint. com TCP 443 TCP 443 これは SharePoint Online の主要な URL で、帯域幅の使用率が高くなっています。 This is the primary URL for SharePoint Online and has high bandwidth usage. sharepoint. sharepoint. com TCP 443 TCP 443 これは OneDrive for Business の標準 URL で、帯域幅の使用率が高く、OneDrive for Business Sync ツールからの接続数が多くなることがあります。 This is the primary URL for OneDrive for Business and has high bandwidth usage and possibly high connection count from the OneDrive for Business Sync tool. Teams のメディア IP URL なし Teams Media IPs no URL UDP 3478、3479、3480、および3481 UDP 3478, 3479, 3480, and 3481 リレー検出の割り当てとリアルタイムトラフィック 3478 、オーディオ 3479 、ビデオ 3480 、ビデオ画面共有 3481。 Relay Discovery allocation and real time traffic 3478 , Audio 3479 , Video 3480 , and Video Screen Sharing 3481. これらは、Skype for Business および Microsoft Teams メディアのトラフィック 通話、会議など に使用されるエンドポイントです。 These are the endpoints used for Skype for Business and Microsoft Teams Media traffic calls, meetings etc. ほとんどのエンドポイントは、Microsoft Teams クライアントが発信を確立するときに提供されます サービスのリストにある必要な IP 内に含まれています。 Most endpoints are provided when the Microsoft Teams client establishes a call and are contained within the required IPs listed for the service. メディアの品質を最適化するには、UDP プロトコルを使用する必要があります。 Use of the UDP protocol is required for optimal media quality. 上記の例では、 テナントをお使いの Office 365 のテナント名に置き換える必要があります。 In the above examples, tenant should be replaced with your Office 365 tenant name. たとえば、 contoso. onmicrosoft. com では、 contoso. sharepoint. sharepoint. For example, contoso. onmicrosoft. com would use contoso. sharepoint. com and constoso-my. sharepoint. com. IP アドレスの範囲を最適化する Optimize IP address ranges これらのエンドポイントが対応する IP 範囲を記述する時は、次のように記述します。 At the time of writing the IP ranges which these endpoints correspond to are as follows. 設定を適用するときに更新を確認し、定期的に実行するポリシーを定めておくために、この例のような、、またはを使用することを 大変強く推奨します。 It is very strongly advised you use a example, the or the to check for any updates when applying the configuration, and put a policy in place to do so on a regular basis. 104. 146. 128. 107. 128. 107. 136. 107. 107. 107. 253. 245. 171. 171. 234. 140. 197. 103. 160. 104. 108. 128. 104. 112. 120. VPN を介して、これらのエンドポイントへのアクセスを最適化する 2. Optimize access to these endpoints via the VPN こういった重要なエンドポイントを特定したら、それを VPN トンネルから逸らし、ユーザーのローカル インターネット接続を使用してサービスに直接接続できるようにする必要があります。 Now that we have identified these critical endpoints, we need to divert them away from the VPN tunnel and allow them to use the user's local Internet connection to connect directly to the service. これを実現する方法は、使用する VPN 製品とマシンのプラットフォームによって異なりますが、ほとんどの VPN ソリューションでは、この手法を適用するポリシーを簡単に構成することができます。 The manner in which this is accomplished will vary depending on the VPN product and machine platform used but most VPN solutions will allow some simple configuration of policy to apply this logic. VPN プラットフォーム固有のスプリット トンネリングを行う方法については、「」をご覧ください。 For information VPN platform-specific split tunnel guidance, see. ソリューションを手動でテストしたい場合は、次の PowerShell の例を実行して、ルート テーブルからソリューションをエミュレートできます。 If you wish to test the solution manually, you can execute the following PowerShell example to emulate the solution at the route table level. この例では、それぞれの Teams メディア IP サブネットのルートをルート テーブルに追加します。 This example adds a route for each of the Teams Media IP subnets into the route table. Teams のメディアの前後でのパフォーマンスをテストをし、指定されたエンドポイントのルートの違いを観察できます。 You can test Teams media performance before and after, and observe the difference in routes for the specified endpoints. 120. 112. 107. NextHop を PowerShellで実行し検索します。 NextHop in PowerShell. ルートを追加したら、コマンド プロンプトまたは PowerShell で「 印刷のルーティング」を実行して、ルート テーブルが正しいことを確認できます。 Once you have added the routes, you can confirm that the route table is correct by running route print in a command prompt or PowerShell. 出力には、追加したルートが含まれ、インターフェースのインデックス この例では 22 とそのインターフェースのゲートウェイ この例では 192. 168. 1 が表示されます。 The output should contain the routes you added, showing the interface index 22 in this example and the gateway for that interface 192. 168. 1 in this example : 「最適化」カテゴリにある すべての現在の IP アドレス範囲のルートを追加するには、次のスクリプトの型を使用して、現在の最適化 IPの一連のサブネットの にクエリを実行し、それをルート テーブルに追加します。 To add routes for all current IP address ranges in the Optimize category, you can use the following script variation to query the for the current set of Optimize IP subnets and add them to the route table. office. The VPN client should be configured so that traffic to the Optimize IPs are routed in this way. これは、Office 365 サービスと接続エンドポイントをできるかぎりユーザーの近くに提供する 、 Office 365 サービス フロントドアなどのローカルの Microsoft リソースをトラフィックが活用できるようにします。 This allows the traffic to utilize local Microsoft resources such as Office 365 Service Front Doors which deliver Office 365 services and connectivity endpoints as close to your users as possible. これにより、ユーザーが世界中のどこにいても非常に高いパフォーマンスを発揮することを可能にし、送信してからわずか数ミリ秒の範囲内で を最大限に活用することがきます。 This allows us to deliver extremely high performance levels to users wherever they are in the world and takes full advantage of , which is very likely within a small number of milliseconds of your users' direct egress. Teams メディア トラフィックの構成と保護 Configuring and securing Teams media traffic 一部の管理者は、スプリット トンネリング モデルを使用した Teams での発信フローの動作方法と接続のセキュリティを保護する方法に関して詳細な情報が必要かもしれません。 Some administrators may require more detailed information on how call flows operate in Teams using a split tunneling model and how connections are secured. 構成 Configuration 通話と会議の両方で、Teams のメディアに必要な最適化 IP サブネットがルートテーブルに正しく配置されている限り、Teams が GetBestRoute メソッドを呼び出して特定の宛先に使用するインターフェイスを決定すると、上記の Microsoft IP ブロックにある Microsoft の宛先にローカルのインターフェイスが返されます。 For both calls and meetings, as long as the required Optimize IP subnets for Teams media are correctly in place in the route table, when Teams calls the GetBestRoute method to determine which interface it should use for a particular destination, the local interface will be returned for Microsoft destinations in the Microsoft IP blocks listed above. 一部の VPN クライアント ソフトウェアでは、URL に基づいてルーティング操作が可能です。 Some VPN client software allows routing manipulation based on URL. ただし、Teams のメディア トラフィックには URL が関連付けられていないため、このトラフィックのルーティングの制御は IP サブネットを使用して行う必要があります。 However, Teams media traffic has no URL associated with it, so control of routing for this traffic must be done using IP subnets. 特定の状況では、Teams クライアントの設定とは関係なく、メディア トラフィックは正しいルートが設定されていても VPN トンネルを通過します。 In certain scenarios, often unrelated to Teams client configuration, media traffic still traverses the VPN tunnel even with the correct routes in place. この状況下では、ファイアウォール規則を用い、Teams IP サブネットまたはポートが VPN を使用するのをブロックすればいいでしょう。 If you encounter this scenario then using a firewall rule to block the Teams IP subnets or ports from using the VPN should suffice. 重要 すべての VPN シナリオの目的の方法で Teams のメディアトラフィックがルーティングされるようにするには、ユーザーが Microsoft Teams クライアントバージョン 1. 13565またはそれ以上を実行していることを確認してください。 To ensure Teams media traffic is routed via the desired method in all VPN scenarios, please ensure users are running Microsoft Teams client version 1. 13565 or greater. このバージョンには、クライアントが利用可能なネットワークパスを検出する方法が改善されています。 This version includes improvements in how the client detects available network paths. セキュリティ Security スプリット トンネリングを避けるべきか考える上でよくある議論の 1 つは、安全性が低いことです。 One common argument for avoiding split tunnels is that it is less secure to do so, i. e たとえば、VPN トンネルを通過しないトラフィックは、VPN トンネルに適用される暗号化スキームの恩恵を受けないため、安全性が低下します。 any traffic that does not go through the VPN tunnel will not benefit from whatever encryption scheme is applied to the VPN tunnel, and is therefore less secure. これに対する主な反論は、機密性、認証、および RTP トラフィックに対する再生攻撃の保護を提供するリアルタイム転送プロトコル RTP のプロファイルである「 Secure Real-Time Transport Protocol SRTP 」によってメディアのトラフィックがすでに暗号化されていることです。 The main counter-argument to this is that media traffic is already encrypted via Secure Real-Time Transport Protocol SRTP , a profile of Real-Time Transport Protocol RTP that provides confidentiality, authentication, and replay attack protection to RTP traffic. SRTP 自体は、ランダムに生成されたセッションキーに依存します。 これは、TLS で保護された出力チャネルを介して交換されます。 SRTP itself relies on a randomly generated session key, which is exchanged via the TLS secured signaling channel. これについては、で詳しく説明していますが、重要な部分はメディアの暗号化です。 This is covered in great detail within , but the primary section of interest is media encryption. メディア トラフィックは SRTP を使用して暗号化されます。 SRTP は、セキュリティ保護された乱数ジェネレータによって生成され、シグナル出力 TLS チャネルで交換されるセッションキーを使用します。 Media traffic is encrypted using SRTP, which uses a session key generated by a secure random number generator and exchanged using the signaling TLS channel. さらに、仲介サーバーとその内部の次ホップの間で双方向に流れるメディアも、SRTP を使用して暗号化されます。 In addition, media flowing in both directions between the Mediation Server and its internal next hop is also encrypted using SRTP. VPN トンネルを使用してクライアントを企業ネットワークに接続する場合でも、トラフィックが企業ネットワークを離れてサービスに到達するときは、SRTP フォームでトラフィックを流す必要があります。 It is worth noting that even though a VPN tunnel may be used to connect the client to the corporate network, the traffic still needs to flow in its SRTP form when it leaves the corporate network to reach the service. Teams が音声や Session Traversal Utilities for NAT STUN 増幅攻撃などのよくあるセキュリティの問題をどのように軽減するかに関する情報は、に記載されています。 Information on how Teams mitigates common security concerns such as voice or Session Traversal Utilities for NAT STUN amplification attacks can be. リモートワーク環境での最新のセキュリティ管理については、「」を参照してください。 You can also read about modern security controls in remote work scenarios at. テスト Testing ポリシーを設定したら、予測どおりに機能していることを確認しましょう。 Once the policy is in place, you should confirm it is working as expected. ローカル インターネット接続を使用するようにパスが正しく設定されているかどうかテストするには、いくつかの方法があります。 There are multiple ways of testing the path is correctly set to use the local Internet connection:• 上記の追跡ルートを含む接続テストを実行する を実行します。 Run the which will run connectivity tests for you including trace routes as above. また、VPN テストをこのツールに追加し、より詳しい情報を観察できるようにします。 We're also adding in VPN tests into this tooling which should also provide some additional insight. スプリット トンネリングの範囲にあるエンドポイントへ簡単に tracert を行うには、たとえば、次のようなパスを示す必要があります。 A simple tracert to an endpoint within scope of the split tunnel should show the path taken, for example: tracert worldaz. teams. microsoft. com 次に、ローカルの ISP を介してこのエンドポイントへのパスが表示されていれば、スプリット トンネリング用に構成した Teams の範囲の IP アドレスに解決されるはずです。 You should then see a path via the local ISP to this endpoint which should resolve to an IP in the Teams ranges we have configured for split tunneling. Wireshark などのツールを使用してネットワーク キャプチャを取得します。 Take a network capture using a tool such as Wireshark. 発信中に UDP でフィルタリングすると、 Teams の「 最適化」範囲の IP アドレスに流れるトラフィックが表示されます。 Filter on UDP during a call and you should see traffic flowing to an IP in the Teams Optimize range. VPN トンネルがこのトラフィックに使用されている場合、メディア トラフィックは追跡情報に表示されません。 If the VPN tunnel is being used for this traffic, then the media traffic will not be visible in the trace. 追加のサポート ログ Additional support logs トラブル シューティングのためにさらにデータが必要な場合、または Microsoft のサポートが必要な場合は、次の情報を集めておくと、解決策を迅速に見つけることができます。 If you need further data to troubleshoot, or are requesting assistance from Microsoft support, obtaining the following information should allow you to expedite finding a solution. Microsoft サポートの 「 TSS Windows CMD ベース汎用トラブル シューティング スクリプト ツール セット」は、関連するログを簡単な方法で収集できるよう手助けしてくれます。 Microsoft support's TSS Windows CMD based universal TroubleShooting Script toolset can help you to collect the relevant logs in a simple manner. ツールと使用手順は をご参照ください。 The tool and instructions on use can be found at 一般 VPN プラットフォームのHOWTO ガイド HOWTO guides for common VPN platforms 当項目では、この分野の最も一般的なパートナーが Office 365 トラフィックにスプリット トンネリングを実装する詳細なガイドへのリンクを示します。 This section provides links to detailed guides for implementing split tunneling for Office 365 traffic from the most common partners in this space. ガイドは利用可能になり次第、追加する予定です。 We'll add additional guides as they become available. Windows 10 VPN クライアント: Windows 10 VPN client:• Cisco Anyconnect: Cisco Anyconnect:• Palo Alto GlobalProtect: Palo Alto GlobalProtect:• F5 ネットワーク BIG-IP APM: F5 Networks BIG-IP APM:• Citrix Gateway: Citrix Gateway:• Pulse Secure: Pulse Secure:• チェックポイント VPN: Check Point VPN: FAQ FAQ Microsoft セキュリティ チームは、セキュリティの専門家と IT が今日の特殊なリモートワーク環境で最新のセキュリティ制御を実現できる主要な方法を概説するを公開しました。 The Microsoft Security Team have published which outlines key ways for security professionals and IT can achieve modern security controls in today's unique remote work scenarios. さらに、この件に関してお客様からよく寄せられる質問と回答を以下に示します。 In addition, below are some of the common customer questions and answers on this subject. データを引き出される可能性がある、信頼していない他のテナントにユーザーがアクセスすることを防ぐにはどうすればいいですか? How do I stop users accessing other tenants I do not trust where they could exfiltrate data? が回答になります。 The answer is a. 認証トラフィックは、量が多くない、もしくは特に遅延の影響を受けにくいため、VPN ソリューションを介して、機能が設定されているオンプレミスのプロキシに送信できます。 Authentication traffic is not high volume nor especially latency sensitive so can be sent through the VPN solution to the on-premises proxy where the feature is applied. 信頼されたテナントのアクセス許可リストがこの中に保持され、クライアントが信頼されていないテナントへのトークンを取得しようとした場合、プロキシは要求を拒否します。 An allow list of trusted tenants is maintained here and if the client attempts to obtain a token to a tenant which is not trusted, the proxy simply denies the request. 信頼されているテナントの場合、ユーザーが適切な資格情報とアクセス権限を持っていると、トークンを取得できます。 If the tenant is trusted, then a token is accessible if the user has the right credentials and rights. このモデルでは、個人の OneDrive アカウントなど、コンシューマー サービスへのアクセスはできますか? Does this model allow access to consumer services such as personal OneDrive accounts? いいえ、できません。 Office 365 のエンドポイントはコンシューマーサービス 例として Onedrive. live. com と同じではないため、スプリット トンネリングではユーザーはコンシューマー サービスに直接アクセスできません。 No, it does not, the Office 365 endpoints are not the same as the consumer services Onedrive. live. com as an example so the split tunnel will not allow a user to directly access consumer services. コンシューマー エンドポイントへのトラフィックは引き続き VPN トンネルを使用し、既存のポリシーが引き続き適用されます。 Traffic to consumer endpoints will continue to use the VPN tunnel and existing policies will continue to apply. トラフィックがオンプレミスのソリューションを通過しなくなったときに、DLP を適用して機密データを保護するにはどうすればよいですか? How do I apply DLP and protect my sensitive data when the traffic no longer flows through my on-premises solution? 機密情報が不注意により漏洩することを防ぐため、Office 365 には豊富なのセットがあります。 To help you prevent the accidental disclosure of sensitive information, Office 365 has a rich set of. Teams と SharePoint の組み込みの を使用して、不適切に保存または共有された機密情報を検出できます。 You can use the built-in of Teams and SharePoint to detect inappropriately stored or shared sensitive information. リモート ワーク戦略の一部にデバイスの持ち込み BYOD ポリシーが含まれているなら、「」を使用して、機密データがユーザーの個人デバイスにダウンロードされるのを防ぐことができます。 If part of your remote work strategy involves a bring-your-own-device BYOD policy, you can use to prevent sensitive data from being downloaded to users' personal devices ユーザーが直接接続を行っている時に、ユーザーの認証制御を評価、維持するにはどうすればよいですか? How do I evaluate and maintain control of the user's authentication when they are connecting directly? Q1 に記載されているテナント制限機能に加えて、「」を適用して、認証リクエストのリスクを動的に評価し、適切な対応を行うことができます。 In addition to the tenant restrictions feature noted in Q1, can be applied to dynamically assess the risk of an authentication request and react appropriately. Microsoft は、今後「」を実装することを推奨しており、そこからモバイル、クラウド ファーストの世界で Azure AD の条件付きアクセス ポリシーを使用して制御を維持することができます。 Microsoft recommends the is implemented over time and we can use Azure AD conditional access policies to maintain control in a mobile and cloud first world. 条件付きアクセス ポリシーを使用すると、次のようなさまざまな要因に基づいて、認証要求が成功したかどうかをリアルタイムで判断できます。 Conditional access policies can be used to make a real-time decision on whether an authentication request is successful based on numerous factors such as:• IP アドレス — 認証要求は既知の企業 IP アドレスからのものか? IP — is the authentication request coming from a known corporate IP address? または信頼していない場所からのものか? Or from a country we do not trust? アプリケーション — ユーザーはこのアプリケーションの使用を許可されているか? Application — Is the user authorized to use this application? 次に、承認、MFA のトリガー、またはこれらのポリシーに基づく認証のブロックなどのポリシーをトリガーできます。 We can then trigger policy such as approve, trigger MFA or block authentication based on these policies. ウイルスやマルウェアからの保護はどうすればいいですか? How do I protect against viruses and malware? 同じく、Office 365 は、サービス自体のさまざまな層にある「最適化」のマークのあるエンドポイントを保護します。 これは。 Again, Office 365 provides protection for the Optimize marked endpoints in various layers in the service itself,. 前述のように、プロトコルやトラフィックを完全に把握していない可能性のあるデバイスに合わせるよりも、サービス自体にこれらのセキュリティ要素を加えておく方がはるかに効率的です。 既定では、SharePoint Online は既知のマルウェアに関して。 By default, SharePoint Online for known malware 上記の Exchange エンドポイントの場合、 および は、サービスにトラフィックのセキュリティを提供するという優れた機能を果たします。 For the Exchange endpoints listed above, and do an excellent job of providing security of the traffic to the service. 「最適化」トラフィック以外にも直接送信は行えますか? Can I send more than just the Optimize traffic direct? 「 最適化」マークの付いたエンドポイントが優先されます。 これらのエンドポイントは、下位レベルでの作業に最大の利益をもたらすからです。 Priority should be given to the Optimize marked endpoints as these will give maximum benefit for a low level of work. ただし、お望みであれば、サービスが機能し、必要に応じて使用できる IP アドレスがエンドポイントに提供されるよう、「許可」マークの付いたエンドポイントが必要になります。 However, if you wish, the Allow marked endpoints are required for the service to work and have IPs provided for the endpoints which can be used if required. これらのソリューションは、可用性、パフォーマンスが高く、ユーザーの近くに準備されていれば、ユーザー近くのクラウド ベースの場所から安全なインターネット アクセスを提供できるため、クラウド ファーストの世界で能力を発揮します。 These solutions can work well in a cloud first world, if highly available, performant, and provisioned close to your users by allowing secure Internet access to be delivered from a cloud based location close to the user. ただし、このソリューションが導入されていても、「最適化」マーク済みの Office 365 トラフィックをサービスに直接送信することを強くお勧めします。 Even with these solutions in place however, Microsoft still strongly recommends that Optimize marked Office 365 traffic is sent direct to the service. Azure Virtual Network への直接アクセスを許可する方法については、「」の記事をご覧ください。 For guidance on allowing direct access to an Azure Virtual Network, see the article. なぜポート 80 が必要なのですか? Why is port 80 required? トラフィックは平文で送信されていますか? Is traffic sent in the clear? ポート 80 はポート 443 セッションへのリダイレクトなどにのみ使用され、顧客データは送信されないか、ポート 80 経由ではアクセスできません。 Port 80 is only used for things like redirect to a port 443 session, no customer data is sent or is accessible over port 80. では、Office 365 の転送中および保存中のデータの暗号化について、では、SRTP を使用してTeams のメディア トラフィックを保護する方法について概説しています。 outlines encryption for data in transit and at rest for Office 365, and outlines how we use SRTP to protect Teams media traffic. この内容は、Office 365 のワールドワイド インスタンスを使用している中国のユーザーにも適用されますか? Does this advice apply to users in China using a worldwide instance of Office 365? いいえ、されません。 No, it does not. 上記内容で 1 つ注意していただきたいことは、ワールドワイド Office 365 インスタンスに接続している PRC のユーザーです。 The one caveat to the above advice is users in the PRC who are connecting to a worldwide instance of Office 365. この地域ではクロスボーダー ネットワークの混雑が頻繁に発生するため、直接のインターネットの下りのパフォーマンスは変動する可能性があります。 Due to the common occurrence of cross border network congestion in the region, direct Internet egress performance can be variable. 当地域のほとんどのユーザーは、VPN を使用して企業ネットワークにトラフィックを取り込み、許可された MPLS 回線などを利用し、最適化されたパスを介して国外への送信を行っています。 Most customers in the region operate using a VPN to bring the traffic into the corporate network and utilize their authorized MPLS circuit or similar to egress outside the country via an optimized path. これについては、の記事で詳しく説明しています。 This is outlined further in the article. 関連項目 Related topics 関連記事.

次の

VPN

スプリット トンネル

こんにちは。 久しぶりにエンジニアブログを更新したいと思います。 本日のお題は今年になってリリースされた新機能「スプリットトンネル」です。 この機能は、先日紹介したCAPWAPに付随する機能で、ユーザトラフィックの経路変更によりコントローラの通信負荷を軽減させることができます。 Wi-Fi利用者がWebアクセスする時には、一般的にWeb認証を行った後にインターネットに接続できるようになります。 これまでのCAPWAPを設定したネットワークの場合には、認証のパケット、DHCPにより払い出されるIPアドレス、ユーザのWebデータ等のすべてのパケットはトンネル化され、必ずコントローラを経由した通信になります。 ユーザが増えれば、当然コントローラの負荷は重くなり通信速度に影響がでます。 そこで、認証等の制御トラフィックと実際のユーザトラフィックをスプリット(分離)させ、ユーザトラフィックはトンネル化せずに通信できるようにしたのが「スプリットトンネル」です。 つまり、ユーザデータはコントローラを経由せずに通信できるのです。 今回は以下のようなネットワークで「スプリットトンネル」を構成してみました。 「スプリットトンネル」で接続された無線クライアントからInternet上のサイト(例:www. goo. jp等)にtracerouteコマンドを実行すると、WHG325を経由せずにパケットが転送されていることが確認できると思います。 ちなみに認証前のパケットはAPで止まります。 「スプリットトンネル」を構成する上で、注目したい点が2つあります。 「スプリットトンネル」で接続する無線クライアントのIPアドレスは、上図のRouter DHCP1 が払い出します。 「コンプリートトンネル」で接続する無線クライアントはコントローラであるWHG325(DHCP2)が払い出している点と異なります。 もう一つは、「スプリットトンネル」を構成できるのは、コントローラのWANポートのみだということです。 (APでコントローラのWANアドレスを指定する必要があります。 )その他、ユーザデータがコントローラを経由しないのでコントローラのファイヤーウォールを設定している場合、スプリットトンネルのユーザにはこのルールが適用されないことも注意が必要です。 それでは設定方法をご紹介したいと思います。 と言っても、これまでのCAPWAPの設定方法から変更はほとんどありません。 変更点は以下の2箇所のみです。 (APの設定) これまで「Wireless」メニューのVAP設定において、「CAPWAPトンネルインターフェース」にチェックをいれる必要がありました。 今回からは必要なく、下図のように灰色で「無効」と示されていますのでこのままで構いません。 VAPのCAPWAPの設定は、コントローラからテンプレートを適用した時に反映されます。 (コントローラの設定) 下図のテンプレートの作成メニューの中の「CAPWAPトンネルインターフェース」に「無効」、「コンプリートトンネル」、「スプリットトンネル」の3つの選択肢があるので、この中から選択します。 ちなみに「コンプリートトンネル」とは今まで通りのCAPWAPのことを指します。 APをコントローラのWAPMに登録するまでの手順は、これまで通りの設定が必要です。 詳しくは、以前の記事(WAPMにおけるCAPWAPの設定、)を参照して下さい。 それでは、ごきげんよう。

次の

スプリットトンネリング (Sun Java System Portal Server 7.1 配備計画ガイド)

スプリット トンネル

Contents• ソフトウェアについて VPN Tunnelingを使用するには、 アプリを端末へインストールする必要があります。 といっても、初回アクセス時に自動的にインストールする仕組み になっているので、特に気にする必要はありません。 ただし、スマホやタブレットから接続する場合は、事前にダウンロードセンターから アプリをインストールする必要があります。 ソフトウェアについては、以下の2つのうちどちらかを使用します。 ・Network Connect ・Junos Pulse この2つの違いとしては、大まかですが、 Linuxにも対応しているのかと、 スマホ対応かということです。 厳密にはもっと細かいです。 詳しくは、Juniper サイトにて。 Junos Pulseはスマホ対応ですが、 Linux端末には対応していません。 Split-tunneling については、最後で説明します。 最後に、Roleに「VPN Tunneling」を使用するところにチェックを入れ、 [VPN Tunneling] タブから、「Split Tunneling」を [Enable] にします。 細かい設定はもっとたくさんできて、 例を挙げると、 ・接続元IPアドレスの制御 ・Bandwidthによるユーザの接続制御 ・端末起動時に自動的にJunos Pulse の接続をしにいくかなど などが可能です。 Split-tunneling スプリットトンネル スプリットトンネルとは、 VPN経由に接続するネットワークを指定するものです。 SSL-VPN接続を行うと、プールで指定したIPアドレスが 付与され、通常、VPN経由の通信しかできなくなりますが、 スプリットトンネルを設定することで、 現状のネットワークを維持した上でVPN経由の通信も行うことが できるようになります。 スプリットトンネルの設定をしなかった場合、 インターネットへ行くときもVPN経由で接続することになります。 また、別セグメントにある社内のファイルサーバなどへはアクセスできなくなってしまいます。 そのため、スプリットトンネルの設定をし、 VPN経由にする接続先ネットワークを指定することで、 現状のネットワークは使える状態かつ、VPN先にもリモートアクセスできる状態というのを作ることができます。 以下、イメージ図です。

次の