はじめに
MGNを利用してオンプレミスにある仮想マシンを、プライベート接続されたVPCに移行するという案件がありました。
MGNには移行元環境と移行先VPCとの間にネットワーク要件があり、その要件を満たす必要があります。
しかし、社内ネットワークでポートに関する制限があり、AWS公式の構成では移行できないことが判明しました。
そこでプロキシを介することでポート制約を回避し、移行を実現することができました。
本記事では、MGNの検証で直面したポート制限の課題と解決法をご紹介します。
課題
社内のネットワーク制約で、オンプレミスからAWSへの通信で、TCP443は社内のプロキシを経由し、かつVPC内リソースのIPアドレスに対応するFQDNをAレコードとして社内のDNSサーバに登録しておき、そのDNSサーバで名前解決する必要がありました。
MGNでは、以下の通信を確保することが要件になっています。
1. 移行元サーバ ⇒ MGNサービスエンドポイント（TCP443）
2. 移行元サーバ ⇒ レプリケーションサーバ（TCP1500）
MGNエージェントはオンプレミスからAWSに通信するとき、「mgn.ap-northeast-1.amazonaws.com」（東京リージョンの場合）というドメイン名でアクセスしようとしますが、社内DNSサーバで名前解決ができないため、アクセスに失敗します。
解決法
詳細は控えますが、社内ルールでは、TCP22，80，443以外のポートへの通信は、IPアドレス直接指定でアクセスできることになっていました。
そこで、移行先VPC内にSquidのプロキシサーバを立て、そのプロキシサーバを経由して、MGNサービスにアクセスする構成としました。
そのうえで、MGNエージェントを実行するコマンドで次のオプションを指定しました。Squidはポート3128で待ち受けているので、3128を指定しています。
--proxy <プロキシサーバのプライベートIPアドレス>:3128
MGNのTCP443通信では必ずしも移行元サーバとMGNサービスエンドポイントとで直接通信する必要はなく、プロキシ経由での通信が可能です。
プロキシ経由にすることで、社内制約のポート制限を回避できるだけでなく、VPC内で名前解決すればよいので、社内の独自ドメイン名を使用する必要がなくなります。
ただし、1つ制約があります。
MGNエージェントを実行するとき、実行処理のなかでJavaを利用するのですが、OSにJavaがインストールされていないと、MGNエージェントが内部でJavaの実行環境をバンドルします。
バンドルされたJavaの実行環境の場合、MGNエージェント実行コマンドのオプションでのプロキシサーバの設定がJavaに反映されません。
そのため、プロキシ経由でMGNサービスエンドポイントにアクセスする構成の場合は、あらかじめ移行元サーバにJavaをインストールしておく必要があります。
おわりに
移行案件で移行元の社内ネットワークの制約でポート制限がある場合は、このようにプロキシを介することでいったん異なるポートに接続して移行先VPC内に入り、そのプロキシからMGNなどのAWSサービスエンドポイントにアクセスできることがあります。
MGNによる移行を実施するときは、ぜひ参考にしてください。