【Sophos】AWSに構築したVPNサーバ経由で社内PCにリモートアクセスするにはIPマスカレードを有効にする

植木 和樹

2017.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹＠上越妙高オフィスです。クラスメソッドではリモートワークが盛んで、多くの人が自宅やコワーキングスペースで仕事をしています。 特に台風の日は交通機関の乱れが予想されるため自宅勤務に切り替え、作業を行なう方が多いようです。

ただリモートワーク中でも、どうしても社内のデスクトップPC等にアクセスしなくてはならないケースがあります。 そのため会社ではVPNサーバーを用意し、リモートから接続することで作業ができるようにしてあります。

背景

これまでVPNサーバーは本社サーバー室に設置していました。しかし諸々の事情によりリプレースを行なうことにしました。

  • VPNサーバーの保守切れ
  • 社員数が多くなりリモート接続ユーザーも増えた（ライセンス、パフォーマンスが足りない）
  • 物理サーバーだとメンテナンスが現地にいるメンバーしかできない（年一回のビル停電など）

そこでリプレースと合わせてAWS上にVPNサーバーを構築することにしました。VPNサーバーにはいろいろな案件で実績のあるSophos UTMを利用しました。

20170613_sophos_101

リモートからはSSL-VPNクライアントを起動しAWS上のVPNサーバーに接続します。その後社内PCにリモートデスクトップなどで接続すると、AWSと各拠点を繋げているVPN経由でアクセスできるという仕組みです。

環境構築

Sophos VPNサーバーの構築とVPNクライアントの設定については、過去のブログを参照してください。

【AWS】統合脅威管理「Sophos UTM」を使ってiPhoneからVPCへIPsec-VPN接続する

接続上の問題と解決方法

上記ブログの設定だけだと社内PCにはアクセスできません。SSL-VPNクライアントから社内PCには届くのですが、社内PCからSSL−VPNクライアントへ折り返しの返事ができないためです。

20170613_sophos_102

この問題はSophosの管理画面でIPマスカレード(IP Masquerade)を有効にすれば解決し、通信できるようになります。

20170613_sophos_001

IPマスカレードを有効にすることで、SSL-VPNクライアントからSophos VPNサーバーを経由して出ていく時のIPアドレスが、Sophos VPNサーバーのプライベートIPアドレスに変換されるためです。

20170613_sophos_103

通信できない理由

SSL-VPNクライアントと社内PCが通信できない理由は、先述したとおり「SSL−VPNクライアントがどこにいるか分からない」ためです。 VPN接続時にSophosからクライアントに払い出される仮想IP（10.242.0.0/24)宛の通信を適切に届けてあげる必要があります。

必要設定1: Sophos仮想IPアドレス(10.242.0.0/24)宛の通信をどうにかSophosに届ける

社内ネットワークでSophos仮想IPアドレス(10.242.0.0/24)をVPN越しにAWSへルーティングすれば良い気もしますが、それではうまく行きません。 AWSのVirtual Private Gateway(VPG)は 10.242.0.0/24 というネットワークを知らないためです。VPGが知っていて扱えるのはあくまでもVPCのネットワークアドレス(10.0.0.0/16)のみになります。

20170613_sophos_102

Sophos VPNサーバーの構築手順の中で、サブネットのルートテーブルとして 10.242.0.0/24 → SophosインスタンスのENI という設定は行いましたが、Virtual Private Gatewayではサブネットのルートテーブルは参照しません。

そのためSSL-VPNクライアントをSophosサーバーのIPアドレスとして通信をさせる必要があります。VGWが分かるネットワークのIPアドレスに変換するわけです。IPマスカレードを使うとSophos仮想IPアドレス 10.242.0.0/24 をSophosのIPアドレス（10.0.0.100/32） に「擬態」させることができます。

必要設定2: 社内ネットワークで 10.0.0.0/16 をAWS(VPN)にルーティングする

（この設定はSophosと関係ありません。AWSとVPN接続する際にすでに設定されているはずです。）

社内PCは自分と異なるネットワークとは直接通信できないため、デフォルトゲートウェイに中継を依頼します。デフォルトゲートウェイは通常その中継をインターネットに送ろうとしますが、宛先はSophosサーバー(10.0.0.100/32)というプライベートIPアドレスのため当然届きません。

今回はデフォルトゲートウェイとAWSのカスタマーゲートウェイを同じルーターで行っています。そのため 10.0.0.0/16 宛の通信をVPN越しにAWSへルーティングする設定が必要になります。

まとめ

通信経路にAWSとのVPNが挟まるためリモートデスクトップ接続等でのレスポンスに影響でるかな？と懸念したのですが、試してもらったところ気にならないとのことで安心しました。

VPNサーバーをAWSに設置したことで、また一つ社内から物理サーバーを減らすことができました。 仮想サーバーにしたことで下記のようなメリットが受けられそうです。

  • ビルの法定点検等による停電等で土日に出勤して電源オンオフしなくて良くなる
  • ハードウェア故障を気にしなくて良いので予備機が不要になる
  • セキュリティグループやNACL等でアクセス制御を行いやすい
  • 接続ユーザー数（パフォーマンス）に応じてスペックを変えられる

ハードウェアから開放されるのがなによりありがたいです。

というわけで、クラスメソッドのリモートワークを支える技術からの報告でした。

AWS