【ICMP】【NAPT】

NAPT(IPマスカレイド)環境において、内部ネットワークから外部ネットワークに対してpingをしたときの処理の流れを教えてください。

NAPTは、
「ポート番号を用いて、外部ネットワークからの戻りパケットを内部ネットワークのどの端末に返せばよいかを判別している」
と理解しています。

このような場合、ポート番号を利用しないping(ICMP)はどのように処理を行っているのでしょうか?


調べてみたところ、
> ただし、ポート番号の変換が行なわれるため、インターネット側から内部のマシンに接続を開始するような使い方はできず、ICMPも利用できないなどの制限がある。
> 最近のブロードバンドルータなどではこうした制限を緩和するための独自の実装を行なっているものもある。
http://e-words.jp/w/NAPT.html

私の自宅では、PLANEXのブロードバンドルータを使っていて、外部ネットワークにpingができたような気がします。
なので、上記の「独自の実装」の内容を教えてください。

どうぞ、よろしくお願いいたします。

回答の条件
  • 1人3回まで
  • 登録:2009/10/02 09:45:30
  • 終了:2009/10/06 19:25:13

ベストアンサー

id:takfjt No.2

takfjt回答回数23ベストアンサー獲得回数32009/10/02 11:37:51

ポイント75pt

RFC3022(Traditional IP Network Address Translator (Traditional NAT))によりますと、ICMPのqueryについては、ペイロードにある識別子をTCPやUDPのポート番号のように扱うことで、NAPTを実現することが想定されているようです。

RFC792で示されているquery/responseタイプのICMPメッセージは、エコー(ping)、タイムスタンプ、情報リクエストの三種類ありますが、そのいずれもフォーマットの中に識別子を持っており、それを利用することになっているようです。

ただし、RFC792では識別子は"may be zero"なんて書いてありますので、TCPやUDPのように確実に変換できる保証はないです。

ICMPをサポートしているNAPTルータであっても"多分できる"程度と考えておくのがよいと思います。

また、ICMPついでですが、ICMP未到達メッセージなどは、そのペイロードにエラーの発生原因であるパケットを内包しています。そのパケットのIPヘッダについてもNAPTテーブルに基づいて変換しなければならないとあります。

ICMPもインターネットの基本プロトコルとして、NAPTでも一通りのことは考えているようです。

RFC3022

http://www.rfc-editor.org/rfc/rfc3022.txt

http://www5d.biglobe.ne.jp/~stssk/rfc/rfc3022j.html

RFC792

http://www.rfc-editor.org/rfc/rfc792.txt

http://srgia.com/docs/rfc792j.html

id:hina1981

コメントにて補足までありがとうございます。


ご紹介いただいたRFC3022の二番目のURLの中にも

> NAPT翻訳はIPアドレスとトランスポート識別子(TCP/UDPポートやICMP問合せ識別子)を含むように拡張されます。

とあるので、RFCの中でICMPの識別子フィールドを使うように決められているようですね。


RFC792でも、確かに「may be zero.」とありますね。

ただ、その前に、

If code = 0, an identifier to aid in matching echos and replies,

(コード = 0 の場合、リクエストとリプライとを対応させる手助けとなる識別子である。)

ともあるので、このフィールドを使ってアドレス変換を行うのは理想的な気もします。


ただ、ICMPでidentify fieldがあるのが、リクエストとリプライだけですね。

ということは、コメントでJULY様が書かれていますが、他のメッセージをやり取りする場合には、

別途、何らかの方法が必要になってくる(ここが独自実装の部分?)のですかね。

2009/10/05 11:50:56

その他の回答(1件)

id:zzz_1980 No.1

zzz_1980回答回数492ベストアンサー獲得回数642009/10/02 11:04:13

ポイント75pt

PLANEXのルーターがどのような実装になっているかは知りませんが、CISCOの例では、

ICMP header の identify field を見ています。

機械翻訳のようで訳がだいぶ怪しいですが。

NAT の ICMP フラグメントの処理方法

id:hina1981

2009/10/2記入:

ありがとうございます。

確かに、微妙な日本語ですね……。


とりあえず、YAMAHA RTX1100があったので、NAPTを構築し、

LAN内のクライアント(A,B)とインターネット内のサーバの双方でWireSharkを使ってみてみました。

クライアントA:

Identificationフィールド 0x0200

