今さらリモートワーク？まずは数人のチームから、働く環境を見直してみませんか

作業PCを手元に残し、業務サーバーと接続経路をオフィスから分離すると、別の場所から仕事を再開できる範囲が広がります。数人のチームから、Office VPN、RDP、Cloud VPCの役割と、停止時に残る依存を見直せます。

リモートワークという言葉は、もう新しくありません。それでも、「会社に行かないと仕事が進まない」という状況は、意外と残っています。

社内のファイルを開くために出社する。業務システムを使うために、会社のPCへリモート接続する。停電や回線障害が起きると、在宅勤務のメンバーまで作業が止まる。

見直したいのは、働く場所だけではありません。仕事に必要な環境が、どの場所に依存しているかです。

全社の仕組みを一度に変える必要はありません。まずは数人の部署やプロジェクトから、作業PC、サーバー、接続経路を分けて考えてみましょう。

VPNにつながっても、オフィスへの依存は残る

従来のOffice VPNは、外出先のPCを社内ネットワークへ接続する仕組みです。社内NASや業務システムを利用する方法として、今も有効です。

図1：従来のOffice VPN。外出先からオフィスのVPN装置に接続し、社内資源を利用する。直接着信を受ける構成例。VPN方式によって接続条件は異なります。

ただし、VPN装置、サーバー、電源、回線がオフィスに集まっていれば、その場所が使えなくなると接続先も失われます。在宅勤務に対応していることと、オフィス停止時に業務を続けられることは、別の課題です。

自社でWireGuardサーバーを置くなら、IPv4では到達可能なPublic IP、NAT環境ではポート転送、Firewallの許可などが必要になります。CGNATやDS-Liteでは自分のルーターだけで着信経路を作れない場合があり、MAP-Eでも使えるポートなどに条件があります。IPv6 DirectならIPv4のポート転送は不要でも、着信許可と接続元のIPv6接続性は必要です。

既存のVPNが安定して動いているなら、まずはそのまま使いながら、どこが止まると仕事も止まるのかを整理できます。

RDPは便利。ただし、画面の向こう側で処理が動く

会社のWindows PCやサーバーへRDPで接続する方法もあります。アプリやデータを社内側に集約したい場合、管理上の利点があります。RDPをInternetへ直接公開せず、VPNや適切に保護されたゲートウェイを経由させることも大切です。

図2：複数のRDPセッションが、共有ホストのCPU、メモリー、ディスクを利用する。バーは実測値ではありません。

RDPでは、基本的にアプリの処理は接続先で実行されます。共有ホストを使う場合、同時利用者が増えるとCPU、メモリー、ストレージI/Oなどを共有します。遅延や画面更新の帯域も操作感に影響します。

「人数が増えたら必ず遅くなる」という話ではありません。使うアプリ、同時実行、GPUの必要性、ホスト構成によって結果は変わります。各自が専用の会社PCへ接続する方式なら、計算資源の共有条件も異なります。WindowsのエディションやRDSのライセンス条件も確認が必要です。

一方、開発、デザイン、動画編集など、手元のPCで快適に動いている仕事まで画面転送へ移す必要があるでしょうか。

作業はローカル、必要な業務資源へはVPNで接続する。 これも現実的な選択肢です。

数人の部署から、接続する環境を分けて考える

全員を社内LAN全体へ入れる代わりに、そのチームが必要とするサーバーやネットワークへの接続から設計します。たとえば開発チームなら、開発サーバー、Git、検証用DBなどです。

図3：チームのPCと部署ゲートウェイが、それぞれCloud Hubへ外向きに接続を開始する。一般的なOutbound Hub & Spokeの設計例。矢印は接続開始方向で、確立後の業務通信は双方向です。部署の権限分離を自動的に保証する図ではありません。

