こんにちは、IT基盤部第三グループのジュンヤと申します。DeNAに入社してちょうどこの9月で丸9年になります。 入社当初はネットワークエンジニアとして着任しましたが、それから、金融系・EC系システムのインフラに携わり、現在は社内システムのインフラエンジニアのマネージャをしています。ちなみに、FirstNameを名乗っている理由は、同じ部署に同じ名字のメンバーがいるためであり、様々な事故防止が理由であって、それ以上でも以下でもありません。

社内システムのインフラエンジニアとは？

当たり前ですが、インフラエンジニアと一口に言っても、担当しているシステムによって必要なスキルセットは異なります。その中でも、社内システムのインフラエンジニアというポジションは、雑多な幅広いテクノロジーに触れることができます。 管理しているサーバOSという面ではLinuxはもちろん、WindowsServerOS（いまだに2008とか・・・もうすぐ撤廃予定）もあり、仮想化基盤ではKVM、VMwareなどがありますし、ミドルウェアに目を向ければ、ActiveDirectory、MySQLやOracleといったRDBMS、Github:Eや様々なSaaSなどの運用も行っています。 このように、社内システムは多種多様なテクノロジーが混在し、日々、バックオフィスを支える縁の下の力持ちとして運用業務を行っていますが、もちろんそれだけではなく、スタッフから寄せられる要望や問題解決にあたることもあります。今回はその中の一つの例を紹介したいと思います。

「VPN接続ができないんだけど・・・」　〜中国からの便り〜

第一報

もう6月なのに肌寒い日もあり、今年は夏が来ないのでは？などと思っていたある日、あるスタッフからSlackで問い合わせがありました。
見ると、週末から突如VPN接続ができなくなった、とのこと。VPNサービスは自宅などからリモートワークをするために必要ですし、それこそインフラエンジニアがメンテナンス目的で多数のサーバへのアクセスをするためだったり、SourceIPでアクセス制限をしているクラウド上のシステムを利用するためだったりと、言うまでもなく社内システムの中でも超重要なサービスの一つです。
嫌な汗が流れそうになるのを感じながらも、どのようなエラーがでているか聞くと、Slackに以下のメッセージが貼られます。

L2TP-VPNのサーバが応答しませんでした。接続し直してください。
それでも問題が解決しない場合は、設定を確認し、管理者に問い合わせてください。

できれば遭遇したくないエラーメッセージの一つです。
「応答しませんでした」と症状を訴えているところを見ると、クライアントは接続しにいったけど、サーバが応答しない、もしくはサーバまで到達できなかったという問題になります。
ここで、サーバに問題があるとなると、オオゴトになります。VPNサービスは前述したとおり、平常時から利用されているサービスですので、障害が発生するとそれなりの騒ぎになりますが、ざわついているSlackチャンネルも見当たらないし、問い合わせも特になし。ましてや監視アラートも発報されていません。念の為にVPNサーバ側での認証ログをみても形跡がない。となると、クライアント側の環境か途中のネットワーク経路に疑いが持たれます。

原因特定。コレはアレでどうしようもないのでは・・・

ここで、問い合わせしてきたスタッフが中国に出張中ということにあらためて気づきます。そして、現地にいる別のスタッフにも同様にVPN接続ができるか念の為に確認を依頼してみると、結果は案の定、接続不可で同じエラーメッセージが表示されるとのこと。ここまできて、コレはアレで打つ手がないのでは・・と原因に目星をつけることになります。

「中国特有の現象」に遭遇

このblogを読まれている方には説明不要かもしれません。ピンとこない方は事象を検索してみて下さい。
今回の不具合は、十中八九、とある事情で接続できない事象（ここでは便宜上、「中国特有の現象」と呼ぶことにします）が原因だと判断した私は、突如戦意を失い、その旨を伝えます。

ジュンヤ「もうダメかもしれない・・・」
スタッフ「業務に支障があります」
ジュンヤ「わかりました・・なんとかしますので時間を下さい」

