はじめての「ヤマハ 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マスカレードの技術文書

観察環境の概念図

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

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 typeNAT変換タイプを指定します。今回はIPマスカレードを利用します。
nat descriptor address outerNAT変換に用いる外側IPアドレスを指定します。今回はLAN1インターフェースに配布されたグローバルIPアドレスを指定します。
nat descriptor address innerNAT変換対象の内側IPアドレスを指定します。今回はすべてのIPアドレスを変換対象とします。
nat descriptor log onNAT変換に関するログを記録します。
ip lan1 nat descriptorNAT定義をインターフェースに適用します。適用すると内部にNATテーブルが準備されます。
show nat descriptor addess allNAT定義の変換テーブルを表示します。
... <<<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番に保存しています。作業手順をまとめると以下のようになります。

  1. NATディスクリプターを定義してLAN1インターフェースに適用する
  2. NATテーブルの表示して動作状態を確認する
  3. 設定内容を確認する
  4. 設定ファイル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を実行し、通信記録を確認します。作業手順を以下に示します。

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

  1. 上位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)に対する逆引きの問い合わせです。

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

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

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

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

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

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

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

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

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

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

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

LAN1 Passed at OUT(299) filter: ICMP 発IPアドレス > 着IPアドレス : echo request
  1. 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行ごとに説明します。

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

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

Nmapを実行する 外→内(Intense scan)

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

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

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

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の内部では以下のような挙動をしています。

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

関連リンク

vRXで利用できるコマンド操作に関連する公式情報です。

ヤマハの公開情報
ヤマハネットワーク製品 技術情報ページ
ヤマハ 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

検証経費

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

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

連載トップへのリンク

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

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