 |
| 8-2 NATの導入 その2 |
|
残念ながら、現在、筆者の環境でMN128-SOHOの導入テストができないため、筆者が知人のネットワークでの導入方法にもとづいて記述したものです。筆者なりに調べたのですが、具体的な設定で間違っている可能性があります。もし、間違っている個所があったら、「間違いの再生産を防ぐ」意味で、ごめんどうでも筆者までメールください。 NAT・IPマスカレード導入にあたって ここまでのことをまとめてみると、
というようなことになります。 ここでは、コストがかからないルータのNAT・IPマスカレード機能を使って、ネットワークのセキュリティを向上させる方法について説明します。 ルータが持っているNAT・IPマスカレード機能を導入するにあたって考えるべきことは、「DNSサーバをどう扱うか」につきるでしょう。DNSサーバでは、OCNの場合、プライマリDNSサーバは自分のサイトに置いていても、セカンダリDNSサーバがOCN側というケースも多いことと思います。ここでは、NT-BINDでセカンダリDNSサーバも構築していますが、OCN側にセカンダリDNSサーバがあるケースも配慮して説明していきます。 単純に言ってしまえば、NATにしろIPマスカレードにしろ、社内LAN側はプライベートIPアドレスの世界になってしまいます。社内LAN側のマシンとインターネット側は、ルータが相互にIPアドレスを変換することで通信ができるようになります。 ただし、ここでルータ個々で機能に違いがあり、たとえばヤマハ製のルータの場合、ルータのLAN側インタフェースにふたつのIPアドレスを持たせることができます。つまり、グローバルIPアドレスとプライベートIPアドレスのようにふたつのIPアドレスを持たせることができるため、社内LAN側にグローバルIPアドレスを持ったサーバと、プライベートIPアドレスを持ったクライアントが混在することが可能です。 また、ヤマハ製ルータの便利なのは、そのサーバ（グローバルIPアドレス）とクライアント（プライベートIPアドレス）が、ルータ経由で相互に接続できるようになっていることです。そのため、インターネット側にグローバルIPアドレス空間のネットワークセグメントを設け、そのうちの1台をゲートウェイとしてプライベートIPアドレス空間のネットワークセグメントとの橋渡しとして使う形にかなり近い状態にすることができます。 しかし、ここで最初に説明するMN128-SOHOには、この機能がありません。MN128-SOHOのNAT機能を使う場合には、MN128-SOHO自身も含めてすべてプライベートIPアドレスを社内LAN側に設けることになります。その上で、MN128-SOHOも含めてプライベート/グローバルのIPアドレス変換を行なうことになります。こうすれば、ルータと社内LAN側とが同じプライベートIPアドレスになるため、接続することができます。 IPアドレスの変換にあたっては、DNSサーバを含めて、公開するサーバにはすべて固定のプライベートIPアドレスを割り当てて、MN128-SOHOのNAT機能によってグローバルIPアドレスに1対1で変換するようにします。これに対してクライアントマシンは、サーバと同じようにプライベートIPアドレスを割り当てますが、NAT機能ではなく、IPマスカレード機能によって、ひとつのグローバルIPアドレスに変換するようにします。言うなれば、グローバルIPアドレスを共有する形にします。また、このときクライアントマシンに割り当てるプライベートIPアドレスは、管理できるもの（DHCPサーバなどを使って動的に割り当てる）である必要はありますが、かならずしも固定されたものである必要はありません。 プライベートIPアドレスに割り振り さて、NAT・IPマスカレード機能を導入する前に考えておくことがもうひとつあります。それは、プライベートIPアドレスの割り振りです。まずクラスCのプライベートIPアドレスといっても、「192.168.0.0」のネットワークから「192.168.255.0」のネットワークまで、かなり幅広くなっています。単純に「192.168.0.0」のネットワークとして「192.168.0.1」から「192.168.0.254」までの254個のIPアドレスを使ってもかまいません。実際にそうしているサイトも多いことでしょう。サブネットマスクを使って区分けしてもかまいません。 筆者の経験からいうと「192.168.1.0」のネットワークとして、「192.168.1.1」から「192.168.1.254」までのIPアドレスを利用することをお奨めします。なぜ、「192.168.0.0」にしないかというと、ネットワーク機器の多くが、デフォルトのIPアドレスを「192.168.0.1」としているケースが多いからです。そのため、購入して導入したとき、社内LANに接続すると、多くの場合、ルータに割り当てているIPアドレスとバッティングすることが多いのです。バッティングすると、その機器にあらたにIPアドレスを割り当てようと思っても、接続することができない場合がほとんどです。 「192.168.1.0」のネットワークなら、導入する機器がデフォルトで「192.168.0.1」というIPアドレスになっても、実際の機器とバッティングすることはありません。設定するクライアントマシンのIPアドレスを一時的に「192.168.0.2」などとして接続すれば、設定することができます。 ネットワーク全体でどこのIPアドレスを使うかも考えなければなりませんが、同じように、サーバやクライアントでどのIPアドレスを使うかも考えなければなりません。「192.168.1.1」はルータだとして、「192.168.1.2」がサーバAで、「192.168.1.3」がクライアントAで、「192.168.1.4」がサーバBで、「192.168.1.5」がクライアントB、などといった割り振りは、だれが考えても無理があります。管理も煩雑です。 かりに「192.168.1.0」のネットワークにするなら、「192.168.1.1」から「192.168.1.254」までの範囲があります。将来的な拡張もそうですが、管理の煩雑さを少なくすることを考えると、前半部分をサーバなどの主要機器に、中間をクライントに、後半部分をネットワークプリンタなどの機器に割り当てるのが自然でしょう。リモートアクセスするユーザがいる場合には、リモートアクセスユーザ用にどこかのブロックを確保しておいたほうがいいでしょう。 （こまかくサブネット化したり、別のクラスC、たとえば「192.168.2.0〜192.168.2.255」のネットワークを自ネットワーク内に導入することもあります。台数が多いからというだけでなく、ネットワーク上のパケットを制御して、流れをよくすることがその目的ですが、当然、スキルが要求されます。ここでは考えないことにします。） ここでは、
と、「192.168.1.2」から「192.168.1.31」までをサーバなどの主要機器に、「192.168.1.32」から適当な範囲までをクライアントに、後半を周辺機器とリモートアクセス用に割り当てることにします。 ルータにNATを設定 具体的には、次のような設定をルータにします。 （ルータの設定を変更する前に、現在の設定をファイルとして保存しておいてください。ここでは、このあとファイアウォールを導入し、バリアセグメントを設けるようになります。その際には、ルータのNAT機能は使わず、ふたたびもとの状態に戻すことになります。） まず、MN128-SOHOの「LAN側アドレス」にプライベートIPアドレス（192.168.1.1）を割り当てます。注意したいのは、「WAN側アドレス」です。ここにグローバルIPアドレス（210.160.79.97）を割り当てがちですが、ここは空欄のままとします。
ここはルーティングの設定で、とくに変更しません。
ここからが、NAT・IPマスカレードの設定です。「ip nat」がそのための設定コマンドで、NATであれ、IPマスカレードであれ、同じように「ip nat」で始めます。続いて、フィルタの設定のときと同じように数字を振っていきます。フィルタのときと同じように1から32までの32行まで指定できます。そのあとは、
というように記述していきます。この部分はフィルタリングの役目を果たしています。 この行では、ルータ自体のプライベート/グローバルIPアドレスの変換を定義しています。 以下、
までは、それぞれサーバである「192.168.1.2」への変換を定義しています。公開しているサービスを考えてポートも指定しています。 最後の
この行で、クライアントマシンのIPアドレスの変換を定義しています。変換前のIPアドレスを「192.168.1.32-192.168.1.63」というように、「192.168.1.32」から「192.168.1.63」という範囲で指定しているため、1対1のNATではなく、1対nのIPマスカレードを指定していることになります。グローバルIPアドレスは使えるものならなんでもいいのですが（もちろん、ブロードキャストアドレスはだめです）、ここでは、「210.160.79.104」を割り当てました。 クライアントへのIPマスカレードは、かならずしもひとつのIPアドレスにかぎるわけでなはく、
というように何行かにわたっても、全体として32行以内であれば、かまいません。 MN128-SOHOのNAT機能では、MN128-SOHOのハードウェア的な能力の問題さえなければ、便利な機能です。最大256セッションまで、複数台で同時接続できるようです。 続いて行なうのが、DNSサーバの設定の変更です。これまでDNSサーバにはグローバルIPアドレスで記述してきました。いまのままでも外部からのアクセスには、そのままグローバルIPアドレスの設定で応えるため問題はありませんが、社内LAN側からそのDNSサーバに問い合わせたときに問題が生じます。なぜなら社内LAN側のマシンはすべてプライベートIPアドレスが割り当てられたプライベートIPアドレスの世界だからです。単純に言えば、自分たち自身（クライアント）が、自分たちのDNSサーバにアクセスしたときに、グローバルIPアドレスで応えが返ってくるからです。 そのため、グローバルIPアドレス（たとえば210.160.79.98）のマシンを求めてパケットはいったんルータを超えて外部に出ていき（外部までは出ていかないかもしれません。ルータ内部でアドレス変換されて）、それから戻ってくるというようなみょうな事態になってしまいます。悪くするとタイムアウト（時間切れ）で、そのまま接続できなくなるでしょう。 そのため、DNSサーバの記述をグローバルIPアドレスからプライベートIPアドレスで記述しなおす必要があります。こうすることで、社内LAN側からも自分たちのDNSサーバを利用することができるようになります。外部からの問い合わせには、DNSサーバからの応えをMN128-SOHOが変換してから渡すため、内部・外部とも矛盾しません。 （ただし、このようなDNSサーバの構築は、けっしてのぞましいものとされていません。DNSサーバは本来プライベートIPアドレスで情報を持っていて、その応えがルータのNAT変換によってグローバルIPアドレスに変換されてから、外部に渡されるからです。できるなら、内向けDNSサーバと外向けDNSサーバを設けたほうがいいでしょう。） セカンダリDNSサーバが外部にあるとき ここで問題になるのが、セカンダリDNSサーバの扱いです。しかもセカンダリDNSサーバがOCN側（も含めて外部ネットワーク）にある場合が非常にめんどうです。 まず、プライマリDNSサーバとセカンダリDNSサーバの関係をもう少し理解する必要があります。セカンダリDNSサーバは、プライマリDNSサーバに障害が起こった場合はもちろん、プライマリDNSサーバが過負荷な状態になったとき、プライマリDNSサーバにかわって外部（インターネット）や内部（社内LAN OCN側にセカンダリDNSサーバがある場合は、内部とはいえず、同じように外部の扱いになりますが）からの問い合わせに答えるようになっています。たとえば、「ns.hyperdyne.co.jpというのは、IPアドレスは210.160.79.98です」とか、「www.hyperdyne.co.jpというのは、ns.hyperdyne.co.jpの別名で、IPアドレスは210.160.79.98です」というように、答えているのです。 では、なぜセカンダリDNSサーバは、「ns.hyperdyne.co.jp」のIPアドレスが「210.160.79.98」だと知っているのでしょうか。プライマリDNSサーバに関してなら、OCN敷設後に自分自身で設定したのですが、OCN側にあるセカンダリDNSはとくに設定はしていません。また、OCN側になにか申請したわけでもありません。 セカンダリDNSサーバを設定したことがあればわかるでしょうが、セカンダリDNSサーバはプライマリDNSサーバ側から情報をもらいうけるようになっています。また、それは一度きりと言うわけではなく、周期的に情報を確認するようになっています。プライマリDNSサーバの設定のときの、
がそのことに関する設定です。とくに「951213 ; serial number」のシリアルナンバーと「43200 ; refresh every 12 hours」更新のタイミングは、セカンダリDNSサーバにとっても重要で、この設定では12時間おきに、設定が変更されていないかをセカンダリDNSサーバは調べにきます。そしてシリアルナンバーを教えてもらい、もし自分が知っているシリアルナンバーよりも多いシリアルナンバーがプライマリDNSサーバから返されると、セカンダリDNSサーバがもっている情報が古いことになります。 さて、それからですが、セカンダリDNSサーバとプライマリDNSサーバとの間で、情報の更新が行なわれて、セカンダリDNSサーバは自分の持っている情報を新しいものにします。これが「ゾーン転送」と呼ばれるものです。ゾーン転送では、プライマリDNSサーバに設定した項目がそのままセカンダリDNSサーバに伝えられます。このゾーン転送に対しては、ルータは無力です。 そのため、プライマリDNSサーバの記述をプライベートIPアドレスに修正してしまうと、その設定情報がそのまま、セカンダリDNSサーバに渡されることになってしまいます。プライマリDNSサーバ、セカンダリDNSサーバとも、NATの内側（社内LAN側）にあるなら、それでもなんら問題はないのですが、セカンダリDNSサーバが外部にあると、そのセカンダリDNSサーバにプライベートIPでの設定情報がそのまま渡ってしまいます。その結果、どうなるでしょうか。 AというプライベートIPアドレスのネットワークの設定情報が、Bというネットワークに転送されたとき、「192.168.1.1」といったプライベートIPアドレスは、AではなくBというネットワークで意味を持ってしまいます。もしかりに、Bネットワークに「192.168.1.1」というIPアドレスを持ったマシンがあれば、そのマシンが該当してしまうことになります。これは非常にまずいことで、自分だけでなく、外部のネットワークに障害を発生させてしまうことになります。 こうした事態を防ぐには、プライマリDNSサーバの記述をプライベートIPアドレスのものに変更してはいけません。そのままグローバルIPアドレスで記述したものにしておきます。DNSサーバマシン自体にはプライベートIPアドレスを持たせ、DNSサーバの各種設定ファイルはグローバルIPアドレスで設定するわけです。そうしておけば、ゾーン転送でOCN側のセカンダリDNSサーバに設定情報が渡されるようなことがあっても、グローバルIPアドレスでの設定であるため、セカンダリDNS側のネットワークに障害を発生させることはありません。 しかし、先に説明したように、DNSサーバをグローバルIPアドレスで記述しておくと、自分たちのDNSサーバでありながら、自分たちで利用できないという事態になってしまいます。この問題は、もう1台、自分たち自身のDNSサーバを設けることでしか、解決しません。このサーバは、内向けDNSサーバと言い、これまでのDNSサーバは外向けDNSサーバと言います。この内向けDNSサーバには、プライベートIPアドレスで設定を記述し、また、外部に公開する必要もありませんので、ルータのNATやIPマスカレード機能の対象にする必要はありません。内部でのみ有効であればいいのです。むしろセキュリティの観点からは、外部からアクセスできないようにしておくほうがベターでしょう。 しかし、SOHOではサーバが何台あるかというのは、きわめて重要な問題です。サーバ自体への投資の問題や管理対象の台数の増加など、負担も大きいでしょう。「サーバはもう増やせない」という場合には、MN128-SOHOの簡易DNS機能を使う方法があります。これは、MN128-SOHOが簡単なDNSサーバとして機能する仕組みで、サーバが増やせないネットワーク（ただし小規模にかぎる）ではなかなか便利です。簡易DNS機能を使うときは、クライアント側にDNSサーバとしてMN128-SOHOのIPアドレスを指定します。また、AutoDNS機能をONにしないとこの簡易DNS機能は使うことができません。 筆者としては、内向けと外向けの2台のDNSサーバを用意するというのが、望ましいのではないかと思いますが、サーバを2台以上設けるのなら、ルータのNAT機能を使わず、インターネットとの間にセグメントを設けて、ファイアウォールを導入する形にしたほうが、ネットワークの構成がすっきりするし、セキュリティ面からものぞましい形ではないかと思われます。ルータのNAT機能は、コストがかからなくていいのですが、あくまで緊急避難的なものと考えたほうがいいでしょう。 現在のネットワーク状況
（注 このネットワーク状況は、ここでの解説のためのもので、筆者を取り巻いているネットワークの状況は、現在これほど単純ではありません。したがって、問い合わせをいただくのはありがたいのですが、即答しかねる場合がほとんどです。 また、セキュリティを考えれば、IPアドレスなどを架空のものにしたほうがいいのですが、経験的に言って、IPアドレスなどを架空のものにすると、知識不足の時期には、それだけで混乱してしまうことが多いでしょうから、あえてここではできるだけ実際の設定に近かったものを使って説明していきます。） （この部分追加 ここではNAT変換についてのみ説明しています。「６ ルータ（MN128-SOHO）の設定」でしたようなフィルタの設定と単純に組み合わせただけではうまくいきません。NAT変換しながらフィルタをかけるときのポイントは、グローバルIPアドレスでなく、プライベートIPアドレス側にかけることです。具体的なサンプルを公開したいのですが、現在の筆者のまわりにはそのことを試す環境がありません。機会があったら、そうします。ごめんなさい。）
|
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||||||||||||||||||||||||||
|
(C) 1998 HyperDyne Inc.
|