MS_FTPServerOnCloud - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

クラウド環境にFTPサーバを構築する場合

  • 戻る（FTP）
    • クラウド環境にFTPサーバを構築する場合

概要

クラウド環境に FTP サーバを構築する場合、

  • 先ず、NAPTがあると思うので、
    （アクティブに対応の NAPT もあるらしいですが）
    パッシブを "適切" に設定するのが良いようです。
  • 以下のサーバー側の設定を "適切" に加えます。
    • データ通信のサーバー側の IP アドレスをグローバル IP にする。
    • データ通信のサーバー側のポート番号の範囲を限定する。

補足（FTP がクラウドで詰まる理由）: FTP は
制御用とデータ用で 2 本の接続を張るという、
現代のネットワークとは相性の悪い設計になっている。

【アクティブ モード】
  クライアント →[21番:制御]→ サーバ
  クライアント ←[20番:データ]← サーバ   ← サーバ側から接続を張る（！）
                                            ↑ クライアント側の FW / NAPT で弾かれる

【パッシブ モード】
  クライアント →[21番:制御]→ サーバ
                「データ用のポートは 50000 番です」と応答
  クライアント →[50000番:データ]→ サーバ ← クライアント側から張る
                                            ↑ サーバ側の FW / NAPT を通す必要がある

つまり、**どちらのモードでも「どちらか側の NAT / FW を
通り抜けなければならない」**という構造的な問題を抱えている。

クラウドでは必ず NAPT（またはロード バランサ）が
前段に入るため、

選択 結果
アクティブ クライアント側の環境に依存する。企業 NW では大抵通らない
パッシブ サーバ側で対処できる（本文の推奨）

となり、パッシブ一択になる。
本文が挙げる 2 つの設定は、まさにその「サーバ側での対処」である。

補足（2 つの設定がなぜ必要か）: 本文の 2 項目には
それぞれ明確な理由がある。

① データ通信のサーバー側の IP アドレスをグローバル IP にする

【設定しない場合】
  クライアント：「パッシブでお願いします」
  サーバ      ：「10.0.0.4 の 50000 番に繋いでください」
                 ↑ 自分のプライベート IP を答えてしまう
  クライアント：（そんな IP には繋がらない）→ 転送が始まらない

サーバは自分がグローバル IP を持っていることを知らない
（NAPT の内側にいるため）。
したがって、「応答に載せる IP」を手動で設定する必要がある。
IIS では［FTP ファイアウォールのサポート］の
**［ファイアウォールの外部 IP アドレス］**がこれにあたる。

② データ通信のポート番号の範囲を限定する

【設定しない場合】
  サーバは 1024〜65535 の任意のポートを使う
     ↓
  NAPT / NSG で【全ポートを開ける】しかなくなる  ← 論外

【範囲を限定した場合】
  例：50000〜50100 に限定
     ↓
  その 101 ポートだけを開ければよい

つまり、開けるポートを最小限にするための設定である。
同時接続数の見積りに応じて範囲を決める
（1 転送につき 1 ポートを消費する）。

Azure であれば、この範囲を
Network Security Group (NSG)で許可し、
ロード バランサを使う場合は
AzureのGW / LB的なモノ。側にも
同じ範囲の規則が要る。

補足（FTPS だとさらに難しくなる）: 参考リンクの 1 つ目・2 つ目が
「FTPS でファイル転送する場合の罠」であるとおり、
暗号化すると問題が増える。

【FTP】  NAPT 機器が制御接続を覗き、
         「50000 番を使う」という応答を読んで、
         自動的にポートを開けてくれる（ALG: Application Level Gateway）

【FTPS】 制御接続が暗号化されている
         → NAPT 機器が中身を読めない
         → ALG が機能しない
         → 【手動で全部設定するしかない】

つまり、暗号化した途端に「機器が気を利かせてくれる」仕組みが
効かなくなる。これが「罠」の正体である。

したがって、FTPS では

必須事項 内容
パッシブ ポート範囲の明示 前述
外部 IP アドレスの明示 前述
その範囲を FW / NSG で開放 ALG に頼れない
データ接続の TLS セッション再利用 サーバ設定によっては必須

をすべて手動で行う必要がある。

補足（そもそも FTP を選ぶべきか）: 現在の実務では、
FTP / FTPS は積極的に選ぶ理由が乏しい。

手段 評価
FTP（平文） 論外（認証情報が平文で流れる）
FTPS 上記の複雑さ。NAT との相性が悪い
SFTP（SSH ベース） 22 番 1 本で済む。NAT の問題が無い（OpenSSH）
HTTPS（Blob Storage、S3 等） 443 番 1 本。認証・監査・冗長化が容易
Azure Files（SMB） 社内ファイル共有として

**「1 本の接続で済む」**という一点だけでも、
SFTP / HTTPS の方が構成が単純になる。

Azure では Blob Storage が SFTP に対応しており、
サーバを立てずに SFTP のエンドポイントを提供できる
（Azureのストレージ）。
取引先の都合で FTP プロトコルが必須、といった
外部要因が無い限り、これらを選ぶのが妥当である。

参考

Tags: 移行, インフラストラクチャ, 通信技術, クラウド, IIS

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️