はじめての「ヤマハ vRX さくらのクラウド版」（7）NAT（IPマスカレード、NAPT）の適用

この連載では、ヤマハ仮想ルーター vRXをさくらのクラウドで検証する環境を構築いたします。「ヤマハ vRX さくらのクラウド版」がどのように動作するのかや検証費用について説明する予定です。皆さんも検証環境を作って、いろいろ試してみてください。

今回は、「ヤマハ仮想ルーター vRX」にNATディスクリプター（NAT、IPマスカレード）を設定します。第6回でセキュリティフィルターを適用した状態からスタートします。

NAT関連技術文書	文書タイトル
RFC1631 (May 1994)	The IP Network Address Translator (NAT)
RFC2663 (August 1999)	IP Network Address Translator (NAT) Terminology and Considerations
(参考) ヤマハネットワーク製品技術情報(Rev.1.06以降：Jun 1996)	NAT機能とIPマスカレード機能(初期の文書)
(参考) ヤマハネットワーク製品技術情報(Rev.4.00以降：Jan 1999)	NATディスクリプターの背景
(参考) JPNIC (2013年3月発行)	初めてのNAT
(参考) 日経xTECH (2018.01.31)	NATとNAPTは何が違う？

NAT、NAPT、IPマスカレードの技術文書

観察環境の概念図
vRXを起動する
今回の観察ポイント
NATディスクリプター機能とは
vRXをシャットダウンする
パケットの流れのまとめ
関連リンク
検証経費
連載トップへのリンク

観察環境の概念図

観察環境は第5回、第6回と変わりません。観察するvRXの機能が変わります。

vRXを起動する

検証を開始する前に、検証対象のvRXを起動します。

第2回の「コントロールパネルを開く」を参考にコントロールパネルを開きます。
第2回の「vRXの起動」を参考にvRXを起動します。

今回の観察ポイント

初期状態のセキュリティーフィルターは、第6回の「セキュリティーフィルター定義(2)→pingの動的フィルター機能」です。

... ＜＜＜セキュリティーフィルターを設定する＞＞＞
# syslog notice on

[静的フィルターの定義]
# ip filter 298 reject-log * * * * *　　　　　　　　　　　　　　　{INは、破棄してログを記録する}
# ip filter 299 pass-log * * * * *　　　　　　　　　　　　　　　　{OUTは、通してログを記録する}

[動的フィルターの定義]
# ip filter dynamic 280 * * domain
# ip filter dynamic 281 * * ping　　　　　　　　　　　　　　　　　{内→外のpingを通す}
# ip filter dynamic 298 * * tcp
# ip filter dynamic 299 * * udp

[接続先フィルターの入力(IN)と出力(OUT)の適用]
# ip lan1 secure filter in 298
# ip lan1 secure filter out 299 dynamic 280 281 298 299

ここにNATディスクリプター（NAT、IPマスカレード、NAPT）を設定して、パケットがどのように処理されるか確認します。

1) 第6回で保存してある「設定ファイル番号」を確認します。show config listを実行すると3番であることがわかります。

2) 3番の設定ファイルを確認します。show config 3を実行すると設定内容が表示されます。

3) restart 3を実行すると、3番の設定ファイルで再起動します。

ヤマハの公開情報
ヤマハネットワーク製品技術情報ページ
→ コマンドリファレンス
→ → show config list
→ → show config
→ → restart

NATディスクリプター機能とは

NATディスクリプターとは、ヤマハルーターのPPインターフェース（ISDN回線でインターネット接続するインターフェース）に組み込まれたNAT機能を定義とプログラム（コアとなるNAT変換処理）と管理テーブル（NATテーブル）に分離し、LANインターフェースやTUNNELインターフェース（IPsec Tunnelなど）に自由自在に適用できるようにしたものです。定義の独立は使い方を標準化できます。プログラムの共通化は信頼性を向上します。NATは流れているデータ（IPパケット）を常時書き換える技術です。IPv4にかかわるほとんどのプロトコルをカバーしなければいけない難しい技術です。NATディスクリプターは、コアとなるNAT変換処理の信頼性を高め、使い方の利便性を高める機能なのです。