負けられない戦いがここにある。
サービスを直接支えるエンジニアではないけれども、サービスを作っているエンジニアをさらにその下で支えるエンジニアである、との誇りとともに、「中国特有の現象」に立ち向かうことを決意します。

Alibaba Cloud CENとの出会い

DeNAではオンプレからクラウドへの移行（Cloud Journey)が現在進行中です。現時点では主なクラウド基盤はAWSとGCPで、Alibabaは名前は聞いたことがあるけど(なんか強そう・・・)、というレベルでした。
そんな状況の中、今回のミッションである「中国から日本のシステムにVPNを張る」ために、Alibaba Cloudを利用するという構成が選択肢としてあがりました。
構成案は以下の通りです。

ポイントは「CEN(Cloud Enterprise Network)」というサービスです。これはリージョンの異なるVPC間を簡単にプライベートネットワークでつなぐことができる、というものです。 https://jp.alibabacloud.com/product/cen

「中国特有の現象」の影響を受けないためには、日中間で専用線を敷設することが必須というのがこれまでの常識でした。しかし、そのためには物理的な拠点が必要ですし、コストもリードタイムもバカになりません。 専用線の代わりにCENを利用し、VPNServerをクラウド上に配置することで、安価で柔軟性があるVPN接続ができそう、と期待が持てます。

実際に使ってみる

WEBにはCEN活用例がすでに紹介されていて、Step by Stepでの解説もされています。ありがたいです。
とはいっても、Alibabaを使うのは初めてのため、どれくらい手間がかかるのかわかりません。早速アカウントを作成し、実際に使いながら設定をしてみます。
無料枠（30,000円分）もついていますので、検証目的で気軽に始めることができるのも良い点です。 ログインしてみた第一印象は、「とっつきやすそう」。ユーザーフレンドリーな感じが好印象です。

具体的な設定手順はここでは割愛します。前述したとおり、既に参考になるサイトがありますし、直感的に操作できます。
CENの注意点としては、実際に設定した後、リージョン間をPINGで疎通確認をするレベルであれば、CENコスト0で可能ですが、実際にSSHログインしたり、curl等でアクセス確認することはできません。
これは、デフォルトでは帯域が1kbpsしかないことが理由で、実用的に使うには帯域パッケージを購入して適用する必要があります。(2Mbpsで約30,000円/月)
また、Alibabaコンソールにログインした画面からは何故かCENコンソールへの導線がありません。CEN関連の作業は別途画面を開く必要があります。（https://cen.console.aliyun.com/）

経路を無事確保。セキュアなVPN通信とは？

触り始めて数十分で日中間でのAlibaba VPCで疎通確認をすることができました。想像以上に簡単です。
しかし、ミッション完遂までは、やるべきことはいくつかあります。ざっと以下のようなタスクがあります。

1. VPNを利用するアカウント数と通信要件のヒアリング

• IPアドレス設計（各VPC、クライアントVPN）
• JP-RegionとDeNAデータセンタの接続
• CN-RegionでVPNServerを構築
• 接続テスト
• (様子を見て)CEN帯域幅の決定、帯域パッケージの適用

タスクリストだけ見るとすぐにコンプリートできそうですが、セキュリティには十分注意を払う必要があります。 VPNサービスという社内システムを安全に使うためのシステムにセキュリティホールがあっては意味がありません。 特に考慮したポイントは以下になります。

• VPN接続時のMFA(Multi-Factor Authentication)化
• VPNサービスのアカウントの自動棚卸し
• エンドツーエンドでのセキュアな通信をするための仕組みづくり
• 必要なIP/Portのみ開放する(SecurityGroup)

VPNを利用するアカウント数と通信要件のヒアリング

まずは中国からのVPN利用人数とどのような通信が必要なのかをヒアリングします。
今回は結果として、プロトコルはHTTPS/HTTPのみ、アクセス先は社内システムとそれ以外という分類になりました。 通信要件としてはシンプルなものと言えます。

IPアドレス設計、JP-RegionとDeNAデータセンタの接続