Hub & Spoke型なら、各端末や拠点から中継点へ接続を集められます。拠点同士を個別に直接接続する方法と比べて、接続関係を整理しやすくなります。VPS上の自作WireGuard Hub、クラウドのマネージドVPN、P2P型のVPNなども比較対象です。P2Pでも回線条件によって中継が必要になります。

Outbound型でも、どんなネットワークからでも接続できるわけではありません。利用場所からHubへの外向きUDP通信が許可され、戻りの通信も通るかを確認します。ホテルや社内ネットワークでUDPが制限される場合は、実際の端末で接続と業務通信を試す必要があります。

また、「VPNに参加できる」と「すべての資源へアクセスできる」を分けます。宛先のアクセス制御、サーバーOSのFirewall、アプリの認証、MFA、利用者の権限を組み合わせます。端末紛失時に接続権限を取り消す手順も決めておきます。

サーバールームをCloud VPCへ。作業PCは手元に

次に考えたいのが、オフィス内のサーバールームに相当する役割をCloud VPCへ移す構成です。

移す候補は、社内Webアプリ、DB、開発サーバー、共有ストレージなど。作業PCまでクラウドへ移す必要はありません。VPCはクラウド上の論理的に分離されたネットワークで、AzureではVNetなどの名称が使われます。

図4：作業PCはローカルに残し、VPNを介してCloud VPC内の業務アプリとDBへ接続する。移すのはサーバー側の役割。VPC内への経路、ゲートウェイ、Firewallなどは別途設計します。

エディターやOfficeアプリは手元で動かす。ブラウザでVPC内の業務アプリを使う。必要な管理通信だけをVPNへ通す。こうすれば、仕事の操作感を保ちながら、サーバーをオフィスの電源や回線から切り離せます。

ただし、ローカルアプリから遠隔DBへ細かな通信を繰り返す構成は、遅延の影響を受けます。大きなファイルの読み書きも回線に左右されます。必要ならアプリとDBを近くに置き、PCからはWebアプリやAPIを利用するなど、アプリの構成も見直します。

VPCへ移しただけで自動的にPrivateになるわけではありません。Public IPの有無、公開設定、Security Group、ルート、DNS、重複しないアドレス設計、戻り経路を確認します。VM化にも、バックアップの整合性、ライセンス、復元確認が必要です。

OfficeとVPCは、しばらく併用してよい

複合機、実験機器、大容量のNASなど、オフィスに残した方がよいものもあります。すべてを一度に移す必要はありません。

図5：Cloud Hubを介して、必要なOffice資源とVPC資源へアクセスする併用構成。単一のLANへ延伸する意味ではなく、必要な経路と権限を用意します。

まず業務アプリをVPCへ移し、NASはOfficeに残す。次に共有ファイルの置き場所を見直す。既存のVPNを一部残す。こうした段階的な移行なら、使い勝手と費用を確かめながら進められます。

VPNゲートウェイの導入だけで、LAN内のすべての機器から他拠点へ通信できるとは限りません。製品や導入方式ごとに、通信方向、ルーティング、対応範囲を確認します。VPNはアプリの権限管理の代わりにもなりません。

オフィスが止まっても、仕事の全部を止めないために

停電や災害でオフィスが使えない日を想像してください。ノートPCを持ち出せても、VPNの接続先と業務サーバーがその建物にあれば、仕事は再開できません。

図6：オフィスは停止しているが、別拠点のPCから稼働中のCloud HubとVPCへ接続する。継続できるのは、停止したオフィスに依存しない業務です。クラウド側の稼働と代替回線が前提になります。

業務システムがVPCにあり、オフィスを経由しないVPN接続が使えれば、別の場所と回線から再開できる範囲が広がります。ただし、OfficeのNAS、社内DNS、認証サーバーなどへの依存が残っていれば、その部分は止まります。

Cloud Hub、クラウド基盤、認証基盤も障害の起きる構成要素です。クラウド継続を当然とせず、バックアップ、復元テスト、必要に応じた冗長化、許容できる停止時間とデータ損失を考えます。