NAT機能は、PPPインターフェース専用でした。NATディスクリプター機能は、NAT定義とインターフェース適用を分離して、NATを自由自在にインターフェース適用できるようにした機能向上版です。これにより、PPPインターフェース、LANインターフェース、TUNNELインターフェースへ柔軟にNAT機能を適用できるようになりました。

ヤマハネットワーク製品技術情報
NAT機能とIPマスカレード機能 (Rev.1.06以降、Jun 1996)
NATディスクリプターの背景 (Rev.4.00以降、Jan 1999)

ヤマハネットワーク製品のNAT、IPマスカレードの技術文書

IPマスカレードを適用する

NATディスクリプターでIPマスカレードを定義して、LAN1インターフェースに適用します。IPマスカレードは2～4個程度のコマンドを投入すれば利用開始できます。

一連の操作コマンドを先に提示し、その後で各作業項目ごとの解説を行います。

コマンド	設定内容
nat descriptor type	NAT変換タイプを指定します。今回はIPマスカレードを利用します。
nat descriptor address outer	NAT変換に用いる外側IPアドレスを指定します。今回はLAN1インターフェースに配布されたグローバルIPアドレスを指定します。
nat descriptor address inner	NAT変換対象の内側IPアドレスを指定します。今回はすべてのIPアドレスを変換対象とします。
nat descriptor log on	NAT変換に関するログを記録します。
ip lan1 nat descriptor	NAT定義をインターフェースに適用します。適用すると内部にNATテーブルが準備されます。
show nat descriptor addess all	NAT定義の変換テーブルを表示します。

... ＜＜＜IPマスカレードを設定する＞＞＞
 
[NATディスクリプターの定義]
# nat descriptor type 1 masquerade　　　　　　　　　　　　　{変換タイプをIPマスカレードに設定する}
# nat descriptor address outer 1 primary　　　　　　　　　　{LAN1アドレスをNATの外側IPアドレスに設定する}
# nat descriptor log on　　　　　　　　　　　　　　　　　　　{NATのアドレス割当をログに記録する}

[NATディスクリプターのLAN1インターフェースへの適用]
# ip lan1 nat descriptor 1　　　　　　　　　　　　　　　　　{LAN1インターフェースへNATディスクリプタを適用}

[NATディスクリプターの変換テーブルの表示（設定状態確認）]
# show nat descriptor addess all

... ＜＜＜スキャン操作の前にログをクリアする＞＞＞
# clear log

... ＜＜＜この間にスキャン操作（ping, traceroute, nmapなど）を行う＞＞＞

... ＜＜＜NATディスクリプターの変換テーブルの表示＞＞＞
# show nat descriptor addess all 

... ＜＜＜動的フィルターの管理コネクションの表示＞＞＞
# show ip connection

... ＜＜＜パケットの入出力を観測する＞＞＞
# show log

... ＜＜＜設定をファイルに保存＞＞＞
# save 0

設定の記録

設定コマンドを一通り投入したら、saveコマンドを用いて設定を保存します。上記の例では設定ファイル番号0番に保存しています。作業手順をまとめると以下のようになります。

NATディスクリプターを定義してLAN1インターフェースに適用する
NATテーブルの表示して動作状態を確認する
設定内容を確認する
設定ファイル0番に保存する

下記の画像は上記1〜4までの操作を行ったものです。

ヤマハの公開情報
ヤマハネットワーク製品技術情報ページ
→ ヤマハ vRX ユーザーガイド
→ → インターネットゲートウェイとして動作させる
→ NATディスクリプター機能
→ → NATディスクリプターの「内向きのパケットの処理」
→ コマンドリファレンス
→ → nat descriptor type
→ → nat descriptor address outer
→ → nat descriptor address inner
→ → nat descriptor masquerade incoming
→ → nat descriptor log
→ → ip lan1 nat descriptor
→ → show nat descriptor addess

pingを実行する(1)　内→外

設定ができたら、インターネット上のサーバーにpingを実行し、通信記録を確認します。作業手順を以下に示します。

clear logコマンドを実行してログを消去します。
pingコマンドでインターネット上のサーバーにpingを実行します。
pingの対象サーバーとしてホスト名を指定したので、DNSサーバーに問い合わせてホスト名の名前解決を行い、結果として出てきたIPアドレスに対してICMP echo requestを数回送信しています。
show nat descriptor addess allを実行してNATテーブルの状態を確認します。
NATテーブルにはDNSの問い合わせやpingの実行に関するNATセッション情報が記録されています。NATを行う外側IPアドレスと内側IPアドレスがあることを確認します(今回の場合は外側IPアドレスと内側IPアドレスは同一です)。
show logを実行してログを確認します。