タスクの2と3については、私のグループの管理下ではないため、部内にある専門部隊のNetworkグループに相談をします。優秀なネットワークエンジニアが多数在籍しているため安心して相談することができます。実際に、この作業も非常に短期間で完了しました。Alibaba側で必要な作業としては、VPN-Gatewayというサービスを利用することになります。実際の構築方法については、これも参考になるサイトがありますのでそちらに譲ります。

CN-RegionでVPNServerを立てる

この時点で、Alibaba CN-RegionとDeNAデータセンタの疎通確認が取れる状態になりました。ただし、セキュリティの観点からDCのInbound向きACLはほぼ閉じた状態です。
まずは入り口をしっかり守るという点で、VPN接続にはID/Passwordの他にMFA(Multi-Factor Authentication)を必須としました。ID/Passwordだけでは万が一、漏洩した場合に第三者がそのクレデンシャルを使った「なりすまし」リスクが想定されます。 MFAに対応したVPNソリューションはいくつかあると思いますが、ここではOpenVPN AS(Access Server)を選定しました。デフォルトでGoogleAuthenticatorに対応しています。

また、接続アカウント(ID)についてもVPNServerのローカルで情報を持ってしまうと棚卸しが大変です。退職等によって権限を剥奪する作業を別途行う必要があるからです。 この点、OpenVPN ASはLDAPに対応しています。DeNAはActiveDirectoryによってスタッフのアカウントの一元管理を行っており、LDAPも話せます。ADとLDAP連携することで、退職者についてはAD上で無効化されたと同時にOpenVPNにもログインできなくなり、別途棚卸しする必要がなくなりますので、この点も◎です。

パブリッククラウドだからこそセキュアな通信を

無事にクライアントPCからVPN接続ができたら一安心、としたいところですが、パブリッククラウドならではの注意するべきポイントがあります。オンプレミス環境とは違い、インフラをすべて自分たちで管理できているわけではないため、「盗聴リスク」も念頭におく必要があります。今回は以下の図のような構成にすることにしました。

目指したことはクライアントPCからDeNA Data Centerまでの通信はすべてSSL化すること、です。

• クライアントPC <-> OpenVPN Server間はSSL-VPN
• OpenVPN ServerからLDAP Serverへの認証はLDAPS
• クライアントPCからpacファイルへの通信はHTTPS
• クライアントPCからプロキシサーバへの通信もHTTPS

このような構成にすることで、パブリッククラウド内では平文が流れることがほぼなくなり、盗聴リスクが大幅に軽減されます。
クライアントPCのブラウザにはプロキシを設定します。プロキシを間に挟むことで、アクセスログの取得もできますし、FWの開放Portを最小限に抑えることができます。また、直接、プロキシサーバを指定せずに、自動プロキシ構成(.pac)ファイルを設置したWEBサーバを準備し、そのアドレスを指すようにします。こうすることで、pacファイルによってトラフィックを複数のプロキシサーバに振り分けることができるようになります。DeNAでは、社外サイトへの通信はProxy-A、社内サイトへの通信はProxy-Bへ、といったようにセキュリティレベルにあわせたProxyを利用するようにしています。

仕上げ -各種ACLの見直しを忘れずに-

細かいところに気を配り、セキュリティ向上に努めたとしても、セキュリティグループやネットワークACLがガラ空きなことほど惨めなことはありません。全体構成を絵にして見直し、必要最低限のPortのみ開放するようにします。

最後に

現在、接続テストを実施していますが、大きな問題は発生していません。これから接続する人数を増やしてCENの帯域を増やす必要があるかどうかも判断していく必要がありますが、ワンクリックで即時に帯域を増やせるため、そこまで神経質に見極める必要はなさそうです。 パブリッククラウドという特性上、セキュリティ面には注意を払う必要がありますが、CENを使うことで、非常に簡単にコストを抑えたグローバルなプライベートネットワークを構築することができました。

「中国特有の現象」に、諦めたことがある、もしくは今まさに遭遇している、そんな方にCENを使ってみることをおすすめします。