Internetへの出口も確認しましょう。すべての通信をOffice経由にしていれば、その出口の停止に影響されます。Private通信とInternet通信の経路を分ける方式や、別の出口を準備する方式を、組織の方針と製品の対応範囲に合わせて選びます。

IP Allowlistを使うサービスでは、予備の出口IPを事前に登録し、認証やMFAと組み合わせます。IP Allowlistは認証そのものではありません。動的IPを使う場合は変更時の対応も必要です。

HomeGrid VPNを、この構成のどこに使うか

ここまでの構成は、HomeGrid VPNを使わなくても検討できます。既存のVPN、自作WireGuard、クラウドのVPNサービスなどで要件を満たせるなら、その方法も選択肢です。

HomeGrid VPNは、その中で端末・拠点をCloud Hub経由で接続する経路と、Internet Exitを担当する選択肢です。サーバーのVM化やバックアップ、アプリの移行を提供するものではありません。

端末側と拠点側がCloud Hubへ接続を開始するHub & Spoke型で、拠点側では原則としてIPv4 Port Forward、IPv6の着信許可、DDNSを前提にしません。接続先のCloud HubへOutbound UDPが通ることは必要です。

図3や図5の考え方で使う場合も、VPC内の導入方式、対応する通信方向、経路とFirewallを個別に確認します。Docker版Gridなどには配下LANからVPN側への通信を許可できない条件があり、拠点間の任意の双方向通信を保証するものではありません。

LANアクセス制御（LAN ACL）では、端末ごとにアクセスできる宛先LANを選びます。既定では拒否され、チェックを入れた端末だけがそのLANに行けます。ゲートウェイに許可する場合は配下LAN全体が対象で、配下のホストを1台ずつ選ぶ制御ではありません。ホストやポート単位の制限が必要なら、別途Firewallやアプリ側の設定で補います。

Cloud HubとInternet Exitを分けて考える

Cloud Hub ≠ Internet Exitです。図のCloud HubはVPNの中継点で、そこから必ずInternetへ出るわけではありません。

Home側のGridを出口にするIPv4通信なら、端末からCloud Hub、HomeのGrid、家庭用ISPを経てInternetへ進みます。接続先に見えるのはHome側回線のPublic IPです。Cloud Hubも経路上にあるため、その運用と可用性は信頼・依存関係に含まれます。

家庭用回線とデータセンターでは出口ネットワークの性質が異なりますが、業務用途では、固定IP、規約、速度、可用性などが選定条件になります。家庭用IPが常に適切とは限りません。実家など他人が契約する回線では、契約者の同意とISP契約条件の確認が前提です。

HomeGrid VPNで出口を変更する場合、複数のGridを用意し、ダッシュボードから手動で切り替えます。出口は1台で、変更はすべての端末に影響します。自動フェイルオーバーではなく、一時的な通信断と端末の再接続も見込みます。全トンネル接続で出口が停止するとInternetも利用できなくなるため、操作担当者がダッシュボードへアクセスする代替回線を用意しておきます。

最初の一歩は「今日はオフィスに入れない」と仮定すること

まずは数人のチームで、普段のノートPCと別回線だけを使い、業務を試してみてください。

ファイルと業務アプリを開けるか。
必要な認証とMFAを完了できるか。
UDPが制限される利用場所でも、予定した接続方法が使えるか。
オフィスのNAS、DNS、認証基盤、Internet Exitに依存していないか。
出口変更後のIP Allowlistと、復元手順を確認できるか。

止まった箇所が、次に見直す場所です。作業PCは手元に残し、サーバーと接続経路を必要なところから分離する。その小さな変更から、働く場所の自由度と、仕事を続けられる範囲を広げていけます。

仕組みを詳しく知りたい場合はHomeGrid VPNの通信経路へ。予備の出口を検討する段階ではInternet Exitの切り替え手順を確認してください。