下記の画像は実行例です。

show logの出力を見ると、以下のような通信を確認することができます。

水色で部分マスクしている箇所

vRXに設定したIPアドレスです(末尾の".19"のみ表示しています)。パケットフィルターやNAT変換などのログにおいて、発アドレスや着アドレスに頻出しています。これを見ると、NATテーブルでは外側アドレスだけでなく内側アドレスにもこのIPアドレスが設定されていることが確認できます。つまり、同じIPアドレスにIPマスカレード変換していることになります(ポート番号は変わることが多いです)。

赤色で部分マスクしている箇所

ポートスキャン元の外部ホストのIPアドレスです。全部で3件ありますが、ログの書式はいずれも以下のようになっています。これはポートスキャンがいずれもNATで破棄されていることを示しています。

LAN1 Rejected at NAT(1) : [プロトコル] 発IPアドレス.ポート番号 > 着IPアドレス.ポート番号

黄緑色で部分マスクしている箇所

vRXに設定したさくらのクラウドのDNSサーバーのIPアドレスです(末尾の".10"のみ表示しています)。DNSサーバーのIPアドレスが出てくるログは全部で10件ありますが、これらは以下の3つのパターンに分類できます。

上位DNSサーバーへの問い合わせ(2件)

ログが以下のような書式になっているものです。

LAN1 Passed at OUT(299) filter: UDP 発IPアドレス.ポート番号 > 着IPアドレス:53 (DNS Query [XXX] from 127.0.0.1)

ログのうち1件目は接続先ホスト名(www.rtpro.yamaha.co.jp)の名前解決の問い合わせです。2件目は接続先ホストのIPアドレス(XXX.XXX.XXX.XXX.in-addr.arpa)に対する逆引きの問い合わせです。

動的フィルターを通過する通信記録(3件)

ログが以下のような書式になっているものです。

[INSPECT] LAN1[out][280] [プロトコル] [発IPアドレス]:[発ポート番号] > [着IPアドレス]:[着ポート番号] ([通信を開始した時刻])

このログは動的フィルタで開放した通信ポートを閉じたことを表します。上記の例では280番の動的フィルタに合致する通信ポートを通過させるコネクションを閉じています。

IPマスカレード変換を通過する通信記録(5件)

ログが以下のような書式になっているものです。

[NAT(1): LAN1] Bound [プロトコル] 外側アドレス.外側ポート番号 <-> 内側アドレス.内側ポート番号 ==> 通信相手

濃い青色で部分マスクしている箇所

pingの宛先となっているwww.rtpro.yamamaha.co.jpのIPアドレスです(末尾の".59"のみ表示しています)。このIPアドレスが出てくるログは以下のように分類できます。

ICMP echo requestを通過させる静的パケットフィルターの記録(5件)

ログが以下のような書式になっているものです。

LAN1 Passed at OUT(299) filter: ICMP 発IPアドレス > 着IPアドレス : echo request

pingのNATセッション開始と終了に関する記録(5件)

ログが以下のような書式になっているものです。

[NAT(1):LAN1] Bound [プロトコル] 外側アドレス.外側ポート番号 <-> 内側アドレス.内側ポート番号 ==> 通信相手
[NAT(1):LAN1] Released [プロトコル] 外側アドレス.外側ポート番号 <-> 内側アドレス.内側ポート番号 ==> 通信相手

補足：NAT変換に関するログ

ログのうちNAT変換に関するものを説明します。

LAN1 Rejected at NAT(1) : [プロトコル] 発IPアドレス.ポート番号 > 着IPアドレス.ポート番号

NATテーブルで管理されていない通信なので破棄したログです。

[NAT(1):LAN1] Bound [プロトコル] 外側アドレス.外側ポート番号 <-> 内側アドレス.内側ポート番号 ==> 通信相

NATテーブルに追加してセッション管理(変換)を開始したログです。

[NAT(1):LAN1] Released [プロトコル] 外側アドレス.外側ポート番号 <-> 内側アドレス.内側ポート番号 ==> 通信相手

