NAT は漠然とした概念だけ知っていましたが、細かな動きまでは理解できていなかったので、今回のメモは NAT を取り上げることにしました。 ちなみにタイトル名の 「
NAT について ■ NAT の概念
まず NAT の概念についてメモしていきます。
NAT とは Network Address Translation の略で、名前のとおりアドレスを変換する技術のことで 「アドレス変換」 と呼ばれることが多いです。 後述する 「
IP マスカレード 」 と同じ意味として使われることがありますが、厳密には動きが若干異なりますので、今回のメモでは NAT と IP マスカレードを区別します。
今このブログを閲覧して下さっている方は （ありがとうございます!!ｗ） インターネットに接続されている環境にあると思いますが、このインターネットでは
グローバル IP アドレス を使って、FC2 のブログサーバにアクセスしています。
一方、自宅内や社内などの室内、いわゆる LAN と呼ばれるスペースでは、グローバル IP アドレスの枯渇問題の関係で
プライベート IP アドレス (ローカル) を使って通信しています。 このアドレスは LAN 専用のため、インターネットで使うことはできません。
↑図1：ローカルとグローバルの関係
では、LAN に属する PC がインターネットへ接続するにはどうすればよいでしょうか。
インターネットに接続するには、LAN 専用のローカルアドレスをインターネット専用のグローバルアドレスに
変換 する必要があります。 この変換技術のことを NAT （アドレス変換） といいます。 LAN に属する PC は NAT の仕組みを使ってインターネットへ接続することができるのです。
NAT は主にインターネットとの境界線に位置するルータが行います。 この記事の1つ前に書いた iptables コマンドを用いることで Linux のサーバ機も NAT を実現できますが、やはり NAT といえばルータが一般的ですね。
■ NAT の動作
NAT で変換されたアドレスは 「
NAT テーブル 」 というキャッシュが管理します。
ルータは LAN から飛んできたインターネット宛のパケットを受け取ると、ルータが持つグローバルアドレスをそのパケットの送信元アドレスに対して書き換え、それからインターネットへパケットを投げます。 このときルータは NAT テーブルに変換したアドレスの情報を保存します。
また NAT したパケットのレスポンスに関しては、パケットを受け取ったサーバのアドレスが送信元アドレスとして指定され、宛先アドレスには NAT したアドレス、すなわちルータのアドレスが指定されます。 このレスポンスのパケットを受け取ったルータは NAT テーブルを参考に、宛先のアドレスをローカルアドレスに書き換えた上で LAN に流します。
このように NAT 技術を使うことで、LAN に属する PC がインターネットに接続できるのです。いやぁ素晴らしい。
↑図2：NAT のイメージ
ところが NAT には小さな落とし穴があります。
NAT は仕組みとして、ローカルアドレスとグローバルアドレスが 「
対（一対一） 」 でなければなりませんので、LAN に複数台のマシンがあり、それら全てのマシンをインターネットに接続させるとなると、台数に応じたグローバルアドレスを持たなければなりません。 LAN に属する PC の数だけ、グローバルアドレスが必要になるのです。
たとえば LAN に3台の PC があったとして、ルータが2つしかグローバルアドレスを持っていない場合、2台までは同時にインターネット接続が可能ですが、残りの1台はインターネットに接続できなくなってしまうのです。
↑図3：NAT する数だけグローバルアドレスが必要
LAN 専用のローカルアドレスは何個でも作れますが、グローバルアドレスは違います。 おおもとは ICANN という組織によって管理されているように有限ですし、なによりも取得するにはお金がかかります。 LAN に属する PC の数だけグローバルアドレスを取得するなど、現実的ではありません。
そこで登場するのが 「
IP マスカレード 」 です。
この IP マスカレード技術により LAN に属する複数台の PC が、1つのグローバルアドレスを共有しながらインターネット接続することが可能になります。
IP マスカレードについて ■ IP マスカレードの概念
IP マスカレードは別名 「
NAPT (Network Address
Port Translation)」 といいます。
その名を読めば 「ポートも変換されるんだな」 ということがイメージできると思います。 NAT では IP アドレスのみ変換されましたが、IP マスカレードではポート番号までもを変換することで、グローバルアドレスをうまい具合に共有する仕組みをとっています。
ポート番号 に関する説明は端折りますが、本稿では 「パケットの種類を判別する数字 (well-known port)」 だと思って頂いて差し支えなく、 「ポート 1024 以降」 に関しては、「パケット送信時に付与されるランダム数字 (ephemeral port)」 だと思って頂ければ問題ありません。 ポート番号に関しては 「
Netstat 」 コマンドを追求するときに詳細なメモを残す予定です。
↑図4：Port はアプリケーションを判別する番号
■ IP マスカレードの動作
IP マスカレードは ephemeral port が重要な意味を持ちます。
TCP/IP 通信では、新規の通信には送信元ポートがランダムで付与されます (ephemeral port)。 この ephemeral port は一時的なもので、新しいコネクションが確立されるたびに変わる性質を持っています。 このポートは数字で判別し、OS にもよりますが 1024～65535 までの数が使われます。
IP マスカレードでは、LAN から受け取ったインターネット宛のパケットのアドレスをグローバルアドレスに NAT した上で、この 1024～65535 までの ephemeral port も加えて NAPT することで、1つのグローバルアドレスで複数の新しいコネクションを開始することができます。
要するに LAN に属する PC 各々の通信が、グローバルアドレスの 「
複数あるコネクションの1つ 」 としてインターネットに通信されるイメージですね。
この仕組みを利用すれば、以下のように1個のグローバルアドレスを共有しながら LAN に属する3台のマシンが同時にインターネットに接続することができます。
1台目のマシン （PC1） が通信を行うとき、パケットの送信元アドレスには PC1 のローカルアドレスが指定され、送信元ポート番号には ephemeral port のランダム数値が指定されます。 このパケットがルータに届いたとき、NAT ではパケットの送信元アドレスがそのままグローバルアドレスに書き換わりましたが、IP マスカレードでは送信元アドレスに加えて送信元ポート番号まで書き換わります。
2台目、3台目のマシンも同様に、それぞれ送信元アドレスと送信元ポートには自らのアドレスとポートが指定され、それらパケットがルータに届くと同時に NAPT され、各々の通信がグローバルアドレスの ephemeral port （コネクション） として認識されます。
このような仕組みによって、IP マスカレードでは1つのグローバルアドレスを共有させることができます。
↑図5：IP マスカレードはポート番号レベルの変換を行う
※ 20.1.1.254 とありますが 10.1.1.254 の間違いですし。。。OTL
■ IP マスカレードの欠点
ただそんな IP マスカレードにも欠点があります。たとえば……、
1．データ内にアドレスを指定するパケットには使えない
2．ポートフォワーディングなどを使わないとインターネットから LAN へのアクセスができない
3．某掲示板サイトなどでは、身に覚えがない IP 規制に引っかかる
「1．」 「2．」 に関しては漠然と理解はできますが、深くまでは理解でいていない現状です。とくに 「1．」 に関してはいつぞやのネットワーク勉強会にて、エンジニアさんから 「
NAPT は FTP に関してはうまく動かないのです… 」 というセリフを聞いたことがあり、おそらくコレも関係していそうな気がします。 FTP には無知なので、これもまた別の機会にメモをする予定です。
「3．」 に関しては、もうお分かりですね。 IP マスカレードはグローバルアドレスを共有しますので、同じフロア内の A さんと B さんが一緒に某掲示板にアクセスしたとして、A さんが煽りまくった挙句にアクセス規制されますと、B さんも規制されてしまいます。 A さんも B さんも同じグローバルアドレスですから……ねw (^ω^*)
↑図6：これ、本気で勘弁してほしい。。。
以上が IP マスカレードの概念と仕組みです。
ここまでは NAT の理解なので 「紙とペン」 さえあればイメージは掴めると思います。 しかしインフラまわりのプロを目指すためには、このレベルで満足してはいけません。 ここはもっと
Gackt のようなストイックさ を見習いながら、アドレス変換を肌で感じなければなりません。
よって以下からは、ヤマハルータを使ったもっと低水準な目線から NAT を理解していきます。
検証環境 とてもざっくりですが、今回の検証環境は以下の通りです。
↑図7：テスト環境。小さな泣き言はスルーすべしw
※ 図7では RTX1100 の LAN インターフェースが逆になっています。 LAN1 が 10.1.1.1 になっていますが、正確には LAN1 が 192.168.0.254 であり、LAN2 が 10.1.1.1 です。 ご注意ください…。 OTL
LAN1 側には LAN 環境として 192.168.0.0/24 ネットワークを設定。
LAN2 側には Internet 環境として 10.1.1.0/29 ネットワークをそれぞれ設定しました。
NAT 動作のみを確認する場合でしたら RTX が1機とマシンが2台あれば十分だったのですが、NAT 用に確保したアドレスが枯渇したときの動作や、IP マスカレードの詳細な動きなどを確認したかったため、LAN1 側には3台のマシンを用意しました。
ただ、これら3台のマシンは Hyper-V による仮想化を行っているため、物理的なマシンは変わらず2台です。 仮想化って 「
テスト環境目的 」 としては本当に便利ですよね。
テスト環境目的！！ なら (笑)
また今回の検証にあたり、以下のサイトを参考にしました。
▼ ヤマハルータ 技術情報ページ
http://www.rtpro.yamaha.co.jp/RT/docs/nat-descriptor/
▼ YAHAMAルータ実機で学ぶ ← たぶん今後は超お世話になる (^ω^*)
http://atnetwork.info/yamaha1/nat01.html
そして、毎度のごとく本メモは 「
NAT の概念を理解 」 することを最優先にしています。
コマンドリファレンス、ヤマハルータの操作等に関しましては、豚に真珠の豚が呆れるほど
役立たない ことを保障しますので、ご理解いただけますと幸いでございますww
静的 NAT / 動的 NAT NAT はアドレス変換を行う技術であり、NAPT はポートも含めて変換する技術ですが、NAT にも種類があります。
本項では、変換の対象となるアドレスがあらかじめ決まっている 「静的 NAT」 についてメモしていきます。
■ 静的 NAT
静的 NAT は別名
スタティック NAT とも呼ばれるそうで 「
このアドレスは、このアドレスに変換されますよ 」 ということがあらかじめ決まっている種類の NAT のことです。 ちなみに 「このアドレスは、このアドレスに変換されますよ」 という動作のことを、ヤマハルータでは 「
バインド 」 と呼ぶそうです。
ではさっそく、コマンドを書いてみます。
以下は、LAN に属するマシンから WAN に属するマシンに向けて Ping を打ちますが、LAN に3台あるうちの1台 (192.168.0.1) のみ NAT させるという動きを意味しています。
ip lan1 address 192.168.0.254/24
ヤマハルータでは [ nat descriptor ] コマンドが NAT コマンドのようですね。
上記のコマンドを設定したあと、NAT したマシン (192.168.0.1) と、NAT していないマシン (192.168.0.2) をそれぞれ WAN のマシン (10.1.1.6) へ Ping したところ、問題なくレスポンスがありました。 ただし 192.168.0.1 からの通信は NAT されていますので、送信元アドレスが変わっています。
以下、WAN マシンで受信した Ping パケットを Wireshark から一部解析した画像です。 こちらを見て頂ければ、送信元アドレスが変わっていることが分かります。
↑図8：NAT されたパケットは送信元アドレスが変換される
次はポート番号の動きを確かめるために HTTP 通信を行います。
環境としては、10.1.1.6 のマシンに IIS をインストールした上で、LAN に属するマシンのブラウザから HTTP 通信を行うイメージです。 ここで注意すべきことは、HTTP 通信はポート番号 80 は宛先のポート番号であり、送信元ポート番号はエフェメラルポート (1024～65535) が自動で割り当てられることを忘れてはいけませんね。
さっそく通信したところ、192.168.0.1 のマシンは NAT テーブルに従って送信元アドレスが 10.1.1.2 に書き換えられましたが、送信元ポート番号は変化がありません。 同じく 192.168.0.2 のポート番号も書き換えは無いので、NAT が IP アドレスのみ書き換える仕組みであることがよく分かりましたね。
↑図9：ポート番号は書き換えられない
■ 動的 NAT
動的 NAT は別名
ダイナミック NAT とも呼ばれ、バインドするアドレスが決まっていない NAT を意味します。
静的 NAT は 「このアドレスは、このアドレスに変換」 とあらかじめ決まっていましたが、動的 NAT では変換するアドレスを 「範囲」 で決めます。 「
ここからここまでのアドレスは、このアドレスに変換しますよ 」 という意味ですね。
では同様に、動的 NAT のコマンドを書いてみます。
ip lan1 address 192.168.0.254/24
[ nat descriptor address outer ] では IP アドレスにハイフンを付け加えることで、範囲を指定できます。 ここでは NAT 用に2つの IP アドレスを確保しました。 NAT の内側で使われるアドレスは [ nat descriptor address inner 1 auto ] によって自動的に紐づけられます。
動的 NAT は基本的に NAT した順に確保した IP アドレスが消費されます。 俗にいう
早い者勝ち ですね。
ためしに上記 config を設定した上で Ping の通信を行います。 LAN1 に属する 192.168.0.1、192.168.0.2、192.168.0.3 の3台のマシンから順に、LAN2 側に属する 10.1.1.6 へ向けて Ping を打つ、といった検証です。
結果は、3台目のマシンのみ Ping が通りませんでした。 これは NAT する IP アドレスが枯渇したためです。 動的 NAT は前述しましたように NAT した順にプールしたアドレス （2個） を消費しますので、192.168.0.1 （1個目） と 192.168.0.2 （2個目） は NAT されましたが、192.168.0.3 のアドレスは NAT するアドレスがなくなってしまい、そのために通信が確立されなかったのです。
↑図10：動的 NAT は早い者勝ち
このように NAT は自分のアドレスを書き換えて、別ネットワークでも通信が確立できるような仕組みになっています。
ところが前述もしたように NAT は
1対1 の通信に限られてしまい、NAT する数だけ IP アドレスが必要になってしまいます。 そこで NAT する IP アドレスをポート番号レベルで共有する
IP マスカレード (NAPT) という仕組みが登場します。
IP マスカレード (NAPT) ■ IP マスカレード (HTTP)
1対1 の NAT に対し、
1対複数 のアドレス変換を行うのが IP マスカレードです。
IP マスカレードの概念は前述にメモしましたので、さっそくコマンドを書いていきます。
以下、IP マスカレードの config です。
ip lan1 address 192.168.0.254/24
※本メモでは 「IP マスカレード」 を名詞として、「NAPT」 を動詞として使い分けています。
nat descriptor コマンドで nat を指定した NAT とは違って、IP マスカレードでは masquerade を指定します。
また LAN2 側で使うアドレスは 10.1.1.2 ですので、outer に 10.1.1.2 を指定しています。
上記の config をルータに設定すると、LAN1 のネットワークに属する全てのマシンが、LAN2 の 10.1.1.6 へ通信する際には送信元 IP アドレスが 10.1.1.2 に書き換えられ、送信元ポート番号もランダムで書き換えられる動きになります。
さっそく LAN1 に属するマシン3台 (192.168.0.1-192.168.0.3) から LAN2 の 10.1.1.6 へ向けて HTTP 通信を行ったところ、以下の図11のように
全マシンの送信元ポート番号が NAPT されました。 ↑図11：左側が NAPT 前、右側が NAPT 後
NAPT 前と後を比較してみると分かりますが、ポート番号が変わっています。 こう見てみると IP マスカレード は 「ポート番号まで変換する」 という言い方よりも、「
通信可能な使っていないポート番号を借りる 」 みたいな言い方の方がしっくりくるような気がしま……せんか？ （僕だけ？）
また 192.168.0.1 と 192.168.0.2 の送信元ポート番号が 49000 番台なのに対し、192.168.0.3 の送信元ポート番号が 38000 番台である理由は
OS の違い にあります。
Windows のエフェメラルポートは IANA の提言に従って
49152～65535 のポートを使いますが、Linux の場合は iptables のメモでも書きましたように
32768～61000 (/proc/sys/net/ipv4/lo_local_port_range) の範囲が使われるため、このような送信元ポート番号に違いが出るのです。 なるほどねぇ…。
■ IP マスカレード (Ping)
ここまでくると漠然としていた IP マスカレードの動きが、だいぶ肌で感じることができました。
しかし、ここで疑問を抱くのが
Ping の動作 です。 Ping は ICMP プロトコルのためポート番号が存在せず、この原理だと IP マスカレードが使えないことになります。 ……が、いざ Ping を放り投げてみますと、なぜか返ってくるじゃありませんか!! ……なぜ？
↑図12：ポート番号レスの ICMP を NAPT。スペシャルイミフ…
このからくりは、ヤマハの技術情報ページに記載されていました。 確かに ICMP プロトコルはポート番号が存在しないので NAPT できないようですが、ICMP の
Type=0 (Echo Reply) と Type=8 (Echo) に限って はマスカレードできるようです。
iptables の --reject-with をメモしたときに、ICMP パケットを取り上げたことがありました。 ICMP パケットには Type フィールドと Code フィールドが存在し、これらフィールドに設定された数字の組み合わせで ICMP メッセージの意味を捉えることができます。 ここまではメモしました。
ところが、Echo 系の ICMP メッセージに関しては 「
Identifier （識別子） 」 というフィールドが存在するようで、IP マスカレードではこの Identifier をポート番号の代用として NAPT しているとのことでした。
↑図13：Type=0,8 の ICMP パケットフォーマット
ということは、Ping に関しては NAPT という言い方は正しくなくて、
NAIT (Network Address Identifier Translation??) という名前になるの？ といったチャチャを入れるのは後回しとして、さっそく動作を確認します。
今までと同様、192.168.0.1-192.168.0.3 のマシンから 10.1.1.6 に対して Ping を打ちます。 このとき NAPT するアドレスは 10.1.1.2 です。 その上でマシンごとに wireshark を起動させ、確認できた動作が以下の通りです。
↑図14：識別子がポート番号として使われている
ポート番号の代わりに ICMP パケットの Identifier フィールドの数値を代替しているのが分かりますね。 IP マスカレード上の Ping 動作、裏ではこんな仕組みによって実現していたのですね。 勉強になった!!!
あと余談ですが、図14 の 192.168.0.3 は Linux 機のため Identifier の数値が異なります。
それに Linux では TTL の上限が 64 （Windows では 128） だったり、Ping のデータ部が Windows より若干高かったりと、Wireshark を触っていると Linux と Windows のパケットの小さな差異に気づくことができます。 結構面白いですね。
■ ポートフォワーディング （静的 IP マスカレード）
NAT には 「静的 NAT / 動的 NAT」 の2種類があることをメモしましたが、実は IP マスカレードにも 「
静的 IP マスカレード 」 と 「
動的 IP マスカレード 」 がそれぞれ存在します。
今までメモしてきた IP マスカレードは、全て後者の動的 IP マスカレードが当てはまります。
ここでは前者の
静的 IP マスカレード について、ちょいとメモしていきます。
静的 IP マスカレードは 「
特定のポート番号に対する通信を受けた場合、特定のホストへ転送する 」 といった動きをします。 この仕組みは主に WWW サーバの公開などに使われることが多いです。
静的 IP マスカレードは別名
ポートフォワーディング などとも呼ばれます。
統一性を考えますと本メモでは静的 IP マスカレードと呼んだ方が良いのですが、ここは
あえて ポートフォワーディングと呼ばせて頂きます。 このポートフォワーディングには、ちょっとばっかし
足を引っ張られた思い出 がありますので、皮肉を込めてポートフォワーディング……と（笑）
では、以下 config を書いていきます。
ip lan1 address 192.168.0.254/24
基本的には IP マスカレードの設定と同じですが、特定のポートに対する通信を転送させる設定が追加されます。 このコマンドが [ nat descriptor masquerade static 1 1 192.168.0.1 tcp www] になりますね。
上記の config を設定した上で、10.1.1.6 のマシンのブラウザから
http://10.1.1.2 にアクセスしますと、そのパケットが 192.168.0.1 に転送されます。 192.168.0.1 には IIS がインストールされていますので、IIS のトップ画面が表示されました。
↑図15：ポートをフォワードするからポートフォワーディングw
今回は複数台の通信状況を確認したかったので、10.1.1.5 というマシンを置きました。 言わずもがなですが 10.1.1.5 のマシンは 10.1.1.6 の OS 上で稼働している VM です。 仮想化って
検証に関しては ホントに便利！！w
■ NAT セッションの限界
これらをメモしながら、個人的に 「なるほど！」 と思ったのが
NAT セッションの限界 でした。
前述の参考サイトにも書いてありましたが、IP マスカレードはポート番号が有限である以上、NAPT できるポート数にも限界があります。 IP マスカレードを使ってインターネットに接続する端末が増えれば増えるほど、共有するポート数が徐々に減っていきますので、インターネット接続に不具合が発生する可能性もあります。
これを判断する基準が、ヤマハルータでいう 「
NAT セッション数 」 のようです。
・仕事で使う機会が多い RTX3000 は、
40,000 セッション 。（もちろん中古w）
・検証で使う機会が多い RTX1100 は、
4,096 セッション 。
・部署のルータである他メーカーの NXR-130/C は、
4,096～32,768 セッション 。
と、個人的に馴染みのあるルータの仕様を確認したところ、このような情報が公開されていました。
僕は今までルータの性能を判断するときは、PPS (packet per second)、CPU 、最大帯域幅くらいしか見ていませんでしたが、こうやって見てみるとまだまだ判断材料が詰まっていそうですね。
フィルタリング動作 ■ フィルタリングが適用されるタイミング
ヤマハルータで NAT (nat descriptor) とパケットフィルタリング (ip filter) を併用するとき、意識しなければならないのが 「
処理が適用されるタイミング 」 です。
処理が適用されるタイミングとはなんぞや……と最初は (?・ω・?) ←こんな感じでしたが、これを把握しておかないと
NAT をフィルタリングしたのに NAT の通信が通る……なんで？ といった混乱を招く上、最悪セキュリティホールを作ってしまう可能性があります。 ここはしっかりと覚える必要がありそうです。
さっそくですが、以下はヤマハルータの処理の位置づけです。
↑図16：ヤマハルータの処理の適用フロー
もっと言えば、上記の処理に加えて 「
パケット・キュー 」 という処理も存在しますが、今回は ip filter と nat descriptor の関係性のみメモします。 ……ってか queue コマンドわかんないです。 (><;;)
図16 を参考に、NAT とパケットフィルタの位置づけをメモします。
以下、
LAN1 インターフェースからパケットを受信した場合 を例に挙げます。
まず LAN1 インターフェースからパケットを受信しますと、パケットは LAN1 の
NAT テーブル を通ります。 このとき NAT テーブルにマッチするバインド情報があればパケットを NAT し、何も設定していない （バインドなしの） 場合は NAT せずに NAT テーブルを抜けます。
次にパケットは LAN1 の
フィルタリングテーブル を 通ります。 LAN1 から受信したパケットなので、このとき適用されるフィルタは IN フィルタ (ip lan1 secure filter in ...) ですね。 このときパケットが reject 定義したフィルタにマッチすれば破棄されますし、マッチしなければフィルタリングテーブルを抜けて (pass)
ルーティングテーブル へ流れます。
ここが重要です。
この流れから分かるように、LAN1 インターフェースからパケットを受信した場合、
NAT の方がパケットフィルタリングよりも先に処理されます。 この概念が整理できていないと、内側アドレスをフィルタリングすべきなのに、外側アドレスをフィルタリングしてしまい、上手く動作してくれない……などといった混乱を招いてしまいます （僕は思い切りハマりました…OTL）。
では、ここで動作確認をしてみます。
ip lan1 address 192.168.0.254/24ip filter 1 reject * 10.1.1.0/29 * * *
ネットワークの構成はいつものです。 図15 あたりをご参考にお願いします。
[ ip filter 1 reject * 10.1.1.0/29 * * * ] コマンドを LAN2 の IN フィルタに設定したことで、10.1.1.0/29 ネットワークからの通信を全て破棄しています。 ただし LAN2 からの 10.1.1.2 へ向けた通信に限っては IP マスカレードが有効になってますので、ip filter 1 の定義にはマッチせずに Ping がポートフォワーディングされて 192.168.0.1 へ通りました。
↑図17：フィルタリングの前に NAT されるため、外側アドレスではマッチしない
今回はヤマハルータを例に挙げましたので、他メーカーのルータの NAT とフィルタリングの関係性 （処理の順番） はわかりませんが、とりあえずこういった概念を知っておけば応用ができると思います （たぶん）。
IP マスカレードの内向き通信 いつぞやのネットワーク勉強会にて、講師役のネットワークエンジニアさんから 「
ヤマハルータを PPTP サーバとして稼働させる 」 ための config を書いて下さりました。
当時の僕は、ヤマハルータで PPTP サーバをどうしても作らなければならない…、でも右も左もわからない…、そんな追い詰められていた状況下でしたので、この config ファイルを頂いたとき、本当に天にも昇る気持ちでした。 ただ、そんな config ファイルを今読み返してみたところ……ちょっとした
疑問 が出てきました。
それが本項の 「IP マスカレードの内向き通信」 のセキュア性に関してです。
あのとき、ネットワークエンジニアさんが書いて下さった config の一部を以下に書きます。
ip route default gateway 192.168.0.254ip filter 1 pass 10.1.1.0/24 10.1.1.3 * * *
※ 諸事情により、本項ではネットワーク構成が 「LAN1＝10.1.1.0/24」 「LAN2＝192.168.0.0/24」 と、今までとは逆の構成であり、かつ 10.1.1.0/24 とプレフィックスが変わっています。 書いている僕でさえ混乱してしまいますが、頭の運動だと思って下さいましw
上記の config は PPTP 構築部分は除き、PPTP のポートフォワーディングとインターフェースの設定がされています。
また、この PPTP サーバを置いたネットワークは、
インターネットに接続できる 「ネットワーク A (192.168.0.0/24) 」 と、
インターネットから遮断された 「ネットワーク B (10.1.1.0/24) 」 に分かれています。
ただし例外として、ネットワーク B は PPTP 通信 （リモートメンテナンス） に限ってインターネット接続を許すといった、そんな運用ルールを取っていました。 いわゆる、
PPTP サーバがファイアウォールとしても動作 しなければならない環境ですね。
↑図18：リモートメンテナンスのみ、インターネット未接続 LAN に接続できる
LAN1 (10.1.1.0/24) のフィルタリングは [ ip filter 1 pass 10.1.1.0/24 10.1.1.3 * * * ] を設定したことで、10.1.1.0/24 からはリモートメンテナンス用のマシンに対してのみ通信が可能となり、それ以外の通信は [ ip filter 999 reject * * * * * ] によって全て破棄されます （10.1.1.3 は PPTP 接続時に割り当てられるアドレス）。
しかし一方、LAN2 (192.168.0.0/24) のフィルタリングは………
なにも設定されていません。 これでは LAN2 側からの通信が確立されてしまい、セキュア性を保持できないのでは？ ――と素人ながらに思いました。ところが試しに LAN2 のマシンから LAN1 のマシンへ Ping を打ってみたところ、不思議なことに通信が確立されなかったのです。
Why!? そう頭を抱えていたとき……当時のこんな記憶がよみがえってきました。
それは勉強会を開いて下さった社長さんと、その講師役のエンジニアさんとの以下のような会話です。
社長 「これってフィルタリングされてなくない？（config を見ながら）」
講師 「大丈夫です。それは
NAT がやってくれますので 」
社長 「あ、そういやそうか」
ぼく 「？？？」
当時の僕からすれば （なにを言っているんだ、一言も理解できない……） と思っていました。
しかし、インフラまわりのプロを目指し始めた
今は違います。 人間は成長するのです!! ……ごめんなさい、前置きが長くなりましたが以下しっかりとしたメモですｗ
IP マスカレードは 「
内側 → 外側 」 の通信に関しては、空いているポート番号がある限り NAPT が可能ですが、その一方で 「
外側 → 内側 」 の通信に関しては、ポートフォワーディングなどを設定しない限り、内側アドレスの判断ができないため通信はできません。
NAT テーブルに該当しない内向きパケットを受信したときの処理に関しては [
nat descriptor masquerade incoming ] コマンドを使ってカスタマイズできます。 デフォルトでは reject ですが、特定のアドレスに転送させたり (forward)、何も手を加えずにスルーさせたりと (through)、用途によって使い分けられます。
IP マスカレードが 「
簡易的なファイアウォール 」 と言われていますが、これは意図的にではなく、
結果的に通信できない といったところが “簡易的” と呼ばれる所以である。そんな認識を持った方がよさそうですね。
↑図19：外側からの通信は簡易的なファイアウォールとして機能
ただ、僕の中ではスッキリしない疑問が残りました。
その疑問とは、ポートフォワーディングが未設定の場合は、「外側 → 内側」 の通信は内側アドレスが判断できないため通信ができませんが…… 「
じゃぁ内側アドレスを知っていたら？ 」 というところです。
普通に考えれば LAN2 インターフェースの in フィルタに対して、LAN1 ネットワークへの通信を破棄する ip filter を設定してあげればヨロシイのですが、それでも勉強会でエンジニアさんが仰った 「
NAT がやってくれますので 」 という言葉を肌で感じたかったので、ここはあえて試すことにしました。
config は前述の物を流用し、以下のような環境でテストしました。
↑図20：ip filter を設定すればすぐに解決する疑問ではありますが。。
上記の図20を見たときに……、
「secure filter in 1 998 ってなに？ 999 じゃねぇの？」
「ip lan1 address 10.1.1.0/24 ってなんだよ、10.1.1.254/24 の間違いか？」
と疑問に思った方がいらっしゃいましたら、
あなたは凄いです。 これらは完全な誤字脱字ですが、
こんな間違い誰も気づかないだろう と思ってあえて修正しておりませんのです。誤字脱字に気づくほど、こんな辺鄙なブログを読む時間を費やして下さったことを
心から感謝いたします!! それでは、以下に検証の詳細を書いていきます。
LAN2 側に属する 192.168.0.1 には IP アドレスの他にデフォルトゲートウェイを 192.168.0.253 （RTX の LAN2 アドレス） を設定しました。 この状態で LAN1 に属する 10.1.1.1 へ Ping を打ってみました。
その結果、192.168.0.1 のコマンドプロンプトからは Ping の応答がありませんでした。
しかしヤマハルータのログを確認すると、「
LAN1 Rejected at IN(999) filter: ICMP 」 といったメッセージが記録されていました。 ip filter 999 は 「通信の全破棄」 を定義していて、今回は LAN1 にそれを設定しています。 ということは、Ping request パケットではなく
Ping Reply パケットが破棄された ことになります。
Outer Address に対しての例外通信は reject されますが、それ以外のルーティングが確立されている通信に関してはやはり通信が通ってしまうようですね。 IP マスカレードのパケットフィルタリングは、
あくまで OuterAddress に対してのみのようです。 ↑図21：「行けるけど帰れない状態」 はじめてのお使いかとw
……ん、まてよ。。。と、ここでもう一つ疑問。
次は LAN2 の IP フィルタと同じように、
LAN1 側の IP フィルタを未設定にした状態 で同じ検証をしたら、どのような結果になるでしょうか？ 僕は 「
通らない 」 と予想しました。
では、同様に検証した結果を以下に書きます。
RTX に設定した Config は先ほどと同じものを使います。 ただし、3行目を [
no ip lan1 secure filter in 1 999 ] から削除しましたので、LAN1 からの通信は全て LAN2 へ通信できる状態です。 これで戻りの経路を邪魔するフィルタリングはありません。
さっそくこの状態で 192.168.0.1 から 10.1.1.1 へ向けて Ping を打ったところ……予想通りコマンドプロンプトからは Ping の
応答がありませんでした。 しかし Ping request を送信した 192.168.0.1 の Wireshark 上では、「
10.1.1.1 からの Ping Reply パケットを受信しています 」。 けれど、コマンドプロンプト上ではエラーとして認識されてしまい Ping が確立しなかった。。
↑図22：「帰れたけど追い出された状態」 帰る家を間違えた？
なぜ Ping が確立しなかったのか？
この時点でその理由がお分かりになった方は
TCP/IP をしっかり理解された素晴らしいお方です。 僕は、そんなあなたのような 「
概念の理解をないがしろにしない 」 エンジニアを目指しております。 インフラまわりのプロを目指すためにも、ここはしっかり書いていこうと思います。
ちょっとここで検証方法を変えます。
とはいっても Ping で検証していたものを 「
HTTP 通信 」 に変えるだけなので、さほど影響はないと思います。 ポートが存在しない Ping (ICMP) よりも HTTP の方がポート番号の変化も確認しやすいのです。 じゃぁ最初から HTTP でやれよ、とか言わないで下さい。。。
Config は図22で使ったものをそのまま使っています。 前述のとおり HTTP のポートフォワーディングは設定しておらず、パケットフィルタリングは [ no ip lan1 secure filter in 1 999 ] によっては全解除しておりますので、OuterAddress 以外の通信がザルの状態です。
さっそく 192.168.0.1 のブラウザ上から IIS がインストールされた 10.1.1.1 へ向けて HTTP 通信 (http://10.1.1.1) を開始します。
その結果、10.1.1.1 の Wireshark で 192.168.0.1 からの
HTTP SYN パケット の受信を確認しました。 同じく送信元の 192.168.0.1 からも HTTP SYN パケットの送信を確認しています。 ここまでは正常ですね。
↑図23：SYN パケットのやり取りは正常
次に HTTP SYN パケットを受信した 10.1.1.1 は、パケットの送信元・宛先のアドレスとポートを入れ替えて、レスポンスパケットを作成します。 このとき TCP のフラグには ACK,SYN が立ちますので
HTTP ACK,SYN パケット と呼びます。
パケットが作成されたら、10.1.1.1 は192.168.0.1 へ向けてこのパケットを送信します。
――が、ここからが問題です。
送信した HTTP ACK,SYN パケットはルータを経由して 192.168.0.1 へ届きますが、このルータの LAN2 インターフェースには
IP マスカレードが有効になっています。 本来の通信でしたら NAPT 処理時に登録されたアドレスとポートが NAT テーブルに記録されていますので、問題なく NAPT された上でパケットが送信されます。
ところが今回はポートフォワーディングされず、かつ NAPT もされなかった内向き通信のパケットに対するレスポンスパケットなので NAT テーブルに変換情報がありません。 しかし困ったことに、ルータ内のルーティングテーブルを抜けた HTTP ACK,SYN パケットは
必要のない NAPT 処理 をしてから LAN2 インターフェースを抜けてしまいます。
この HTTP ACK,SYN パケットは、宛先アドレスの 192.168.0.1 へ届きます。けれどもそのパケットの送信元アドレスと送信元ポートが、待ち受けていたアドレス情報とは全く異なってしまっています。 この不必要な NAPT 処理により、このパケットは
通信が確立できないのです。 ↑図24：“信頼性” の意味がちょっと違うけど気にしない。。
192.168.0.1 には、本来待ち受けていたパケットとは全く異なるパケットが届いてしまいました。
これは 「
我が子をお使いに行かせたら、全然違う子供が帰ってきた 」 みたいなレベルです。 そんな子を家に迎えるほど TCP は甘くありません。 そんなボランティアのような活動は
UDP にやらせておけばいいのです。 すなわち、この通信は
ボツ です。
よって 192.168.0.1 はレスポンスパケットを作成しますが、このとき TCP フラグには
RST (Reset) が立ちます。 RST パケットは接続を中断させる意味を持ちますので、このパケットを送信した時点で 192.168.0.1 のハンドシェイクは終わりを迎え、同時にパケットを受信した 10.1.1.1 も通信を終わらせます。
↑図25：RST フラグを立たせて通信の断絶
とっても長くなってしまいましたが、以上のような結果でした。
NAT はパケットフィルタの役割を担いますが、それは OuterAddress に対する通信であって、それ以外の通信に関してはフィルタリングを行う機能はないようです。
ただレスポンスのパケットには NAPT 処理が走ってしまうので、本来待ち受けていたパケットではないパケットが来てしまったことで TCP 通信が未確立に。 結果的にはフィルタリングされたことになります。
結論：IP マスカレードを設定しても IP フィルタは設定しましょう （あたりまえだw）。
最後に 今回のメモで 「最も多く入力したコマンド」 を挙げるとすれば、以下の2つだと思います。
[ cold start ]
[ shwo config ]
前者の [ cold start ] は、ルータの設定を初期化するコマンドです。
これは不慣れなコマンドを覚えるために行っています。
事あるごとにルータを初期化して、config をゼロから設定し直します。
地道な作業にはなりますが 「
体にコマンドを記憶させるため 」 にはこれが一番の近道です。
ただ 「体に記憶させる」 というのは、
決していい事ばかりではありません。 それは 「最も多く入力したコマンド」 の
後者 を見れば分かります。
その後者の [ shwo config ] ですが………
実はこんなコマンドはありません。 本当のコマンドは [
show config ] といって、これは現在ルータに設定された config を表示させるモノです。
[
shwo config ] なんてコマンドは存在しないのです。
show ← 表示する 、見せる、といった意味
shwo ← なにこれ？ バカなの？
ではなぜ [
shwo config ] と打ってしまうのか？
単純にいえば
ただのタイプミス なのですが…、
あまりにも多く、繰り返しタイプミスしてきたのでしょうね。。
今となっては、僕の体には 「
shwo config と打つ記憶 」 が染み付いてしまっています。
もう [ show config ] と打とうとすると、3回中2回は [
shwo config ] と打ってしまいます。
時すでに遅しとは、まさにこのこと。
[ show config ] と打とうとして。
[
shwo config ] と打っちゃって、、
[ BackSpace ] キーを連打して、、
…また [
shwo config ] と打っちゃって、、、
[ BackSpace ] キーをさらに強く連打して、、
…挙句の果てに [
sho w config ] なんて打っちゃった日にゃぁ――
「体で覚える」 というのも、考えようですわよ。。。 OTL
スポンサーサイト