Checksumフィールド 0xb25b

サーバ(クライアントAからのパケット):

Identificationフィールド 0xea73

Checksumフィールド 0xd3e7

クライアントB:

Identificationフィールド 0x0200

Checksumフィールド 0x2be6

サーバ(クライアントBからのパケット):

Identificationフィールド 0xea75

Checksumフィールド 0x346e


確かに、Identificationフィールドで制御してそうなカンジですね。

で、ヘッダ情報を書き換えてるせいで、Checksumフィールドもルータ側で書き換えているみたいですね。


もう少し、ご紹介いただいた文書を読んでみます。


2009/10/5追記:

いろいろ混乱していたのですが、ようやく整理できてきました。

まず、IPヘッダ内のIdentify fieldと、ICMPヘッダ内のIdentify fieldが別物としてあるのですね。

で、

・IPヘッダ内のIdentify fieldは、中継ルータがパケット分割をした際の再構築用

・ICMPヘッダ内のIdentify fieldは、NAPT機が送受信を判断する(トランスポート層のポート番号と同じように使う)ため

なのですね。

(今、読み返してみると、そう書いてありますね……)

2009/10/05 11:42:12
id:takfjt No.2

takfjt回答回数23ベストアンサー獲得回数32009/10/02 11:37:51ここでベストアンサー

ポイント75pt

RFC3022(Traditional IP Network Address Translator (Traditional NAT))によりますと、ICMPのqueryについては、ペイロードにある識別子をTCPやUDPのポート番号のように扱うことで、NAPTを実現することが想定されているようです。

RFC792で示されているquery/responseタイプのICMPメッセージは、エコー(ping)、タイムスタンプ、情報リクエストの三種類ありますが、そのいずれもフォーマットの中に識別子を持っており、それを利用することになっているようです。

ただし、RFC792では識別子は"may be zero"なんて書いてありますので、TCPやUDPのように確実に変換できる保証はないです。

ICMPをサポートしているNAPTルータであっても"多分できる"程度と考えておくのがよいと思います。

また、ICMPついでですが、ICMP未到達メッセージなどは、そのペイロードにエラーの発生原因であるパケットを内包しています。そのパケットのIPヘッダについてもNAPTテーブルに基づいて変換しなければならないとあります。

ICMPもインターネットの基本プロトコルとして、NAPTでも一通りのことは考えているようです。

RFC3022

http://www.rfc-editor.org/rfc/rfc3022.txt

http://www5d.biglobe.ne.jp/~stssk/rfc/rfc3022j.html

RFC792

http://www.rfc-editor.org/rfc/rfc792.txt

http://srgia.com/docs/rfc792j.html

id:hina1981

コメントにて補足までありがとうございます。


ご紹介いただいたRFC3022の二番目のURLの中にも

> NAPT翻訳はIPアドレスとトランスポート識別子(TCP/UDPポートやICMP問合せ識別子)を含むように拡張されます。

とあるので、RFCの中でICMPの識別子フィールドを使うように決められているようですね。


RFC792でも、確かに「may be zero.」とありますね。

ただ、その前に、

If code = 0, an identifier to aid in matching echos and replies,

(コード = 0 の場合、リクエストとリプライとを対応させる手助けとなる識別子である。)

ともあるので、このフィールドを使ってアドレス変換を行うのは理想的な気もします。


ただ、ICMPでidentify fieldがあるのが、リクエストとリプライだけですね。

ということは、コメントでJULY様が書かれていますが、他のメッセージをやり取りする場合には、

別途、何らかの方法が必要になってくる(ここが独自実装の部分?)のですかね。

