NLB 経由で手元の Windows 11 からプライベートサブネットの EC2（RHEL9）に WinSCP でファイル送受信してみた

コーヒーが好きな emi です。

今回は NLB 経由で、手元の Windows 11 からプライベートサブネットの EC2（RHEL9）に WinSCP でファイル送受信してみました。

ファイル送受信や SSH 接続で NLB を経由させる場合は注意点があります。
手順を先に見たい方は 検証：WinSCP でのファイル送受信 からご覧ください。

プライベートサブネットの EC2（RHEL9）にオンプレミスサーバーや手元の開発端末からファイルを共有したい

プライベートサブネットの EC2（RHEL9）にオンプレミスサーバーや手元の開発端末からファイルを共有したいケースがあります。
よく考えられるのは「踏み台サーバー経由でファイル共有する」「Transfer family で S3 バケットにデータを配置し、S3 バケット経由でファイル共有する」などのパターンです。

プライベートサブネットの EC2 にオンプレミスサーバーや手元の開発端末からファイルを共有したい場合は他にも以下のように様々な方法が考えられます。

しかし、今回は「EC2 インスタンスを AWS Auto Scaling でスケーリングせず、1 台のみ」、「データを EC2 内部に保持している」、「ファイル共有したい周辺サーバーや開発端末が多く、SSM ポートフォワードや EC2 Instance Connect エンドポイントだと周辺サーバーや開発端末の設定が大変」等の前提があったため、NLB 経由での SCP ファイル送受信を試してみました。

Systems Manager セッションマネージャーを使いたい場合は以下のブログをご参照ください。

NLB のおさらい

Network Load Balancer（NLB）は、OSI 参照モデルの第 4 層で機能します。 毎秒数百万のリクエストを処理でき、以下のようなケースで利用できます。

• 高スループット・低レイテンシーの通信が必要な場合
• Elastic IP アドレスが必要な場合（IP を固定したい場合）
• WebSocket や IoT デバイスなど、長時間の TCP 接続を維持する必要がある場合

注意点

SSH や SFTP は通常長期間の接続を必要とし、その接続は特定のクライアントとサーバーの間で維持されます。ロードバランサーを介すると接続は複数のサーバー間で分散され、それにより接続が不安定になる可能性があります。

本記事の検証のように SSH や SFTP の接続をロードバランサーを介して行うことも可能ですが、以下の点に注意してください。

• スティッキーセッションは未サポート
  • NLB はスティッキーセッション（同一クライアントからの複数のリクエストを同じターゲットにルーティングする機能）をサポートしていません。NLB のターゲットグループに複数のインスタンスが含まれる場合、同一クライアントから複数の SSH 接続リクエストが異なるターゲットにルーティングされる可能性があります。
  • 本記事の構成のように、NLB のターゲットグループに含まれる EC2 インスタンスが 1 台のみの場合、全てのリクエストは同一のインスタンスにルーティングされるため、接続の整合性は保たれます。
• 接続タイムアウト
  • NLB は 350 秒以上無活動の接続を自動的に切断します。SSH や SFTP の接続が長期間開放される場合、接続の切断を引き起こす可能性があります。
  • SSH や SFTP の通信が短時間で完了し、ターゲットのインスタンスが 1 台のみである場合、この設定による影響は抑えられます。
  • 参考：接続のアイドルタイムアウト

検証：WinSCP でのファイル送受信

今回の検証構成図

以下のような構成で検証します。NLB のターゲットグループには EC2（RHEL9）が 1 台だけ含まれるようにします。

事前に VPC と EC2（RHEL9）を作成しておいてください。手元の Windows 11 端末には WinSCP をインストールしておいてください。

NLB のターゲットグループの作成

NLB を作成する前に、ターゲットグループを作成しておきます。

EC2 コンソール画面より、[ターゲットグループ] - [ターゲットグループの作成] をクリックします。

• ターゲットタイプの選択：インスタンス
• ターゲットグループ名：任意の名前（今回は「nlb-sftp-test-tg」としました）
• プロトコルポート：TCP、22
• IP アドレスタイプ：IPv4
• VPC：EC2 インスタンスが作成済みの VPC を選択

• ヘルスチェックプロトコル：TCP

その他はデフォルト値で「次へ」をクリックします。

「ターゲットを登録」画面で、作成済みの EC2（RHEL9）にチェックを入れ、「保留中として以下を含める」をクリックします。すると、下部の「ターゲットを確認」欄に選択した EC2 が表示されます。
「ターゲットグループの作成」をクリックします。

ターゲットグループができました。

NLB の作成

NLB と、NLB に割り当てるセキュリテイグループを作成します。

EC2 コンソール画面より、[ロードバランサー] - [ロードバランサーの作成] をクリックします。
Network Load Balancer の項目で「作成」をクリックします。

• ロードバランサー名：任意の名前を入力（今回は「nlb-sftp-test」としました）
• スキーム：インターネット向け
• IP アドレスタイプ：IPv4
• ネットワークマッピング：作成済みの VPC を選択
• マッピング
  • ターゲットとなる EC2 インスタンスを作成した AZ と同じ AZ にチェックする
    • サブネット：パブリックサブネットを選択
    • IPv4 アドレス：今回は「Elastic IP アドレスの使用」を選択
      • IP アドレスを固定したいときは Elastic IP アドレスを選択します。
      • DNS 名でしかアクセスしない、もしくは IP アドレスが変更されても問題ない場合は「AWSによって割り当て済み」を選択します。