NATテーブルから削除してセッション管理(変換)を終了したログです。

補足：パケットフィルターに関するログ

ログのうちパケットフィルターに関するものを説明します。

LAN1 Passed at OUT(299) filter: UDP 発IPアドレス.ポート番号 > 着IPアドレス:53 (DNS Query [www.rtpro.yamaha.co.jp] from 127.0.0.1)

vRXの内部機能(ping)がwww.rtpro.yamaha.co.jpのIPアドレスを調べるために上位DNSサーバーに問い合わせる通信を静的フィルターで捕捉したログです。

LAN1 Passed at OUT(299) filter: UDP 発IPアドレス.ポート番号 > 着IPアドレス:53 (DNS Query [XXX.XXX.XXX.XXX.in-addr.arpa] from 127.0.0.1)

vRXの内部機能(ping)がXXX.XXX.XXX.XXX.in-addr.arpa(逆引きのIPアドレス表記)のホスト名を調べるために上位DNSサーバーに問い合わせる通信を静的フィルターで捕捉したログです。

LAN1 Passed at OUT(299) filter: ICMP 発IPアドレス > 着IPアドレス : echo request

vRXの内部機能(ping)がwww.rtpro.yamaha.co.jp宛てにpingのパケット(echo request)を送信したのを静的パケットフィルターで捕捉したログです。

[INSPECT] LAN1[out][280] [プロトコル] [発IPアドレス]:[発ポート番号] > [着IPアドレス]:[着ポート番号] ([通信を開始した時刻])

DNSの名前解決を行うために上位DNSサーバーに問い合わせを行う際に動的パケットフィルターを用いてセッションを開設しますが、そのセッションを閉じたログです。

pingを実行する(2)　外→内

clear logコマンドを実行して、手元のPCからvRXに向けてpingを実行します。下記の例では4回送信して4回返事がありました。

ところが、show logコマンドでログを見ると(下図参照)、外部からのポートスキャンやDHCP Discoverパケットはありますが、4回のpingの記録が見当たりません。下図には5件のログがありますが、1行ごとに説明します。

TCP 18245番ポートに対するスキャン（SRTPサーバ: Secure Real-time Transport Protocol）
TCP 6626番ポートに対するスキャン（WAGO社のサービスに関するポート）
TCP 23番ポートに対するスキャン（telnet）
UDP 67番ポートに対するブロードキャスト（DHCP Discover）
TCP 80番ポートに対するスキャン(HTTP)

このようにpingに関するログが残らないのは、パケットフィルターよりも先にNAT（IPマスカレード）が代理で返事をしてしまうからです。詳しくは後述の「pingに返事があるのになぜログに記録されないの？」を参照してください。

Nmapを実行する　外→内（Intense scan）

手元のPCからNmap(Intense Scan)を実行しました。以下はNmapの実行結果の概要です。

調査内容	結果
ping	up
SYN Stealth Scan (1000 Ports)	filtered：0 port ignored states：150 ports no-responce：850 ports
OS推定	不明（候補多数）
Traceroute	16 hops
調査所要時間	6.17 秒

show logでログを確認すると、TCP/443(https)の後、ランダムな順番でポートスキャンを行っています。1000個のポートに対するスキャンは大量のログを残していました。なお、pingは実行されているのにログには残っていませんでした。これもパケットフィルターより先にNAT（IPマスカレード）が代理で返事をしてしまうからです。詳しくは後述の「pingに返事があるのになぜログに記録されないの？」を参照してください。

vRXをシャットダウンする

検証が終わったら、検証対象のvRXをシャットダウンします。

第2回の「コントロールパネルを開く」を参考にコントロールパネルの開きます。
第2回の「vRXのシャットダウン」を参考にvRXを停止します。

パケットの流れのまとめ

パケットの通過/破棄を制御するため、「ホストの挙動」（第5回）、「IPv4フィルターの挙動」（第6回）、「NATディスクリプターの挙動」（今回）の機能を観察してきました。

第6回でセキュリティフィルターを適用した状態からスタートして、NATディスクリプター（IPマスカレード）を適用しました。もしかしたらパケットフィルターで破棄されてしまう可能性を頭がよぎったかもしれませんが、実際にはパケットフィルターより前にNATが処理されるので、パケットフィルターで破棄されることはありません。

パケットの流れ

ヤマハ仮想ルーター vRXのそれぞれの機能の適用場所は、下図のようにまとめられます。

実際に機能を組み立てる場合は、このような構造（アーキテクチャー）を理解しながら組み立てます。なお、このような構造は製品やサービスによってさまざまな考え方で実現されています。新しい製品を利用する場合はこのような検証を行って実際のところを理解していくと構築ミスを防げると思います。

IPマスカレードの挙動

IPマスカレード(NAPT)は、一つのIPアドレスを複数のIPアドレスで共有します。中→外の通信は粛々とNATテーブルに登録し、中→外も外→中もNAT変換が行われます。しかし、NATテーブルに未登録の通信をどのように処理するのかは実装に依存します。

ヤマハルーターが生まれたころは接続性が不確実な時代だったので、ホストもしくはサーバーの存在をできるだけ早く伝える必要がありました。ブロードバンドや常時接続が普及していくと今度は不正アクセスのリスクが高まり、ポートスキャンなどに対して安易に返事をしない仕様が求められました。そのようなタイミングで、IPマスカレードの動作仕様を選択できる nat descriptor masquerade incoming コマンドが追加されました。挙動の詳細はリンク先のドキュメントを見ていただきたいですが、引数に設定する値と挙動の概略を下図に掲載します。

設定値	TCP/0～1023宛てのパケット	左記以外のパケット
through	破棄してRSTを返す	変換せずに通す
reject [初期値]	破棄してRSTを返す (nmapでignored statesと判定)	破棄して何も返さない (nmapでno-responceと判定)
discard	破棄して何も返さない	破棄して何も返さない
forward	指定されたホストに転送する	指定されたホストに転送する

nat descriptor masquerade incoming コマンドの設定値

pingに返事があるのになぜログに記録されないの？

以前にも説明しましたが、pingを実行して対象先ホストから応答があっても、パケットフィルターより前にNAT（IPマスカレード）が返事をしてしまうので、pingに関する情報はログには記録されません。vRXの内部では以下のような挙動をしています。

ICMP Echo Requestに対しては無条件にICMP Echo Replyを返す
TCPやUDPに対する動作はnat descriptor masquerade incomingコマンドの設定値に従う

では、防御力を維持しながらログにしっかり記録するにはどうしたらよいでしょうか。方法はいくつか考えられますが、例えばnullインタフェースやloopbackインターフェースにルーティングするとか、パケット転送フィルターで記録ツールなど外部機器（サーバーなど）に転送するといった方法があります。また、これまでに説明したパケットの通過/破棄を制御する機能以外を使ってログを記録することもできるでしょう。ネットワークの守り方はいろいろ工夫できそうですね。遊んでみてください。

検証経費

今回検証したサーバとvRXに関する費用は次の通りです。

項目	経費
vRXを動作させる仮想マシン	起動からシャットダウンまでの稼働時間に応じた課金が発生します
vRXのアーカイブ	今回の動作確認だけなら費用は発生しません
vRXのライセンス	今回の動作確認だけなら費用は発生しません

連載トップへのリンク

連載回数番号	リンク
第1回	はじめる前に
第2回	インストールとシャットダウン
第3回	初期設定
第4回	入出力を観測
第5回	インストール状態確認
第6回	セキュリティーフィルター適用

「はじめてのさくらのクラウド版vRX」の連載一覧

※画面キャプチャーなどは、2025年2月時点のものです。

観察環境の概念図

vRXを起動する

今回の観察ポイント

NATディスクリプター機能とは

IPマスカレードを適用する

設定の記録

pingを実行する(1) 内→外

水色で部分マスクしている箇所

赤色で部分マスクしている箇所

黄緑色で部分マスクしている箇所

濃い青色で部分マスクしている箇所

補足：NAT変換に関するログ

補足：パケットフィルターに関するログ

pingを実行する(2) 外→内

Nmapを実行する 外→内（Intense scan）

vRXをシャットダウンする

パケットの流れのまとめ

パケットの流れ

IPマスカレードの挙動

pingに返事があるのになぜログに記録されないの？

関連リンク

検証経費

連載トップへのリンク

pingを実行する(1)　内→外

pingを実行する(2)　外→内

Nmapを実行する　外→内（Intense scan）