NAT Traversal といえば、ヤマハルータで iPad を使った "L2TP/IPsec" を実現させたときに役だった技術 （NAT 越え）、という印象が個人的には記憶に新しいです。 今まで僕が IPsec を構築してきたときは VPN ルータに固定 IP アドレスを設定することが多く、 any な接続とは無縁だったこともあり NAT Traversal についてはノーマークでした。
けれども例として挙げられるということは、理解しておいて損はないはず。 むしろ FTP が NAT 越えできない理由を知っておいた方が IPsec の理解も早いような気がしました。 ということで今回は FTP についての理解でございます。
FTP - 接続/切断 本来なら 「
FTP ってなんぞや？ 」 というレベルから解説するのが一般的です。
けれども今回は 「FTP の接続と切断動作」 からメモしていきます。 本来なら FTP の基本概念や仕組みを理解するのが先のはずですが、これらを全て
すっ飛ばして 接続動作からメモしていこうという、このイミフなカンジ。
「基本概念 → セッション接続/切断 → 動作の詳細」 といった順番に沿わない理由ですが、今の僕は 「HTTP と FTP のダウンロードの違い」 さえも区別がつかないという右も左も分からない、でも目指すのはインフラまわりのプロという
身の程を知らないレベル ですので、正直どの位置から追究してもあまり変わらないのです。。
↑図1：Windows 同士の FTP 通信
FTP クライアントとサーバは共に Windows マシンを用いており、サーバにログインできる ID/Password 情報は 「gen / genchan」 で統一させています。 接続の方法はコマンドプロンプトから FTP コマンドを使い、以下からは 「接続要求 → ID/Password 確認 → ログイン完了 → ログアウト」 の流れを追っていきます。
そしていつものことですが、 本メモは動作概念などの理解に力を入れますので、FTP サーバの設定方法や使い方などは他の解説サイトをご参照ください。 ……というよりも、もともと本ブログは設定方法やコマンドリファレンスのメモとして書いていたつもりでしたが、いつから概念野郎に心変わりしたのだろうかw (^ω^*)
■ セッションの接続 基本的にはいつもの TCP ハンドシェイクから始まります。
以下の画像は FTP コマンドプロンプトから [ open 10.1.1.2 ] を実行したときの結果です。
↑図2： FTP コマンドからセッション接続を行う
↑図3：セッション接続時にやり取りされるパケット内容
ハンドシェイクは通常通り行われますが、注目すべきところは FTP サーバ使っているポートが
TCP/21番 であることでしょうか。 TCP/IP のポート一覧表をご覧になった方はご存知かとFTP は使用ポート番号が2つありますので、ここはちょっと重要になってきそうですね。
これらのハンドシェイクを終えてセッションが確立すると、次は FTP の処理が始まります。 FTP サーバはクライアントへ向けて接続確認のメッセージを送りますが、このパケットの TCP ヘッダーには 「ACK, PSH」 のフラグが立っており、また FTP には以下のようなデータが格納されていました。
Response Code: Service ready for new user (220)
Response arg: Microsoft FTP Service
Service ready for new user と書いてありますので、英検27級 （年齢と共に上がっていく） の僕でも 「FTP 新規ユーザの接続待機中」 の状態であることが分かります。 加えて Microsoft FTP Service という文字列ですが、これは FTP のコマンドプロンプト上に表示されます。 図2 からも確認ができますね。
この FTP パケットを受けた FTP クライアントは、順当にいけば次にログイン情報をサーバに送信するのですが、その前に ACK フラグを立てた TCP セグメントを送り返します。 この動作に関してはいずれ TCP のフラグについてメモするときが来るはずなので、そのときに詳細を書かせて頂きます。
とりあえず今は 「PSH フラグが立っていたら ACK を返す」 という程度のイメージで問題なさそうです。
■ ログイン認証 FTP サーバとのセッションが確立しましたら、次はログイン認証です。
ユーザ名とパスワードを入力して、ログイン処理を行ったときのイメージ図が以下になります。
↑図4：FTP コマンドからログイン認証を行う
↑図5：ログイン認証時にやり取りされるパケット内容
ユーザ名を入力して FTP サーバへ送りますが、このとき FTP のデータ内を除いてみると "Request arg: gen" といったクライアント側で入力したユーザ名が確認できます。 こういった暗号化されていないデータのことを
平文 （ひらぶん） と言います。 本来なら何らかの方法で暗号化しますが、今回は
平文 （ひらぶん） のままでメモします。
このユーザ名が格納された FTP パケットを受け取ったサーバは、Response code 331 をクライアントに返します。 このときの FTP パケットには以下の情報が格納されています。
Response Code: User name okay, need password (331)
Response arg: Password required
パスワード入力を求められたクライアントは、次にパスワードを入力してサーバへ送信します。 前述もしました、ここで送信されたパスワード情報も
平文 （ひらぶん） のため、注意が必要ですね。
こうしてクライアントからパスワードを受け取ったサーバは、ログイン情報が正しければログイン処理を行いながら
ステータスコード 230 を返し、もしログイン情報が正しくなければ
ステータスコード 530 を返します。 このあたりはよくあるログイン処理と似ていますね。
ちなみに、なぜ
平文 （ひらぶん） を強調したのかといいますと、僕がその昔、平文を 「へいぶん」 とドヤ顔で言ったところ、その手のプロから 「セッション層をセション層と呼ばないヤツ、平文を “へいぶん” と読むヤツはエンジニアとして信用ならない」 と
ケチョンケチョン に言われたことがありました。
あのときのように
ケチョンケチョン に言われる辛さを皆さまには味わっていただきたくないので、今回
平文 （ひらぶん） を繰り返し強調させていただきました。 合言葉は
平文 （ひらぶん） でございますw
■ ログアウト FTP コマンドプロンプトから [ close / quit ] を実行することで FTP 接続を終了させられます。
せっかくなので、このログアウト動作についてもメモしていきます。
↑図6：FTP コマンドからログアウトする
↑図7：ログアウト時にやり取りされるパケット内容
FTP サーバへの接続を終了するときは、クライアントからサーバへ "quit" が送られます。 このメッセージを受け取ったサーバは
ステータスコード 211 をレスポンスし、ログアウト処理を行います。 あとはいつものように FIN / ACK フラグを立てたパケットを投げ合って、切断処理を実行します。
以上、FTP サーバへの接続/切断の流れでございました。
アクティブモード FTP には
Active Mode / Passive Mode の2種類が存在します。
Active Mode は、データ転送のコネクションを 「サーバ側」 から確立するもので、一方の Passive Mode は 「クライアント側」 から確立するものです。 これらの違いによって FTP の動作が異なるのです。
…と、そんなことを自分で書いておきながら、これらの情報だけでは Active / Passive の違いが全く分からない自分がおります。 僕のような想像力の乏しい人間は、やはり実際に動かしてみなければワカランので、以下から Active Mode によるデータ転送の動作を掴んでいきます。
↑図8：Active Mode のデータ転送
図8 では、データ転送のトリガーとなる [ get ] コマンドを実行してから、転送処理が終わるまでに “16個” のパケットを受信しています。 もちろん、転送されるファイルのデータ量によっては、16個以上のパケットがやり取りされますが、今回は数バイトの小さなテキストファイル (texas.txt) を転送対象のデータとしました。
また、図8 のやりとりを一気にメモすると見づらいため、見やすいように （と個人的には思っている） 3回に分けてパケットの解析をしていきます。 1回が 「
データ転送のセッション確立まで 」。 2回が 「
テキストファイルの指定から、データ転送の開始まで 」。 3回が 「
データ転送終了から、データ転送のセッション切断まで 」、といった流れでございます。
■ データ転送のセッション確立まで
↑図9：TCP/20 セッションの確立
1: TCP/21 （← データ制御の処理という意味）
まずはじめに FTP サーバにログインしたクライアントが [ get ] コマンドを実行すると、FTP サーバの21番ポートに向けて、データ転送に必要な情報 （ポート番号と IP アドレス） が送られます。 このとき送られたポート番号は
データ転送専用のポート番号 で、このポート番号を通知するこのコネクションで使われたコマンドを 「PORT コマンド」 と呼びます。
図9 の PORT コマンドでは"PORT 10,1,1,1,192,89" と指定されました。 この数値の先頭から4カンマまでがクライアントの IP アドレスを意味しており、5カンマ目の数値に定数 (256) を乗算し、その値に最後の数値を加算すると、クライアント側のデータ転送用のポート番号が算出されます。
2: TCP/20 （← データ転送の処理という意味）
PORT コマンドが FTP サーバで受け付けられると、今度はデータ転送用の FTP ポート "TCP/20" から、クライアントのデータ転送用ポートに向けて SYN フラグが立った TCP セグメントを送ります。 いわゆるハンドシェイクの開始ですね。
3: TCP/21 クライアントからの PORT コマンドの受信に対し、サーバはステータスコード 200 をクライアントへ向けて送信。 PORT コマンドが正常に受理されたことを通知します。
ちなみに、このときやりとりされるポート番号は、サーバ側が "TCP/21" で、クライアント側が "TCP/49240" です。 ということはデータ制御のコネクションは、データ転送のハンドシェイクを待たないということになり、TCP/20 と TCP/21 が完全に独立していることを意味しています。 言われてみれば当たり前のことですが、こうやって手と目で追ってみると、改めて実感させられますね。
4: TCP/20 5: TCP/20 4、5 はデータ転送用ポートのハンドシェイクなので省略します。
このハンドシェイクが終わると、データ転送用のセッションが確立されますので、次からはデータ転送の処理フェースが始まります。
■ データ転送のセッション確立まで
↑図10：データが転送されるまで
6: TCP/21 今回は [ get ] コマンドを使ったファイルダウンロードですが、このコマンドの実体は 「RETR コマンド」 にダウンロード対象のファイルを指定したメッセージです。 ここでは texas.txt というテキストファイルを転送するため、引数には texas.txt が指定されます。
ちなみに （RETR ってなんだろう） と思って調べてみたところ、これは "Retrieve" の意味でした。 魚釣り用語にもリトリーブという言葉があり、これはリールを巻いてルアーを泳がせることを指します。 僕は魚釣りが趣味なのでリトリーブという単語を頻繁に口に出しますが、実はリトリーブの意味まではよく分かっていませんでした。 なるほど Retrieve って 「取り返す・回収する」 っていう意味だったのですね。
…まてよ？ じゃぁこの Retrieve に "r" をつけたら Retriever になるわけですが、僕の実家で暮らしている
ラブラドール・レトリバー は英文で "Labrador Retriever" と書きます。 そうか！ ラブラドール・レトリバーって、ラブラドール地方で生まれた回収する犬 （猟犬？） という意味だったのか!!!
――と、すげーどうでもいい話にそれてしまいましたが、ともかく転送するファイルを指定する際には RETR コマンドを使いますｗ (//ω//)
7: TCP/21 RETR コマンドを受理したサーバはファイル転送処理を開始しますが、その前に
ステータスコード 125 をクライアントへ送信します。 FTP パケットの引数には Transfer starting と書かれており、転送開始を意味していることがわかりますね。
8: TCP/20 ここでファイル転送が開始されます。 このときはサーバの TCP/20 から、クライアントの 「1」 の get コマンドで通知したエフェメラルポートに向けてデータ転送が行われます。 前述もしましたが、転送ファイルの texas.txt は数バイトの容量が小さなデータのため、1パケットのみで事足りていますが、これがもっと容量が大きなデータとなりますと、やりとりされるパケット数が増えていきます。
9: TCP/21 10: TCP/20 サーバ側の TCP/20、21 ポート両方に ACK フラグが立ったセグメントが返ってきます。 これは 「7、8」 のセグメントが PHS, ACK フラグが立っていたことによるレスポンスです。
■ データ転送終了から、データ転送のセッション切断まで
↑図11：データ転送の終了とセッションの切断
11: TCP/20 ファイル転送が終了すると、サーバの TCP/20 ポートから FIN, ACK フラグを立てたセグメントをクライアントへ送ります。 これは言わずもがなセッションの切断を行うハンドシェイクのトリガーですね。
12: TCP/21 ファイル転送用のセッションに FIN, ACK フラグが立ったセグメントが流れると、サーバ側はデータ制御用のセッションに
ステータスコード 226 を送信します。 Closing data connection, Transfer complete. と FTP パケットには書かれていますので、これはファイル転送が正しく終わり、ファイル転送用のセッションを閉じることを意味します。
13: TCP/20 14: TCP/20 15: TCP/20 「11」 に続く、切断のハンドシェイク処理です。
このコネクションを終えると、データ転送用のセッションが切断されます。
16: TCP/21 この ACK フラグのセグメントは 「12」 の PSH, ACK に対するレスポンスです。 ファイル転送用のセッションがクローズされても、制御用のセッションはまだ生きていますので、こちらはまだまだ切断されません。
以上が FTP Active Mode でのファイル転送の流れでした。
FTP には他にも Passive Mode のデータ転送モードがありますが、本メモでは 「データ部にアドレスが書かれること」 の理解を中心に書いているため Passive Mode のメモは端折ります。
また、転送するファイルの容量が増えることで、データ転送のコネクションも増えていきますが、これには 「
シーケンス番号 」 が大きく絡んできます。 今の僕はシーケンス番号が絡む制御についてド素人なので、今回はこちらも端折らせて頂きます。
たぶん、次のメモはシーケンス番号が絡む制御について書くと思ふw (^ω^*)
FTP の NAT を失敗させる 冒頭に 「FTP は NAT 越えできない」 というセリフを書きました。
この記事を書く前は、その理由が理解できませんでした。 けれども前項の FTP Active Mode の動きを解析しながら追っていったことで、その理由が 「なんとなく」 ではありますが理解できてきました。 その 「なんとなく」 といった漠然とした気持ちを 「
ロジカルに理解するためにも 」 以下にメモしていきます。
……誤解のないように説明させて頂きますが、僕は
ロジカル人間 ではありません。
あくまでインフラまわりのプロを目指すために、自ら体にムチを打って苦手なロジカルな世界に飛び込んでいるだけで、本当の僕は （ネットワーク?? そんな難しいことは
プロに任せればイーヨww ）< と常に考えております。
プロを目指しているのプロに任せようとする、そんな素晴らしい
怠け癖 を持っている人間が書いているブログですので、どうかみなさま肩の力を抜きながら本ブログを読んでくださいましw d(^q^*)
では、以下のような ActiveMode の環境で FTP の NAT 越えを検証します。
↑図12：FTP クライアント/サーバ間にルータを置いただけ
次にルータは vyatta を使い、以下の設定を追加しました。
# show nat
上記の設定を施すことで、eth0 からの通信はすべて IP マスカレードされます。
ポート番号は 60000～61000 の間を NAPT。また NAT した IP アドレスは 20.1.1.254 が使われます。 [ address masquerade ] コマンドを実行すると、NAT に使われる IP アドレスは [ outbound-interface eth1 ] で指定したモノが使われます。 すなわち、eth1 インターフェースに設定した IP アドレスになります。
さっそく図12の環境にて、FTP クライアントからサーバの texas.txt をダウンロードします。
このときクライアントが実行したコマンドは [ get texas.txt ] コマンドです。 通常、ActiveMode の動きとしては、ダウンロードをはじめる前に POST コマンドに指定された情報から、クライアントのデータ転送用アドレス/ポートを割り出すことは前述したとおりですが、今回は NAT を挟んでいることから以下のような現象が発生します。
FTP パケットはいわゆるアプリケーション層に位置します。 けれども NAPT は L3 と L4 ヘッダーの変換のみ行いますので、
アプリケーション層 （POST コマンド） で指定された情報までは書き換えてくれません。 ということは、POST コマンドから割り出したファイル転送用のアドレスとポート番号は、NAPT する前のアドレスとなることから、サーバからのレスポンス （ハンドシェイク） を開始することができないのです。
これが 「
FTP は NAT 越えできない 」 の真理でございます。
それでは、以下から NAT 越えできない FTP パケットを解析してみましょう。
↑図13：NAPT された FTP パケット……
………。
（あれ？ POST コマンドで指定した IP アドレスが
書き変わってるじゃない… ）
どうやら僕は
とんだ嘘つき だったようです。
実は FTP データ部を NAPT すると、論理的には NAPT 前の IP アドレスが指定されたままになりますが、最近のルータ （含む NAT 機器） では、
データ部の IP アドレスを NAPT の環境に合わせて書き換えてくれるそうです。 Cisco では、こういったアプリケーション層のデータ部に埋め込まれた IP アドレスを書き換える仕組みを "
ALG - Application Level Gateway " と呼び、これはヤマハルータでもお馴染みの "
NAT Traversal " 技術の1つです。
NAT Traversal はとても大切な技術なので、近々詳細にメモしていきます。 NAT Traversal を理解しておかないと、ヤマハルータで L2TP/IPsec サーバを構築するとき、なかなか構築できずに担当者から怒られる羽目になります。 そう、僕のように…。OTL
ただ、個人的に気になるのが 図13 の青枠、いわゆる NAPT の P の部分です。
データ部で指定された IP アドレスが NAPT 後のモノに書き換わっているのならば、ポート番号も書き換えなくてはいけない気がします。 ですが 図13 では、ポート番号が NAPT される前のエフェメラルポートのままであり、これは少々違和感がありました。
ちなみにヤマハルータで同様の検証を行ったところ、こちらはポート番号まで NAPT されました。
↑図14：vyatta を RTX1100 に変えて検証した結果
図14 の赤枠で囲った部分が POST コマンドを受理したあとに動作するファイル転送用ポートです。 NAT テーブルにも、データ部に指定されたポート番号 60003 が登録されているため、こちらは筋が通っていますね。
Vyatta では、データ部に指定されたポート番号を
NAT 前と同じポート番号を使う仕様 なのか、または
ただの僕の設定漏れ なのかは分かりませんが、どちらにせよ ALG 機能によって正常に NAPT されていました。
↑図15：vyatta の NAPT の動き
図15 は Vyatta の内向きと外向きの NAPT 動作を表示したものです。
赤枠で囲ったメッセージは 「FTP クライアント → FTP サーバ」 通信時に NAPT 処理された Source Address/Port の情報です。 具体的には "10.1.1.1:49312" → "20.1.1.254:60003" といった形で NAPT されており、宛先ポート番号が 21 となっていますので、ALG がしっかりと適用されています。
青枠で囲ったメッセージは 「FTP サーバ → FTP クライアント」 通信時に NAPT 処理された Destination Address/Port の情報です。 "20.1.1254:49313" → "10.1.1.1:49313" といったように相変わらず NAT されていますが NAPT されない、でも動いている状況ではあります。
ということは、データ部のポート場号に ALG 処理が働かないのは
Vyatta の仕様である ……と、自分に言い聞かせることにしました。（……たぶん仕様じゃなくて設定漏れだと思う…w）
■ 意地でも NAT を失敗させる Vyatta とヤマハルータ （NAT 機能搭載ルータ？） は、NAT 設定を施すことで ALG 機能が働き、IP/TCP ヘッダーに加えて FTP データ部のファイル転送用 IP アドレスも書き換えることが分かりました。
けれども、これでは本項のタイトルにもあります 「FTP の NAT を失敗させる
“に失敗” 」 していることになります （失敗の失敗、と表現すると混乱するw）。 となりますと FTP 通信で NAT を失敗させるには、どうすればいいでしょうか。
色々と考えた結果 「
ALG 機能を搭載していない NAT BOX 」 を使うことを思いつきました。
ここでルータではなく "NAT BOX" と表現したのは、この検証では
iptables (CentOS) を使うからです。 iptables に NAT チェインを追加すれば立派な NAT BOX になりますし、なによりも iptables (CentOS?) のデフォルトでは ALG 機能は搭載していないと予想しています。 iptables は今回の検証に超最適でございます。
ではさっそく検証するため 図12 の vyatta を CentOS に置換した上で、以下の設定を iptables に施しました。
# vi /etc/sysconfig/iptables-A POSTROUTING -s 10.1.1.0/24 -d 20.1.1.0/24 -j MASQUERADE
この設定を施すと FTP Client が送信するパケットの送信元 IP ヘッダーが 20.1.1.254 に NAT されます。 ただし、あくまで NAT であり NAPT はされません。 ちなみに filter のデフォルトポリシーは全て許可 (ACCEPT) しています。
この状態で [ get texas.txt ] コマンドを実行させると、wireshark から以下のようなパケットが解析できました。
↑図16：ついに失敗!! ktkr!!!!!
やっと NAT に失敗しましたわよ！ 予想が当たる、って嬉しいですよね。 ロジカル人間じゃなくともニヤニヤしてしまいますw
そんなニヤつきながら、図16 の詳細をメモしていきます。
① NAT された PORT コマンドを見てみると、予想通りファイル転送用 IP アドレスが
書き変わっていませんでした （①'）。 iptables (Netfilter?) のデフォルトでは、ALG 機能がオフになっているようですね。
② 続いて TCP/20 ポートによるハンドシェイク処理ですが、POST コマンドで通知されたアドレス情報が間違っているため
ステータスコード 501 が返されてしまい、ハンドシェイクが行われませんでした。 ステータスコード 501 は "Syntax error in parameters or arguments" と書かれており、引数またはパラメータの文法が間違っていることを意味しています。 今回は PORT コマンドの引数が変換されていないので、まさしくズバリですね。
③ TCP/20 ポートのハンドシェイクが未実施なのに、TCP/21 ポートは RETR コマンドを受け入れました。 どうやら一応は処理が続くようです。
④
ステータスコード 150 を FTP Server は返します。 これは "File status okey; about to open data connection" と表されており、ファイル (texas.txt) の指定は正しいため、TCP/20 の状況には関係なくファイル転送処理を始めようとします。
⑤ ところが TCP/20 のセッションは確立されていないため、
ステータスコード 425 が続けて FTP クライアントへ送られます。 "Cannot open data connection" ファイル転送用のコネクションが開いていない、という意味ですね。 当たり前です。
前言撤回。
FTP の NAT 越えに失敗しましたので、、、
僕は
辛うじて嘘つきではない ということが判明しました。
（ｱﾌﾞﾈｰw）
さて、思わぬ ALG によって FTP の NAT 越えに苦戦してしまいましたが、以上のような理由で 「FTP は NAT 越えできない」 ことが分かりました。
一応は目標は達成しましたので、ここでハッピーエンドを迎えても差し支えないのですが……。 でもよく考えたら、上記の検証は
パケットフィルタリング未設定 なので、しっかりとパケットフィルタリングを設定した環境で試しておいた方がいいような気もしてきました。
けれども、パケットフィルタリングを設定した環境で FTP の NAT 越えを検証するとなると、次は "
Passive Mode " についても理解しておかなければイケマセン。 いや、イケナイというわけではないのですが、Passive Mode を知っておいた方が 「理解がグッと深まる」 ことに
気づいてしまいました。。 悪魔 「Passive Mode？ 面倒くせぇよ、漠然とだけ知っときゃいいってwww」
天使 「いいえ!! Passive Mode の理解こそ、インフラまわりのプロに欠かせないわよ!!」
と、僕の脳内で 「天使（努力） vs 悪魔（怠け）」 が戦っており、正直
(悪魔よ、頑張ってくれ…!!） と祈ったのですが、やはりインフラまわりのプロを目指すためにも、ここは悪魔に負けてもらうことにしましたw
パッシブモード FTP には Active Mode / Passive Mode の2種類が存在するのは、前述したとおりです。
また 「
今回のメモでは Passive Mode は端折る 」 と言ったのも、前述の通りです。
そんな Passive Mode ですが、やはりメモすることにしました。 知識は少しでも多く持っておいた方がいいですし、追究することで新しいアイディアが思いつくかもしれないので、いざチャレンジでございます。
まずはじめに。 Active Mode の検証では FTP クライアントに Windows を使いましたが、情けないことに Windows の Passive Mode の使い方が分からなかったので、今回は FTP クライアントに Ubuntu 12.04 を使いました。
Ubuntu の FTP コマンド画面に [ passive ] コマンドを実行すると "Passive mode on." と表示されます この状態で [ get texas.txt ] を実行すると、その通信が Passive Mode として機能するようです。
そんな Passive Mode のファイル転送を実行すると、以下のようなパケットが解析できました。
↑図17：Passive Mode のパケット内容
図17 を見ると分かるように Passive Mode の重要なポイントは、ファイル転送が行われる FTP サーバの 「
ポート番号が異なること 」 です。 Active Mode の FTP サーバは TCP/20 がファイル転送用のポート番号でしたが、Passive Mode ではそれがエフェメラルポートに変わっています。 また Passive Mode では PORT コマンドを使わないところも含め、このやり取りを以下にメモしていきます。
↑図18：①～⑥ まで。 Active Mode と重なる処理は省く
① Active Mode では PORT コマンドを使ってファイル転送用のポート番号をサーバに通知しますが、今回クライアントは 「
PASV コマンド 」 のみをサーバへ投げます。
② PASV コマンドを受け取ったサーバは、
ステータスコード 227 と一緒に IP アドレスとポート番号を返します。 ステータスコード 227 は Passive Mode で使うサーバのファイル転送情報を通知するもので、ここで指定されたポート番号がサーバのファイル転送用ポート番号を意味します。 ここでは "Passive port: 49190" が指定されており、
TCP/49190 がサーバのファイル転送に使われることになります。
③ ファイル転送セッションのハンドシェイクが行われます。 Active Mode ではサーバ側からハンドシェイクを始めましたが、今回の Passive Mode ではクライアント側からハンドシェイクが始まりました。 「FTP のアクティブとパッシブの違いは、接続要求の開始がサーバであるかクライアントであるかの違い」 と言われますが、
それがまさにここです。 ④ ここは Active Mode と一緒で、RETR コマンドで転送するファイルを指定し、
ステータスコード 150 （正常） をトリガーにファイル転送が行われます。
⑤ ファイル転送が行われましたが、ここで使われるサーバのポート番号が前述したエフェメラルポート (TCP/49190) であることがポイントですね。
⑥ ファイル転送が終わり、ファイル転送セッションの切断処理が始まります。 これらの処理は Active Mode と同じなので、ポイッと端折っちゃいます。。
以上、Passive Mode の動きでした。
Active Mode と Passive Mode の違いを理解しようと試みたとき、最初はテキストを読んだのですが （
はぁ?? 意味がわからねぇぞ!? ） と投げかけましたが、実際にこうやって動かしてみると （
あら、この程度の違いだったのね… ） とアッサリ理解できました。 やっぱり実際に手を動かしてみることは大切ですね。
さて、Passive Mode と Active Mode の違いを理解できたところで、本メモを締めくくる 「パケットフィルタ」 を設定した状態の FTP 通信を次項にてメモしていこう……と思ったのですが、ここに来て僕の脳内で 「
天使（努力） vs 悪魔（怠け） 」 のバトルが再戦いたしてしまいました。。
なぜ脳内バトルが再戦されたのか。 それはパケットフィルタを用いた FTP 通信を理解するには 「
動的フィルタ 」 というパケットフィルタの技術を理解しなければなりません。 この動的フィルタについてのメモを書こうとすると、これだけで1つの記事が出来上がってしまう恐れがあり――
（早く FTP の記事を終わらせたいなぁ…）
といった悪魔的思考になってしまったのです。
………。
ま、まぁ振り返ってみますと、本メモの最終目的は 「FTP は NAT 越えできないことの理解」 にありますから、一応は目的達成をしていますので、やっぱりパケットフィルタを使った FTP の検証は
保留 ということで……お願いいたします。。OTL
最後に この記事を書きはじめた日付は 「2014年9月9日」 です。
ところがこの記事を書き終えた日付は、なんと 「2014年10月31日」 です。
1つの記事を書くのに、なぜここまで時間がかかるのか？
その答えは僕が
怠け者 だからであり、
そんなことは分かり切っていますので、言うまでもなく今回の話題には挙げません。
それよりもこの記事を書き終えた
10月31日 。
世間では何の日でしょうか？
そう、
ハロウィン ですね。
ハロウィンは、もともと日本では馴染みの薄いイベントでしたが、
最近はハロウィンブームとでもいいますか、世間でも身近になりつつあります。
ちなみに僕は
カボチャの煮つけ があまり好きじゃないので、
毎年ハロウィンに興味を持ちませんでしたが、
今年はちょっと違いました 。
なんとワタクシ、
ハロウィン仮装した近所の保育園児にお菓子をあげる役 を任されました。
このような役を演じるようになった経緯とか、詳細とかはこの際割愛するとして、
ともかく僕は、仮装した園児たちの前に立ったのです。
園児たちは声を揃えて、僕に向かって――
園児 「「「とりっく おあ とりーと！！」」」
それに対して、ぼくは――
ぼく 「おかしあげるからイタズラしないでー！！」
と、オーバーリアクションで、僕は園児たちを怖がりました。
ところが―――
こういう役を引き受けたわりには、
僕はこういうことに
慣れていない人間 なので、
とってもぎこちなく、そして棒読み そんな僕を見た園児たちの方が、よっぽど怖かったような気がします。
園児「「「………」」」
ぼく「はい、おかしどうぞー」
園児「「「………」」」
ポイッ
ぼく「
！？ 」
この際、イタズラしてもいいから、
せめて、捨てないでください…… OTL
スポンサーサイト