2009/10/05 11:50:56
  • id:standard_one
    toインターネットとfromインターネットで等価にpingを打ちあいできないのがおかしいって話ですか?
    LAN内のあなたのマシンにはグローバルIP振ってないですよね?ソレが答えです。

    それともpingの答えはどうやってローカルのマシンを識別して戻ってくるんだ?て話ですか?
    別に相手はping打ち返してくるわけじゃないですよ?
  • id:hina1981
    >> standard_one様
    えっと、プライベートIPアドレスネットワーク内の送信側(A)と、インターネット内の受信側(B)とブロードバンドルータ(C)がある場合、

    AからBに対して、httpアクセスする場合には、
    A⇒C⇒B⇒C⇒Aという流れでパケットがやり取りされます。


    このとき、
    ① A⇒Cのパケット:
    送信元IPアドレスは、A
    送信先IPアドレスは、B


    ② C⇒Bのパケット:
    送信元IPアドレスは、Cのグローバルアドレス(アドレス変換)
    送信先IPアドレスは、B


    ③ B⇒Cのパケット:
    送信元IPアドレスは、B
    送信先IPアドレスは、Cのグローバルアドレス


    ④ C⇒Aのパケット:
    送信元IPアドレスは、B
    送信先IPアドレスは、A(アドレス変換)


    これと同様に
    AからBに対してpingを送った時の処理が知りたいです。
    上記のようにアプリケーション層まである通信の場合であれば、上記の②の処理で送信元IPアドレスをAからCに変換する際のポート番号の情報を使って、④で変換するアドレスが識別されます。
    ただ、ICMPの場合には、アプリケーション層がない(ポート番号を利用しない)通信のため、戻りのパケットの送信先を識別する方法がありません。
    その場合、どのように④のアドレス変換を行うのかを知りたいです。
  • id:JULY
    確かに「NAPT」は「Network Address Port Translation」だから、ポート番号を持たない ICMP はどうなるんだ? と思いますね。TCP や UDP であれば、グローバル側のポート番号によって、ローカル側のどのホストへパケットを転送すべきかを判断しているけど、じゃぁ、ICMP は?

    ping(icmp echo) に関しては、zzz_1980 さんの言うように、Identifier で識別できそうですが、だとすると「Port Translation」ではないんで、そう考えると、N 対 1 のアドレス変換において、icmp は厳密には「NAPT」の範疇では無い、ということになるのかな?

    ping は Identifier で識別できるとしても、Destination Unreachable とか、他の icmp はどうなっているのかも気になったりしますね。

    参照:
    http://www.asahi-net.or.jp/~AA4T-NNGK/ipttut/output/icmpheaders.html

    今まで、漠然と「N 対 1 のアドレス変換は NAPT」と思っていたけど、語源から考えると、そうとばかりは言えないのかもしれませんね。
  • id:takfjt
    修正

    > また、ICMPついでですが、ICMP未到達メッセージなどは、そのペイロードにエラーの発生原因であるパケットを内包しています。そのパケットのIPヘッダについてもNAPTテーブルに基づいて変換しなければならないとあります。

    ICMPエラーメッセージは、ペイロードにエラーの発生原因であるパケット(おそらくはTCPかUDP)を内包しています。NAPTルータは、そのペイロード内パケットのアドレスとポート番号を元に、ICMPメッセージ自身のIPヘッダとペイロード内パケットのIPヘッダおよびTCP/UDPヘッダを書き換えることができます。
    これだとペイロードにオリジナルパケットを持っていないICMPエラーは変換することができませんが、そのようなエラーはそもそも受け取る意味が無いので破棄してもかまわないでしょう。
    また、リダイレクトだけは内側ホストのパケットが原因であったとしてもNAPTルータ自身でモニタしなければならないとあります。
  • id:standard_one
    hina1981さんが混乱してしまう根本はネットワーク上にpingパケットだけが流れていると思っているからだと思います。
    IPもポート番号もイーサの上で「ごっこ」をしているだけです。
    tcpdumpでも使って流れてるフレームを見てみてください。
  • id:hina1981
    >> JULY様
    厳密な言葉の意味で言うと、やはりICMPはNAPTではないですね。
    NAIT(Network Address Identify Translation)とか(^^;

    ping以外のメッセージのやり取りについては、コメントを読ませていただくまで、
    考えていませんでした。
    JULY様のコメントを読ませていただいた後で、2の回答のURLを見るとIdentify fieldが存在しないメッセージフォーマットがありますね。
  • id:hina1981
    >> takfjt様
    エラーレスポンスがICMPパケット内にエラーパケットそのものを内包しているのは、
    WireShark等で見たことがあります。


    NAPTがその内包しているエラーパケットまでチェックし、内部ネットワーク宛にアドレスを変換しているというのは驚きました。
    でも、確かにそうしないと内部ネットワーク内のコンピュータが不達メッセージを正しく処理できませんね。

    NAPTもICMPも仕組み自体は、単純だと思っていたのですが、こんなに奥が深かったんですね。
    非常に勉強になりました。
    ありがとうございます。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません