2018年10月9日火曜日

AWS内部でVPNを構築するとの注意ポイント | ライタス株式会社

AWSの構築依頼が増えてきており、ネットワーク構築、セキュリティのコンサルティングのご依頼が特に増えております。

昨今パブリッククラウドが普及したためか、これまでオンプレミス環境で構築されていたお客様も、一部、ないしは全部の環境をクラウドに移行することを検討されるなど、さらなる普及が進むと思われます。

しかしながら、適切なセキュリティを講じていないために、法外な請求を受けたり、情報漏洩を起こしたりと、インシデントが発生することも多々あるので、構築時からセキュアな環境を構築するように心がけていきたいところです。

セキュアな環境を構築するときに、よく登場するVPNですが、今回はこれを構築するときにはまりましたので、その記録を書きたいと思います。

構成としては、AWS VPC上に、自前VPNサーバー + NAT トラバーサルです。
今回はユーザーメンテナンスを考慮し、SoftEther VPNで構築しました。

構築については、他のサイトでもよく記載されているので、そちらをご参照いただければと思います。

AWSにSoftEther VPNServerで簡単にVPN接続しよう | DevelopersIO
https://dev.classmethod.jp/cloud/aws/rk-2018-02-12-softethervpn/
AWS(EC2)でSoftEtherを使ってL2TP/IPsecなVPNを構築する (Mac) - Qiita
https://qiita.com/showwin/items/92861057a8b62611444d

SoftEther VPNは、設定がGUIでできるので、ユーザーに環境を引き渡すときも安心なのがうれしいですね。
ところが、VPNで接続して、いざ内部のサーバーにPingをしてみたところ、うまく疎通できません。(クライアントはWindows 10)

不思議なことに、tracertをすると、何回かタイムアウトしたのちに通信ができるようになります。
一度通信できるようになったら特に問題なく疎通できるのですが、VPNを再接続すると現象が再現します。
最初はMTUが適切な値ではないとか、ルーティングの設定がおかしいのかといろいろ試してみたのですが、どれもうまくいかない上に、クライアントがMacやAndroidなどの端末では、疎通できてしまいます。
いろいろと調べているところ、「送信元/送信先の変更チェック」がTrueになっているとおかしい状態になることを発見しました。


この設定は、EC2インスタンスへの通信が、本当にそのインスタンスから発せられたものであれば通信を許可し、そうでない場合は通信を拒否する機能で、デフォルトでTrueになっています。
tracertをした後、通信がうまくいくのは、この機能によりVPNサーバーの内部ネットワークであるEC2インスタンスから発せられたパケットであると、AWS基盤側に認識されたためと考えられます。
この設定をFalseにした後、しばらくの後に、問題なく通信ができるようになりました。

ルーティングもファイアウォールも問題なく設定されていても通信できないという状況になったら、基盤側の設定も疑ってみるとよいかもしれません。

0 件のコメント:

コメントを投稿