次は NLB に割り当てるセキュリティグループを設定します。
「新しいセキュリティグループを作成」のリンクをクリックすると、ブラウザの別タブでセキュリティグループの作成画面が開きます。

• セキュリティグループ名：任意のセキュリティグループ名（「test-sg-nlb」など）
• 説明：任意の説明文を入力（日本語は使えない）
• VPC：ターゲットとなる EC2 インスタンスを作成した VPC を選択
• インバウンドルール
  • タイプ：SSH
  • ソース：任意のソース IP（今回は「マイ IP」を選択し、自身の手元の Windows 11 端末がインターネットにアクセスする際のパブリック IP を指定）

インバウンドルールの説明やタグは任意で指定してください。
最後に「セキュリティグループの作成」をクリックします。

セキュリテイグループができました。

それでは、NLB を作成していたブラウザタブに戻ります。
更新ボタンを押すと今作成したセキュリテイグループがプルダウンで選択できるようになっていますので、今作成したセキュリテイグループを選択します。

• リスナー
  • プロトコル：TCP
  • ポート：22
  • デフォルトアクション：先程作成したターゲットグループを選択（今回は「nlb-sftp-test-tg」になります）

その他の項目はデフォルトのままで、「ロードバランサーの作成」をクリックします。

ロードバランサーができました。「ロードバランサーを表示」をクリックします。

作成した NLB の詳細画面が開きます。EC2 インスタンスに接続する際に使用するため、DNS 名をコピーしておいてください。

EC2 インスタンスのセキュリティグループの編集

次は EC2 インスタンスのセキュリティグループを編集し、NLB からの SSH 接続を許可するインバウンドルールを追加します。

EC2 に付与されたセキュリテイグループの詳細画面を開きます。「インバウンドルール」タブで「インバウンドルールを編集」をクリックします。
（画像では既に 1 行インバウンドルールが存在していますが、本検証には影響がない部分なので無視してください）

• タイプ：SSH
• ソース：カスタムを選択し、NLB に紐づけたセキュリテイグループを選択（「sg」と入力すると候補で出てきます）

「説明」は任意で入力し、「ルールを保存」をクリックします。

NLB からの SSH 接続を許可するインバウンドルールを追加できました。

ここまでで、NLB にはマイ IP から SSH のインバウンド通信を許可、EC2 には NLB のセキュリティグループから SSH のインバウンド通信を許可する設定になっています。

ターゲットグループのヘルスステータス確認

セキュリテイグループによる適切な通信許可設定をおこなったので、ターゲットグループのヘルスステータスは「Healthy」になりました。
ステータスが「異常」になっている場合は、

• EC2 インスタンスが起動していて sshd プロセスが起動しているか
• セキュリテイグループの設定が正しく行われているか

を確認してください。

キーペアの作成と設定

EC2 インスタンスにキーペアを設定していない場合はキーペアを設定してください。
キーペアを後から EC2 インスタンスに設定する場合は以下ブログの

• キーペアの作成
• キーペアの公開鍵の文字列を取得
• セッションマネージャーで EC2（RHEL9）に接続し、公開鍵の文字列を登録

を参照ください。

なお、RHEL 9.0 では SHA-1 が非推奨になったことにより、キーペアのタイプが「RSA」だと鍵認証に失敗することがある模様です。
本検証ではキーペアのタイプ「RSA」ででうまく行きましたが、SSH 接続をおこなう場合、キーペアのタイプは「ED25519」を選択してください。

• 参考
  • 1.1. RHEL 9.0 における主な変更点
  • [RHEL9]sshd: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] ※Red Hat アカウントで要ログイン

WinSCP での接続

WinSCP で EC2 インスタンスに接続します。
WinSCP を開き、以下のように入力します。

• 転送プロトコル：SFTP
• ホスト名：コピーしておいた NLB の DNS 名、または NLB に付与した Elastic IP アドレス
• ポート番号：22
• ユーザー名：ec2-user（キーペアを登録したユーザー）

入力できたら「設定」をクリックします。

[SSH] - [認証] の「秘密鍵」で、キーペア（.ppk 形式）を保存している手元の Windows 11 端末のパスを入力します。
入力できたら「OK」をクリックします。

「ログイン」をクリックします。

初めて接続する際は、以下のように警告が出ます。このまま「はい」で進めます。

EC2 インスタンスに NLB 経由で接続できました。

WinSCP でのファイル送受信

手元の Windows 11 端末のエクスプローラーから、WinSCP にテストファイルをドラッグ&ドロップします。

テストファイルを EC2 上にアップロードできました。

WinSCP 上で見えている EC2（RHEL9）上のファイルを、ドラッグ&ドロップで手元の Windows 11 端末にコピーすることもできます。

終わりに

今回は「EC2 インスタンスを AWS Auto Scaling でスケーリングせず、1 台のみ」、「データを EC2 内部に保持している」、「ファイル共有したい周辺サーバーや開発端末が多く、SSM ポートフォワードや EC2 Instance Connect エンドポイントだと周辺サーバーや開発端末の設定が大変」等の前提があったため NLB 経由での SCP ファイル送受信を試してみました。
どなたかのお役に立てば幸いです。

参考