id:hina1981
ポイントあり150ptベストアンサーあり
コンピュータインターネット

【ICMP】【NAPT】

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

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

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


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

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

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

回答の条件
  • 1人3回まで
  • 登録：
  • 終了：2009/10/06 19:25:13
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:takfjt No.2

回答回数23ベストアンサー獲得回数3

ポイント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の中にも

> ＮＡＰＴ翻訳はＩＰアドレスとトランスポート識別子（ＴＣＰ／ＵＤＰポートやＩＣＭＰ問合せ識別子）を含むように拡張されます。

とあるので、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

回答回数492ベストアンサー獲得回数64

ポイント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

回答回数23ベストアンサー獲得回数3ここでベストアンサー

ポイント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の中にも

> ＮＡＰＴ翻訳はＩＰアドレスとトランスポート識別子（ＴＣＰ／ＵＤＰポートやＩＣＭＰ問合せ識別子）を含むように拡張されます。

とあるので、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

コメント（7件)

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

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

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


    このとき、
    ①　Ａ⇒Ｃのパケット：
    送信元IPアドレスは、Ａ
    送信先IPアドレスは、Ｂ


    ②　Ｃ⇒Ｂのパケット：
    送信元IPアドレスは、Ｃのグローバルアドレス（アドレス変換）
    送信先IPアドレスは、Ｂ


    ③　Ｂ⇒Ｃのパケット：
    送信元IPアドレスは、Ｂ
    送信先IPアドレスは、Ｃのグローバルアドレス


    ④　Ｃ⇒Ａのパケット：
    送信元IPアドレスは、Ｂ
    送信先IPアドレスは、Ａ（アドレス変換）


    これと同様に
    ＡからＢに対してpingを送った時の処理が知りたいです。
    上記のようにアプリケーション層まである通信の場合であれば、上記の②の処理で送信元IPアドレスをＡからＣに変換する際のポート番号の情報を使って、④で変換するアドレスが識別されます。
    ただ、ICMPの場合には、アプリケーション層がない（ポート番号を利用しない）通信のため、戻りのパケットの送信先を識別する方法がありません。
    その場合、どのように④のアドレス変換を行うのかを知りたいです。
  • id:JULY
    JULY 2009/10/02 11:37:33
    確かに「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
    takfjt 2009/10/02 11:59:10
    修正

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

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

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


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

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

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

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

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

回答リクエストを送信したユーザーはいません
ユーザー登録をして使いはじめる!無料
すでに登録されている方はこちらからログイン
この質問に含まれるキーワード
知りたいことを検索してみよう
▲ページトップへ