TCP

先日、自宅のネットワークで「インターネットに接続できない」というトラブルがありました。事象としては以下の様な感じです。 - ブラウザ等でインターネットに接続できない - nslookupでの名前解決は出来ている - ADSLルーターを再起動すると一時的に接続可能になるが、しばらくするとまた接続できなくなる - ただし、完全にインターネットへの接続が出来ないわけではなく、稀に成功することもある 嫁さんからの連絡でこの事象に気がついたのですが、良く調べてみると結局ルーターのNATテーブルがGoogle Driveによって食いつぶされているのが原因でした。 512件しか登録出来ないところを512件全て使い切ってしまっています。この状態ではきちんとNATが維持出来ずTCPコネクションが確立し続けられない事になります。 UDP1発の往復ですぐに終わるnslookupはうまく動作していたこととも整合性があります。(NATテーブルの維持時間が短くてもすぐに動作完了するので成功する) netstat –anbで利用しているポートを確認した所、googledrivesync.exeが原因でした。 とりあえずgoogle driveのプロセスを終了した所正常に通信できるようになりました。 google driveの同期先のサーバーに障害でも発生していたのでしょうか？ちょっとそこまではよくわかりませんが、とりあえず数日おいてから同期を再度開始してみたら問題は特に再現しませんでしたので、一過性のものとして判断しています。

Exchange Server 2013になり、TCPコネクション数をOutlookがより沢山使うようになっています。 これはOutlookプロファイル上でサーバー名部分がユーザーメールボックスのGUIDとなり、特定サーバーを指すものではなくなったため、同一サーバー上であっても過去バージョンにおける別サーバーであるかのようにTCPセッションを使うようになったからだそうです。Outlook Anywhereを常に使うようになったため、HTTPS通信が多数発生します。 特に他人の予定表を参照するような動作の時に個別のTCPセッションとなるため、1クライアントから数十のTCPセッションが発生し、かなりの数のコネクションが保持されるようなことが容易に起こります。 オンプレミスでは問題にならないケースも多いですが、特にExchange Onlineの場合にはProxy経由で外部に出て行くことが多いためアクセスがそこに集中し、TCPコネクション数の論理的な限界に達することや、そこまで行かなくてもProxy上の制限に合致し、まともにOutlookが使えない、Webが閲覧できない等の障害が発生することが多いようです。 オンプレミスであればきちんとシステムの変更に関してきちんと計画、テストがなされるのが普通だと思いますが、Exchange Onlineの場合には勝手にアップグレードされてしまい、障害が起きたから切り戻す…ということも行えないため場合によっては致命的な状況に陥る可能性があります。対処法がProxyサーバーを増やす、グローバルIPを増やす…というようなものになってしまう場合、対処するまでの時間も非常に長くなってしまいます。みなさんも気をつけて下さい。

VLANという技術があります。これはTCP/IPのレイヤ2に対する技術です。ある程度以上の規模のネットワークになるとVLANを使用していないネットワークはほぼ皆無になると思います。実際のネットワーク構築時には理解していることがほぼ必須になるのでよく理解しておく必要があります。自分の役割がサーバー管理者であり、ネットワーク管理者が別にいるとしても概念はきちんと抑えておかないといけません。 まず、前提知識としてレイヤ2のことを理解しておく必要があります。 - [レイヤ2 –データリンク層- 宛先はMACアドレス](https://windowsadmin.ebisuda.net/2009/02/12/%e3%83%ac%e3%82%a4%e3%83%a42-%e3%83%87%e3%83%bc%e3%82%bf%e3%83%aa%e3%83%b3%e3%82%af%e5%b1%a4-%e5%ae%9b%e5%85%88%e3%81%afmac%e3%82%a2%e3%83%89%e3%83%ac%e3%82%b9/) - [レイヤ2 -データリンク層- スイッチングハブの動作](https://windowsadmin.ebisuda.net/2009/02/18/%e3%83%ac%e3%82%a4%e3%83%a42-%e3%83%87%e3%83%bc%e3%82%bf%e3%83%aa%e3%83%b3%e3%82%af%e5%b1%a4-%e3%82%b9%e3%82%a4%e3%83%83%e3%83%81%e3%83%b3%e3%82%b0%e3%83%8f%e3%83%96%e3%81%ae%e5%8b%95%e4%bd%9c/) スイッチングハブの動作の説明で、スイッチングハブのおかげでホストが受け取るパケットは基本的に以下のものだけだ…という話をしました。 - 自分(のNIC)宛のフレーム - ブロードキャストやマルチキャストなどの明示的に届けられるもの 自分宛のフレームは受け取るのは当たり前としても、ネットワークにホスト数が非常に多くなり、ブロードキャストやマルチキャストなどが多数飛び交うようになるとやはりネットワークのパフォーマンスが悪くなってしまいます。ブロードキャストが騒がしい環境では自分は何も通信していないのにパケットキャプチャを行うと沢山のパケットが見えます。すべてのパケットを「自分宛ではない」と判断して捨てることになるのでかなりの無駄が発生してしまいます。これを避けるためにはどうすればいいか・・・？というと、スイッチを分割すれば良いことになります。 上の図のような状態を下の図のような状態に分割すればブロードキャストの届くホストの数は半分になります。 もちろん単純にこれだけだとPC1～4とPC5～8の間での通信ができなくなってしまうので、間をルーターでつないだ上で、更にネットワークアドレスをそれぞれで変更する必要が出てきます。具体的には以下のような感じです。 ルーターを使ってネットワークを分けた、という言い方でもいいかもしれません。これでお互いに通信できつつ、ブロードキャストの届く範囲(＝ブロードキャストドメイン)を分割しネットワークの混雑を緩和できます。 ですが、分割するのに、物理的にスイッチを用意して、接続を繋ぎ変えて…とやるのはさすがに面倒ですよね。なので、VLANがここで登場します。 ポートVLAN コンピューターがつながっているポート単位でVLANを設定し、同一のVLAN番号であれば同じスイッチにつながっているのと同じように設定する技術がポートVLANです。前に出てきた例をポートVLANで行うと以下のようになります。 スイッチのポートにVLAN番号を割り当てました。物理的にスイッチを分割しなくても、スイッチの設定を変更するだけで所属するセグメントを変更可能で非常に便利です。 アクセスリンクとトランクリンク さらに、VLANの仕様はIEEE802.1Qで標準化されており、複数ベンダーの複数スイッチをまたがってVLANタグの共有が可能です。例えば下図の様に複数のスイッチにまたがって自由にポート毎にVLANを割り当てることができます。 この時、それぞれのPCがつながっているスイッチのポートは単一のVLANにのみ所属していればいいわけですが、スイッチ同士をつないでいるポートに関してはそういうわけにはいかず、流れているパケットがVLAN1に所属するものなのか、VLAN2に所属するものなのかがわかるようにしないといけません。これが行えるのが「トランクリンク」で、トランクリンクではイーサネットフレームに対してVLANタグ番号を追加した「タグVLAN」方式のフレームが流れることになります。 これと区別して通常のPCが接続されるVLANを意識しない通常のフレームが流れるポートのことを「アクセスリンク」と呼びます。 ※アクセスリンクになっているポートのことを「アクセスポート」、トランクリンクになっているポートのことを「トランクポート」とも呼ぶようです。 このあたりがポートVLANの基本です。

今回は「もしかしてネットワークがおかしい?」という時のポイントの話をしようとおもいます。「もしかしておかしい?」というのは随分と曖昧な表現ですが、実際にこのような微妙な状況というのはよく起こるものです。 - 通常の処理は全部正常に出来るのだけれども、時間がかかりすぎているような感じがする。 - ほとんどの処理は正常なのだけれども、サイズの大きなファイルを扱う時だけうまくいかない。 - ネットワーク上のファイルコピーになんだかやけに長い時間がかかる・・・けど、ほおっておけば終わる。 - なんとなくネットワークを利用する処理が重い気がする。 このようなことは良くあります。よくある問題やチェックポイント等、私がいつも意識してチェックしている項目を紹介します。 SNP Windows Vista以降、ネットワーク関連で何か怪しいところがあればまず試してみるのがこの項目です。本来性能Upのためにあるものなのですけど…ね。 - [予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか? - Ask the Network & AD Support Team - Site Home - TechNet Blogs](http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx) - [［Windows 7編］ネットワーク設定を標準で使ってはいけない - ITアーキテクトの「やってはいけない」：ITpro](http://itpro.nikkeibp.co.jp/article/COLUMN/20100824/351391/) SNPの実装自体はWindows Server 2003 SP2のころからあったようですが、規定の状態で有効になったのはVista以降とのことです。時間がたち、技術が成熟することで問題は落ち着き本来の性能向上の恩恵にあずかれる…状態には残念ながらまだまだならないようです。さらにHyper-V上で複数の仮想OSが稼働するようになって問題発生時の複雑度がさらに上がっている印象です。残念ですが、とりあえず現段階では「すべて無効にする」のが得策だと思います。 得に注意したいのは「OSで設定を無効にするだけではなく、HW側の設定も無効にする」という事です。「SNP無効にしてる?」「うん。してるよ。それでもまだ問題が発生しているんだ。」というケースでも実はHW側ではまだ機能が有効で、それにより問題が引き起こされていた…ということが何度かありました。 ジャンボフレーム ジャンボフレームが原因でネットワークのトラブルが起きるケースがあります。もちろんこちらもきちんと構成すればパフォーマンスが向上するのですが…。ジャンボフレームについては以下の記事が理解しやすいと思います。 - [イーサネットを高速化するジャンボ・フレーム技術 － ＠IT](http://www.atmarkit.co.jp/fwin2k/pchard/05jumbo/05jumbo_01.html) ジャンボフレームはTCPの3ウェイ・ハンドシェイクの中でMSSとして値が渡されホスト間でパケットサイズが決定されるので、「通信するホストはどちらもジャンボフレームに対応しているんだけど、間のネットワークにはジャンボフレーム未対応のスイッチやルーターがある」というような場合にトラブルが発生します。しかも小さいサイズのパケットは普通に通るので「pingは全く問題ないんだけどな」というようなことになりがちです。 ブラックホールルーター ジャンボフレームの問題とかなり発生メカニズムや症状は似てくるのですが、発生原因が異なるのがブラックホールルーター問題。昔からときおり見かけるやっかいな存在です。 - [ブラック ホール ルーターの問題をトラブルシュートする方法](http://support.microsoft.com/kb/314825/ja) 解決手順にはセオリーがありますので上記のKBをよく読んでもらえるといいと思います。 ポート枯渇 TCPポートが枯渇することで問題が発生することもあります。TCPポートについてはレイヤ4 -トランスポート層- ポート番号をご覧ください。1つの典型的なケースとしてフロントエンド/バックエンドシステムでTCPポートが涸渇する問題への対処方法を紹介しましたが、このパターン以外でも様々なケースでポート枯渇問題に遭遇することがあります。基本的にnetstat -anコマンドにてコネクションの数を確認すればこの問題が発生しているかどうか判別することができます。集計にはPowerShellで簡単に集計する方法なども使えます。 パケットを見る 上記のどの問題も、それ以外の問題もパケットを見れば理屈上は全部わかるはずです。パケットを見るにはパケットをキャプチャする方法で紹介した方法をつかってまずパケットを取得します。 その後色々な見方がありますが、私がまずお勧めするのはwiresharkでのフィルタを使った確認方法です。 ...

このエントリでは典型的なWindowsクライアント、Windowsサーバーのトラブルシューティング時の確認ポイントやよくある問題についてまとめてみようと思います。 ログ確認 - イベントログ アプリケーション - システム - (監査)※監査ログを追う機会は比較的少ない - アプリケーションのログ デバッグモード、診断ログ的なものがあれば有効にする - 循環したり、切り捨てられるものが多いのですぐに回収する ダンプ - ダンプファイル確認 再現 - 再現性の有無を確認する - 再現手順を探す 設定差異 - 問題が発生する状況を確認する(問題発生時と未発生時) 端末 - ユーザー - OSバージョン - SPバージョン - 修正パッチ - ブラウザ(違うブラウザでの切り分け) - 導入ソフトウェア、アドオン 特にウイルス対策ソフトウェア(無効、除外による切り分け) - ログオンDC - ログオンサイト - ドメイン - ネットワーク設定 SNP - GW - DNS - NetBIOS over TCP/IP - WINS - IPv6 - コンポーネント - Windows FireWall パフォーマンス確認 - CPU - メモリ - ディスク - リーク メモリーリーク - ハンドルリーク 環境確認 - ネットワークトラフィック ブラックホールルーター問題 - SNP - ジャンボフレーム - DC複製状況 repadmin - GPO適用状況 gpresult - VSS動作状況 vssadmin list writers 問題発生時の動作確認 - ProcessMonitor - TCPコネクション状態 TCPポート枯渇 - パケットキャプチャ ...

今回はパケットをキャプチャする方法です。パケットキャプチャというとネットワークの専門家の専売特許であってネットワークのプロでないと見ても意味が分からない難しいもの…と敬遠してしまいがちですが、実はパケットを取得して中身を見る事自体はすごく簡単に行えます。最後の手段ではなく、最初の手段とすることをお勧めします。 最後の手段ではなく、最初の一手に 何かトラブルがおきた際には色々な切り分け方法がありますが、とりあえず取得する情報の１つとしてパケットの取得をお勧めします。もちろんネットワークが絡まない場合には取得の必要はないのですが、昨今のシステムでネットワークが絡まないものはほぼ無いので事実上頻繁に取得する事になると思います。 パケットを見て、そこからすべて原因を判明させるのではなく - 問題がどこにあるのかの切り分け - ネットワーク部分の問題かどうかの切り分け - 他にどこを調べるべきかの手がかり など、次につなげていくことができます。私は個人的にメールシステムのトラブルなどに対応することが多いので、文字化けの問題だろうと、滞留する問題だろうと、何でもとりあえずパケットを取得して状況を確認します。 何を使ってパケットを取得するか パケットを取得するソフトには色々ありますが、Windows 2000 ServerやWindows Server 2003の時代にはOSにNetwork Monitorが標準で付属していましたのでそれを使ってキャプチャすることが非常に多かったです。Server系だと外部のソフトウェアのインストールは禁止というお客さんが多いのですが、OSのコンポーネントの追加という形であれば許可が出やすいからです。この場合、[プログラムの追加と削除]の[Windowsコンポーネントの追加と削除]から追加する事ができました。 ですが、Windows Server 2008からはNetwork MonitorはOSには付属しなくなりました。なぜかはよく知りません(あまり興味ありません)。それでもやっぱりマイクロソフト製じゃないとServerへのインストールは許可していただけないお客様が多いので通常Network Monitorの最新版をダウンロードして持ち込み、インストールさせてもらう事が多いです。 Download: Microsoft Network Monitor 3.4 - Microsoft Download Center - Download Details 基本的なインストール方法やキャプチャの方法に関してはネット上にたくさん情報がありますので、以下のあたりを参照してもらえれば良いと思います。 Network Monitor 3 を使用したパケットの採取 - Ask the Network & AD Support Team - Site Home - TechNet Blogs また、以下は個人的なポイントです。 - Network Monitorインストール時には基本的にOS再起動は必要ない。 - [Temporary capture file] の [Size] 項目は必ず大きくしておく事。パケットを取得しているつもりでサイズの上限に達していて取得できていなかった!というのは痛すぎますので注意!! - サーバーへのインストールが許可されなかった場合にはスイッチのミラーポート設定にて別端末でパケットを取得する。この場合かならずプロミスキャスモード(自分宛のパケット以外も取得するモード)にしておかないと目的のパケットが取得できないので注意。(※昔は10MBpsのリピータハブをパケットキャプチャように常備しておいたものですが、最近ではそういうことはしなくなりましたね。) - ネットワーク上でパケットロストなども疑われる場合には１つのホスト上だけではなくて、通信相手でも同時にパケットをキャプチャし、両方を突き合わせて解析できるようにします。 キャプチャ後の解析 パケットをキャプチャした後は解析を行うのですが、この場合にはNetwork Monitorを使っても良いですが、別のものを使ってもかまいません。もちろんNetwork Monitorのファイル形式(pcap)が読める必要はあります。 ...

ここまでNAT関連で以下のエントリを書きました。 - [NAT(Network Address Translation)の基本](https://windowsadmin.ebisuda.net/2011/01/12/natnetwork-address-translation%e3%81%ae%e5%9f%ba%e6%9c%ac/) - [1対1 NAT](https://windowsadmin.ebisuda.net/2011/01/19/1%e5%af%be1-nat/) 1対1NATではシンプルに2つのIPが相互に変換される動きをみました。シンプルですが、IPアドレスが沢山必要になってしまうという欠点もありました。今回はより「よく使われているNAT」であるNAPTを見ていこうと思います。 ### ブロードバンドルータ経由で複数のPCがインターネットに同時に接続する [](https://windowsadmin.ebisuda.net/wp-content/uploads/2011/02/image6.png) 上記のような環境を考えてみます。家庭内にPCが2台あって、同時にインターネットに出るようなイメージですね。PC1,PC2が同時にWeb Serverに対してWebサイトの閲覧を行おうとしたとします。 WEBサーバーへの通信を開始するので、以下のパケットを生成します。WEBサーバーを想定していますので宛先のポート番号は80番。送信元のポート番号はランダムなポートになりますがここでは1024番にしておきます。 PC1が生成したパケット PC2が生成したパケット 上記パケットがブロードバンドルーターまで届きました。ここでNATが行われます。まず、前回解説した通り宛先IPアドレスは変更されませんし、宛先のポート番号も変更されません(Web Serverの気持ちになってみれば、これは当然です)。送信元IPアドレスはブロードバンドルーターの持っているグローバルアドレスになります(ほかにグローバルIPアドレスはありませんので)。問題はこのときの送信元ポート番号を何番にするか、ということです。どのようにすべきかちょっと考えてみてください。複数のPCが存在していることを考慮してみてくださいね。 ・・・。 ・・・。 ・・・。 考えてもらえましたでしょうか。正解は1つではないです。結局送信元のポート番号はランダムに選ばれていますので、基本的には何番でもかまわないからです。ただ、以下のことは考慮しないといけません。 - 送られてきたパケットと同じ送信元ポート番号を使うことにした場合、他のPCからも同じ送信元ポート番号のパケットが送られてきたときの考慮が必要。(同じ送信元ポート番号を使うと、どちらのPCにひもづいた通信なのかわからなくなってしまう。) - ブロードバンドルーターからも通信を開始する可能性があり、そのときの通信とも重複しないようにする必要がある。 通信が混ざる、混ざらないということに関しては、TCPのコネクションの概念を理解していないと理解できないです。このあたりの理解が難しければ、以下のエントリを参照してもらえればと思います。 - [レイヤ4 -トランスポート層- ポート番号](https://windowsadmin.ebisuda.net/2009/10/06/%e3%83%ac%e3%82%a4%e3%83%a44-%e3%83%88%e3%83%a9%e3%83%b3%e3%82%b9%e3%83%9d%e3%83%bc%e3%83%88%e5%b1%a4-%e3%83%9d%e3%83%bc%e3%83%88%e7%95%aa%e5%8f%b7/) TCP/IPでは宛先IP、宛先ポート番号、送信元IP、送信元ポート番号の4つの要素の組み合わせで通信を区別します(ソケット)。今考えている環境ではブロードバンドルーター自体と複数のPCが(インターネットへの通信に関して)同じIPアドレスを共有しているのでポート番号でしか区別できなくなっています。なので、ポート番号は(インターネットに出るときには)かならず重複しないようにしなくてはいけないわけです。 このようにポート番号まで書き換えるNATのことをNAPTといいます。 ここまで理解できれば、ブロードバンドルーター上でNATを行ったときに管理表が必須になることがわかると思います。どのパケットをどのように変換すればいいのか、という管理表です。俗にNATテーブルと呼ばれます。 NATテーブルをまで意識しながら通信の流れを見てみましょう。 プライベートIPからグローバルIPへの変換 グローバルIPからプライベートIPへの変換(戻りパケット) どうでしょうか?このようにNATの変換表に、IPとポート番号の情報まで盛り込むことで、1つのグローバルIPのみを用いて複数の端末がプライベートLANからインターネットにまでアクセスできるようになりました。 この際、NATでポート番号まで管理、変換していますのでNAPT(Network Address Port Translation)と呼ばれます。ちなみに、「IPマスカレード」という単語で呼ばれることもありますが、これはLinuxにおけるNAPTの実装の名前が「IPマスカレード」であったために、このように呼ばれるそうです。Linux上の実装は今現在はiptablesに変わっていますので、技術の名称と実装の名称は区別して呼んだ方がよい個人的には思います。 さて、これで一応NAT関連の基礎的な部分は解説を終えたことになります。ここまで理解できればあとはバリエーションの問題ですので、考えれば思いつけるようになると思います。 NATの説明の中ではレイヤ3、レイヤ4にのみ注目しましたが、それぞれレイヤ2レベルでのやり取りも説明できる状態にしておくのが重要だと思います。上記の図にレイヤ2レベルの情報を書き込めるでしょうか?難しければ以下のエントリを再度読んでみてからトライしてみてください。 - [レイヤ2 –データリンク層- 宛先はMACアドレス](https://windowsadmin.ebisuda.net/2009/02/12/%e3%83%ac%e3%82%a4%e3%83%a42-%e3%83%87%e3%83%bc%e3%82%bf%e3%83%aa%e3%83%b3%e3%82%af%e5%b1%a4-%e5%ae%9b%e5%85%88%e3%81%afmac%e3%82%a2%e3%83%89%e3%83%ac%e3%82%b9/)

今回は前回に引き続いてNATについての話です。前回の記事を読まれていない方は先によんでおいていただくことをお勧めします。 - [NAT(Network Address Translation)の基本 | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2011/01/12/natnetwork-address-translation%e3%81%ae%e5%9f%ba%e6%9c%ac/) ここまではTCPのポート番号には注目しませんでした。今回はTCPのポート番号まで意識して動きを見ていきます。 NAT 以下は前回のおさらいです。IPアドレスにだけ注目して以下のような変換が行われることを説明しました。 ここにポート番号も書き加えてみます。本当は様々なバリエーションがあるのですが、以下ではNATが書き換えるのはIPアドレスのみとします。 単純にTCPのポート番号を書き加えただけですが、大丈夫でしょうか。PC1から見た宛先サーバーのポート番号はWEBサーバーですので80番となり、ソースポートに関しては、ランダムに選ばれますが、ここでは1024番としてあります。WEBサーバーからの戻りのパケットはソースとデスティネーションのポート番号が入れ替わっています。 複数台のNAT それでは、ここでさらにPCがもう一台ある環境を考えてみましょう。 PC1とPC2が同じブロードバンドルーターの下にある状況です。 TCPでは送信元ポートはランダムに選ばれます。なので「PC1とPC2が同じサーバー(宛先IP)の同じサービス(宛先ポート番号)に同じ送信元番号をつかって接続する」ということは普通に起こりうることです。同一LAN内であればこれは以下のように区別することが可能です。 - 宛先IP：宛先ポート番号 - PC1のIP:送信元ポート番号 - 宛先IP：宛先ポート番号 - PC2のIP:送信元ポート番号 PC1のIPとPC2のIPが異なるので当たり前に区別できるのですが、これが上記の図の中で、同じWEBサーバーに対して接続をしようとし、その時の送信元ポート番号がたまたま同一で、さらにそのパケットがNATされた時にはどうなるでしょうか? 変換前パケットには送信元IPしか違いがなかったのに、それをどちらもGlobal IP Aに変換してしまっては区別がつかなくなってしまいます。これでは通信が混ざっていしまい、うまくいきません。 これを解決するにはどうしたらいいでしょうか。色々やり方はありますが、TCPポートは書き換えずに実現可能な方法を考えてみて下さい。 ・・・・・・。 ・・・・・・。 ・・・・・・。 思いついたでしょうか。正解は「ブロードバンドルータにPC1、PC2に対応するグローバルIPをそれぞれ割り当てる」ということです。以下のように、グローバルIPとプライベートIPの対応を作ってしまう訳です。 プライベートIP グローバルIP 192.168.1.1 Global IP A 192.168.1.2 Global IP C こうする事でインターネットとプライベートネットワークとで相互に通信出来ます。 1対1 NAT この様にグローバルとプライベートのIPを1対1で対応付けするNATを1対1NATと呼びます。 注目すべきは、プライベートネットワーク(PC1, PC2が存在するプライベートIPをつかった192.168.1.0/24のネットワーク)からインターネットへの通信のみならず、インターネットからプライベートネットワークへの通信もきちんと対応付ける事が可能な事です。(実際に通信させるかどうかは別問題ですが、「対応づけを矛盾なく行うことができる」ということです。) そして、グローバルIPアドレスが沢山必要になってしまう事も特徴です。 このNATはインターネット上に複数(WEB、MAIL等々)のサービスを提供するサーバーの公開の時に使われる事が多いです。グローバルIPアドレスが沢山必要になるので、一般家庭ではめったに使われない形態ではあります。 今回は1番シンプルなNATロジックである1対1NATを説明しました。次回以降はTCPのポート番号まで書き換える形態のNATを説明しようと思います。お楽しみに！

今回はNAT(Network Address Translation)について書きます。NATはほとんどのネットワークで、もっと正確にいえばネットワークの接続部分に使われているとても重要なものです。一番身近なところでは、自宅のPCのIPアドレスはプライベートIPアドレスなのに、インターネットの世界に接続できている、さらに言うと複数のPCが同時にインターネットに接続できているという方が多いのではないでしょうか。こんなことができるのはNATのおかげなんです。 NATを理解するにはIPアドレスとTCPのポート番号の理解が必ず必要ですので、まだこのあたりの理解が怪しい場合には先に以下のエントリを参照してもらえればと思います。 - レイヤ3 -ネットワーク層- IPアドレス - レイヤ4 -トランスポート層- ポート番号 NATは何をするものか NATはその名の通りアドレスを変換するものです。具体的にはパケット内のIPアドレスやTCPのポート番号を書き換えます。その書き換えパターンによって様々なバリエーションがあり、呼び方や目的が変わってきます(一部同じものもありますが)。よく耳にするのは以下のようなものです。 - 1対1NAT - NAPT(Network Address Port Translation) - IPマスカレード(IP masquerade) - DNAT(Destination NAT) - SNAT(Source NAT) それでは具体的な利用シーンを想定しながら動きを見て行きましょう。 (NAT無し)自宅PCからインターネットにアクセスする まずは理解を容易にするためにNATを使用しない状態から解説します。以下のような接続を考えます。 - PCがグローバルIPを持っている - PCからゲートウェイまで直接通信する これでなんの問題もなく世界中と通信出来る訳ですが、同時に世界中の誰からも自由にアクセスされる状態にもなっている事がポイントです。NATを考える時には「どこにアクセス出来るか」に加えて「どこからアクセスされるか」が重要になってきます。 因みに、本当にこのように「PCを直接インターネットに接続する」のは非常に危険なので行わないようにして下さい。恐らく数分で攻撃される事になります。 ブロードバンドルータ経由でインターネットに接続する 次に一般家庭でよくあるように、まずブロードバンドルータがインターネットに接続し、その下にPCを接続する構成を考えます。 また、説明のために、インターネットの向こう側にWEBサーバーがある場合を考えてみます。 - PCはプライベートIPを持っている - PCはデフォルトゲートウェイとしてブロードバンドルータを利用する - ブロードバンドルータはグローバルIPを持っている この接続は一般的なもので、PCからインターネットに接続する事ができます。 「プライベートIPはインターネット上では使用できない」ということを知っていれば、「なぜプライベートIPしか持っていないPCがインターネットにアクセスできているのか？」という疑問が出てきます。ここでNATが使われているのです。 簡単にいうと、「PCがインターネットにアクセスしようとする時に、ブロードバンドルータからのアクセスという事にする」ことでアクセスできるようにしています。 この時の動きをIPアドレスに注目してパケットレベルで詳しく見てみましょう。 まず、PCからWEBサーバーに接続要求が出されます。送信元IPアドレスは192.168.1.1, 宛先IPアドレスはGlobalIP Bになります。 このパケットはまず、デフォルトゲートウェイであるブロードバンドルーターに届けられます。ブロードバンドルーターはそのままルーティングするのではなく、送信元IPアドレスを自分自身のグローバルIPに変換して送信します。宛先IPアドレスはGlobal IP Bのまま、送信元IPアドレスはGlobal IP Aになります。 この時、パケット内のIPアドレスが書き換えられています。これこそがNATです。通常のルーターであれば、IPアドレス部分は参照するのみで書き換えることはしません。NATはIPアドレス部分を書き換える(※TCPポート番号まで書き換えるタイプのNATもあります)ここがポイントです。 それでは続きを見てみましょう。 パケットは途中いくつものルーターを経由して、WEBサーバーにまでパケットが届きます。この時WEBサーバーにしてみると、通信をしてきたのは単にブロードバンドルーターであるように見えます。PCの存在はWEBサーバーにはまったくわかりません(わかる必要もありません)。ここも1つのポイントです。NATが行われる場合実際の送信元、送信先とパケット上の送信元、送信先が異なることが多いです(NATの種類にもよります)。 ...

今回はTCP/IPのレイヤ4、トランスポート層の、「ポート番号」についての話です。IPアドレスまでは知っていても、TCPのことはよく知らないという人が多いはずです。この層より上の層ははかなりアプリケーションに依存した話になりますので、ネットワークを抑える意味ではこの層が理解の要になります。しっかり理解していきましょう。 どうやってアプリケーションを区別するのか まず、考えてもらいたいことがあります。たとえばブラウザを2つ開いているとします。1つのブラウザではyoutubeでAという動画を再生しています。もうひとつのブラウザではyoutubeでBという動画を再生しています。 さて、このとき自分のPCとyoutubeのサーバーとの間には(少なくとも)2つの通信が確立されています。この2つは「どうして混ざってしまわないのでしょうか?」。どちらも同じブラウザですし、相手も同じyoutubeのサーバーです。不思議だと思いませんか? 通信にはIPアドレスを使っているはずです。仮に自分のPCのIPアドレスをIP1、youtubeのサーバーのIPをIP2としましょう。以下の2つの通信が確立されているはずです。 - IP1 – IP2 - IP1 – IP2 うーん。どう見ても区別できませんね。これは当然のことで、「IPアドレスだけで通信の確立がなされているわけではない」のです。IPアドレスだけではなくてそのPCの中で「どのプログラムと関連づいているのか」、より正確に言うと「どのプロセスと関連づいているのか」ということが管理されているわけです。これが「ポート番号」です。 超有名なポート番号として「HTTP = 80番」というものがあります。ブラウザで接続する時にはHTTPサーバー(Webサーバー)の80番ポートに接続するわけです。 - IP1 – IP2:80 - IP1 – IP2:80 うーん。これでもまだ見分けがつかないですね。普段ポート番号はサーバー側だけが意識されることが多いですが、「クライアント側のポート番号」も意識する必要があるのです。 それでは、クライアントのポート番号は何番になるのかというと、これはもう「何番でもいい」わけです。少なくとも他とバッティングしなければ。このようにクライアント側が接続のために一時的に使用するポート番号のことをエフェメラルポートといいます。 - [エフェメラルポートとは 【ephemeral ports】 - 意味/解説/説明/定義 ： IT用語辞典](http://e-words.jp/w/E382A8E38395E382A7E383A1E383A9E383ABE3839DE383BCE38388.html) ここでは適当に1024と1025番だったとしましょう。 - IP1:1024 – IP2:80 - IP2:1025 – IP2:80 うん。これできちんとそれぞれの通信が区別できるようになりました。このようにサーバー、クライアントのIPアドレスとポート番号をつかって接続の状態を表し、これをソケットといいます。 - [ソケットとは 【socket】 - 意味/解説/説明/定義 ： IT用語辞典](http://e-words.jp/w/E382BDE382B1E38383E38388.html) このように、プログラムが通信をする際には、それぞれの動的なポート番号が割り当てられるので、混ざることが無いわけです。 繰り返しになりますが、サーバー側のポート番号だけではなく、クライアント側のポート番号も意識していきましょう。 接続の状態を確認する ここまで理解できたら、実際に自分が使っているPCの現在の接続の状態を確認してみましょう。接続を確認する方法は沢山ありますが、Windowsの標準コマンドということでいうとnetstatコマンドがあります。コマンド自体の解説は@ITに譲ろうと思います。 - [netstat - ホストのネットワーク統計や状態を確認する](http://www.atmarkit.co.jp/fnetwork/netcom/netstat/netstat.html) 私がよく使うオプションを紹介しておきます。実際に試しながら見てみてください。 netstat –an いつも何も考えずに使うのは -anオプションです。-aで接続状態に加えて、待ち受けているポートの状態を表示しています。「状態」が「LISTENING」になっているものが待ち受けているものです。いわゆるサーバーですね。 ...

今回はレイヤ3、ネットワーク層のIPアドレスのお話です。 IPアドレスはTCP/IPで通信をする際に必ず設定されるもので、よく「住所」にたとえられます。ネットワーク上の住所がIPアドレスで、ネットワーク上のデータはIPアドレスを宛先として届けられるんだよ、と。 この説明は全く間違いではないのですが、あえて言うならIPアドレスは「レイヤ3での宛先」です。すでに説明したように「レイヤ2での宛先」はMACアドレスなわけです。つまり - 同一ネットワーク内の通信であればMACアドレスが宛先となる(レイヤ2) - 別ネットワークへの通信であればIPアドレスが宛先となる(レイヤ3) というわけです。つまりIPアドレスは「宛先のホストが存在するネットワークへ送り届ける」という目的で主に使用されています。 たらいまわす IPアドレスを宛先とした通信の特徴は「たらいまわし」にすることです。例えば自分のPCのTCP/IPの設定を見てみると、基本的に以下のものしか設定しません。 - IPアドレス - サブネットマスク - デフォルトゲートウェイ 「IPアドレス」と「サブネットマスク」があれば、宛先のIPアドレスが同一ネットワークかどうかは判別がつきます(詳細はレイヤ3 -ネットワーク層- サブネットマスク参照)。しかし、それ以外に関してはどこからどのように繋がっているのかということは全く関与していません、単純に「デフォルトゲートウェイにお願いしておけば届けてくれるんでしょ?」程度の認識です。で、デフォルトゲートウェイに届けることを依頼します。 では、デフォルトゲートウェイとなっているルーターでは、宛先ネットワークを全てしっているのかというと、大抵の場合そうではありません。ルーターはいくつかのネットワークの宛先は知っていますが、「その他」に関しては特によくしらず、ルーターもさらに上位の「ゲートウェイ」に届けることを依頼します。 で、同じようなことが何段も続くわけです。たらいまわしです。「とりあえずあの人にお願いしておけば大丈夫でしょ」的な。 で、いつかは誰かがきちんと「このネットワークであればこっち」という判断をしなければいけません。これはISPのなかでも大規模なところが世界中のネットワークを理解しているルーターを管理してくれているので、そこで行われます。 そうすると今度は逆に世界の中心的な場所から末端の端末まで通信が行われるわけですが、ここではルーターはさすがに「自分が管理しているネットワーク」がどのようなものかは理解しているので、届く、というわけです。こうして世界中で繋がるわけです。

先日実際にお客さんのところで「TCPポートが涸渇する」という問題が起きたのでそのことについて書いてみようと思います。 実際のシステムはMicrosoft Dynamics CRMだったのですが、これは通常のフロントエンド/バックエンドシステムであればどのシステムでも起こりうる問題です。 フロントエンド/バックエンドシステム 「フロントエンド」、「バックエンド」という言葉が耳慣れない方もいると思うので簡単に説明しておきます。「フロントエンド」というのは実際にクライアントからの接続を受け、結果を返す役割のサーバーを指します。基本的にクライアントから見えるのはこのサーバーだけです。1台だけでは性能的にさばききれない、1台だけでは単一障害点になってしまう、というような理由から複数台配置されることが多いです。性能が足りなくなってきたらフロントエンドのサーバーの台数を単純に足してスケールアウトさせることができるというのもメリットです。 「バックエンド」というのはフロントエンドサーバーからデータの要求を受けつけ、それを返すサーバーです。フロントエンドは複数台で構成されることが多いのですが、その1台1台に実際にクライアントに応答を返すためのデータを全て保持していては、コストもかかりますし、それらをどのように更新、同期させるのかなど、色々と難しい問題が出てきてしまいます。そこで、データ自体は「バックエンド」のサーバーに持たせておき、必要なものをつど「バックエンド」から取得して、クライアントに応答する、ということにします。「バックエンド」にはデータベースサーバーが配置されることがほとんどです。また、「バックエンド」のサーバー自体も冗長化されることが多いですが、データベースサーバーを複数同時に稼動させるとデータの同期が難しいため、実際に稼動しているのは1台だけのActive-Passive構成を取る事が多いです。 フロントエンド/バックエンド構成の場合には、上記の図のようにTCP/IPのコネクションが張られます。フロントエンドの上の矢印はクライアントからの接続を意味しています。フロントエンドが複数台ある場合には、複数台に接続が分散されるように別途構成する必要があります。 Windows系のシステムでは - フロントエンドサーバーではIISが稼動 - クライアントからのHTTPの要求を受け付ける - バックエンドで稼動しているMS SQLサーバーから必要なデータを取得 - 結果のHTMLページを生成 - クライアントに返す ･･･というような処理が行われているのが一般的です。この際、フロントエンドの冗長化および負荷分散にはWindows標準のNLB(ネットワーク負荷分散)が使われ、バックエンドのMS SQLの冗長化には、Microsoft Cluster Service(フェールオーバークラスタ)が使われることが多いです。 何がおきていたのか 今回のトラブルは、フロントエンドサーバーにアクセスすると、特定のページでエラーが表示されてしまう、というトラブルでした。色々と可能性が考えられますが、結局はフロントエンドサーバーとバックエンドサーバー間のTCPコネクションに問題が発生していました。フロントエンドとバックエンド間では、SQLサーバーからのデータを取得するために、多数のコネクションが発生しています。そして今回のケースではフロントエンド側に大量にTIME_WAITのセッションが残ってしまっていて、それが原因でTCPのポートが涸渇し、バックエンドからデータを取得できない状態になってしまっていました。 TIME_WAITというのはTCPの状態を表すものです。通信の始まりから終わりまでどのようにTCPの状態が遷移するのか、ということはRFC793で定義されていて、その中のひとつです。以下の@ITの記事がこのあたりについてわかりやすく書いてあります。 - [＠IT：連載 基礎から学ぶWindowsネットワーク 第16回 信頼性のある通信を実現するTCPプロトコル（3） 2．TCPの状態遷移図](http://www.atmarkit.co.jp/fwin2k/network/baswinlan016/baswinlan016_03.html) 今回は、「フロントエンド側に大量のTIME_WAIT」「バックエンド側には特におかしな点は無い」ということでした。これはつまりフロントエンド側がアクティブクローズを行っているわけです。ですが、その量が半端な数ではありませんでした。netstat -anで確認したところ、負荷が対してかかっていない状況でも100コネクション程度はTIME_WAITが確認でき、負荷が高い時間帯では数千コネクション程度確認されました。 TCPのコネクションはいくつまで使えるのか? 数千オーダーになってくると、そもそもきちんと動くのか?と心配になるかもしれませんが、実際に今回のシステムではこのTCPのポートが涸渇してしまい、正常に接続できない状態になってしまいました。そもそもTCPのポート番号(=コネクション)はいくつまで使えるのでしょうか? 規定の状態では、Windows XPとWindows 2003では一時的なポートの範囲は1024～5000です。つまり4024個を同時に使ってしまうとそれ以上接続にいけなくなってしまいます。Windows VistaとWindows2008では49152～65535と大幅に数が増えました。 - [The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008](http://support.microsoft.com/?scid=kb%3Ben-us%3B929851&x=10&y=14) 対処方法 このようにTCPのポート番号が涸渇してしまうようなケースにはどうやって対処すればいいのでしょうか?大きく3つの方法があります。 1.アプリケーションでネットワークの扱いを変更する これが本来はいちばんいい対応方法です。TCPのコネクションを張るだけもパケットが3回も飛び交って時間がかかる(3ウェイハンドシェイク)わけですから、そんなに大量にコネクションを張らなくてはいけないくらい頻繁にデータを要求するなら、少数のTCPコネクションを張ったままにして、それをつど再利用すればいいわけです。これならポート涸渇の問題も発生しませんし、パフォーマンスすらよくなるでしょう。 ただし、もちろんこれは自分が作成しているアプリケーションならまだしも、製品であってはなかなか手がでる話ではありません。一応メーカーに文句はいいつつも、別の方法で問題を回避するより仕方が無いでしょう。 2. 一時的なポートの数を増やす 一時的なポートの数を増やすことでも対応できます。以下のレジストリの値を変更し、5000~65534までのポート番号までを使用できるようにできます。 ...

TCP/IPは現在Internetを支えるもっとも重要なプロトコルであり、Windowsでも標準のプロトコルスタックとして採用されています。Windows Server管理者としてはきちんと把握しておかなくてはいけません。 お勧めの書籍 入門書としては「マスタリングTCP/IP」がお勧めです。 マスタリングTCP/IP 入門編 第4版 竹下 隆史 村山 公保 荒井 透 苅田 幸雄 私も入社したてのころに先輩からこの本を手渡され、がんばって読み込みました。基本的な部分はこの本を読んで理解できれば抑えられます。 お勧めサイト Web上の情報としては以下のサイトもお勧めです。 3 Minutes Networking ちょっとゆるい感じなので好みが分かれるかもしれませんが、とっつきやすいと思います。私も駆け出しのころにずいぶんお世話になりました。 このサイトでも少しづつTCP/IPに関することも書いていきます。

今回はレイヤ2の話です。 レイヤ2と一口に言ってもPPPやHDLCやADCCP等多数のデータリンクプロトコルがありますが、まずはなんといってもイーサネットに関しての理解が必要です。 MACアドレス レイヤ2において色々と理解すべきことはありますが、まずは何と言っても「MACアドレス」を理解しなくてはいけません。大げさに言えば、私はMACアドレス、レイヤ2の概念をきちんと理解しているかどうかが素人とプロのまず大きな違いだと思っています。そのくらい重要です。 昨今ではTCP/IPが全盛なので、「コンピューターはIPアドレスを持っていて、IPアドレスを住所のように使って通信している」という理解をしている人が多いですし、確かにそれは間違いではありません。ですが、それはレイヤ3を考えた時の話です。レイヤ2で同じようなレベルで理解をするならば「NICはMACアドレスを持っていて、MACアドレスを住所のように使って通信している」ということになります。 「NIC」というのは「Network Interface Card」の略で「LANカード」などとも言われます。このNICに、MACアドレスというものが指定されているわけです。 MACアドレスを確認する 「IPアドレスは設定したことあるけど、MACアドレスなんて設定したことないよ?」という人も多いと思います。まずは自分が今使っているコンピューター(についているNIC)のMACアドレスを確認してみましょう。 コマンドプロンプトで「ipconfig /all」を実行してみてください。 「Physical Address. . . . . . . . . : XX-XX-XX-XX-XX-XX」という行があります。これがMACアドレスです。上の例だと「00-0F-B5-8E-0B-54」ですね。 このMACアドレスはメーカーが工場でNICを生産する際に埋め込みます。ですので基本的に私たちが設定するものではありません。(例外はありますがまずはこの理解でいいでしょう。) MACアドレスからベンダーを調べる このMACアドレスは重複しないようにメーカーごとに割り当てることができる範囲が決まっています。ですので、MACアドレスを見ればどのメーカーのNICなのかわかるようになっています。具体的にはMACアドレスの先頭24ビットがベンダーをあらわしています。具体的には以下のようなサイトで調べることができます。 IEEE Registration Authority - IEEE OUI and Company_id Assignments サイトに行って「Search the public OUI listing . . .」という項目に自分のNICのMACアドレスの先頭24ビットの値を入力して「Search!」して見ましょう。 上の例であれば「00-0F-B5」というのは「NETGEAR Inc」のNICであることがわかります。 フレームの構造 レイヤ2のレベルで考えたときには宛先、送信元にMACアドレスが入力され、Ethernetに電気信号として伝えられます。これの塊をレイヤ2では「フレーム」と呼びます。「フレーム」は以下のような構造をしています。 「プリアンブル」「タイプ」「FCS」などの理解はとりあえず後回しで大丈夫です。重要なのは「宛先MACアドレス」と「送信元MACアドレス」です。 原則としてEthernetでは全てのフレームが全てのコンピューターに届けられます。レイヤ1レベルではただの電気信号なので繋がっている全てのコンピューターまで届くわけです。NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す、という動きをします。(※例外あり、後述) どうやって通信相手のMACアドレスを知るのか では、何か通信をしたい時、送信元MACアドレスには自分が知っている自分自身のMACアドレスを入れればいいとして、宛先MACアドレスはどうしたらいいでしょうか?どうしたらわかるでしょうか? たとえばpingを考えてみましょう。「ping x.x.x.x」という形でコマンドを打つときには、宛先のipアドレスはコマンドを打つ人が入力してくれますが、このときにMACアドレスを入力するということはしません。 ですので、IPアドレスからMACアドレスを知る仕組みが必要になるわけです。NICの気持ちになって考えてみると「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という事をネットワークに流せばよさそうです。そしてMACアドレスを教えてもらう。このやり取りを**ARP(Address Resolution Protocol)**と言います。 ARPは正確にはレイヤ3に属するプロトコルなのですがレイヤ2のMACアドレスを理解するために重要なのでここで登場してもらいました。 ブロードキャスト ところで、「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という時には宛先MACアドレスには何を入れればいいでしょうか?宛先MACアドレスを知るための通信をするときの宛先MACアドレスです。 なかなか難しいですが、正解は「全員宛て」です。全員に通信を受け取ってもらって、受けとったコンピューターのうち、x.x.x.xのIPアドレスを持っているコンピューターからのみ返事をもらえればいいわけです。 このような「全員宛て」という意味で「FF-FF-FF-FF-FF-FF」というMACアドレスが使われます。先ほど「NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す」というように説明しましたが、より正確にはここで宛先MACアドレスとして「ブロードキャストアドレス(FF-FF-FF-FF-FF-FF)」やマルチキャストアドレス「01-00-5E…」であっても受け取って上位層に渡します。 MACアドレスだけではなぜいけないのか? さて、MACアドレスというものを知りました。宛先のアドレスはブロードキャスト、ARPを使って知ることができます。この仕組みだけあれば他にアドレスは必要ないようにも思います。なぜMACアドレスだけでは駄目なのでしょうか? 実際、昔Windowsネットワークで使われていたNETBEUIというプロトコルには他にアドレスは存在しません。NETBIOS名というものはつけますが、NETBEUIにおいてNETBIOS名はMACアドレスと一対一に対応付けられます。サブネットマスクだのデフォルトゲートウェイだのルーティングだの面倒なことはなにもありません。ネットワークに接続しさえすればきちんと通信できるのです。こっちのほうが楽でいいのではないでしょうか? この問いへの答えはブロードキャストのことを考えるとわかります。実際にデータを届けるには相手のMACアドレスが必要なわけですからブロードキャストするわけです。そのフレームは全コンピューターに届かなくてはいけません。これは小規模なネットワークなら問題にならないでしょう。ですが、今日最大のネットワークであるインターネットではどうでしょうか? インターネット上の全てのコンピューターの発するブロードキャストが全てのコンピューターが受信する必要があるとしたら、おそらくブロードキャストパケットだけでネットワークは飽和してしまうでしょう。 ...

今回は「NETBIOS名」と「ホスト名」について解説します。「NETBIOS名」と「ホスト名」が混ざってしまいよく理解できていない人はかなり多いです。いざという時のトラブルシュートで差が出ますのでしっかり理解しましょう。 Windowsネットワークの歴史 NETBEUIの時代 「NETBOIS名」のことをよく理解するためにはWindowsネットワークの歴史を知らなくてはいけません。 まず、今のTCP/IP全盛の時代からすると信じられないかもしれませんが、初めてWindowsにネットワーク機能が標準搭載されたWindows95では規定のプロトコルはTCP/IPでは無くてNETBEUIというものでした。そしてNETBEUIはNETBIOSというAPIを利用しています。 NETBEUIはTCP/IPとは全く異なる考え方のプロトコルです。IPアドレスなんてありません。ルーティングもしません。名前だけ決めておけばアクセスできる。そんなプロトコルです。考え方は非常にシンプルです。 このNETBIOSのAPIを利用するために「コンピューターにつける名前」が「NETBIOS名」です。 Windows95, 98の時代にはコンピューターにコンピューター名(=NETBIOS名)だけつけておいて、あとはEthernetで接続(レイヤ1で接続)だけしておいてあげれば「\コンピューター名」という形式で他のコンピューターにアクセスしてファイル共有やプリンタ共有を利用することができました。 「NETBEUI時代に使っていたコンピューター名」が「NETBIOS名」です。 NETBEUIの限界 NETBEUIは現在ではほぼ使われていません。なぜ使われていないのかというと以下の点で現在のネットワーク環境に合わなくなってしまったからです。 - ルーティング機能が無いため大規模なネットワークには向かない - インターネットが普及し、NETBEUIとの相互接続性に問題がある 95, 98の時にはファイルやプリンタの共有のためにはNETBEUIプロトコルを使って、インターネット接続にはTCP/IPを使って･･･と、複数のプロトコルスタックを使うようなこともありました。今では用途別に複数のプロトコルスタックを使い分けるということはもうほぼありません。 TCP/IPへの移行 Windowsネットワークもインターネット普及の流れに乗るためにTCP/IPを標準のプロトコルに採用します。時代の流れです。ですが、単純にTCP/IPに移行してしまうと今まで使っていたNETBIEUI+NETBIOSのAPIをつかったWindowsファイル共有やプリンタ共有が使えなくなってしまいますし、Windowsネットワークの特徴であった「とりあえず名前だけ決めておけば繋がる」という利点が失われてしまいます。 そこでマイクロソフトがとったのはTCP/IPの上でNETBIOSのAPIを使えるようにする、という戦略です。これをNETBIOS over TCP/IPといいます。TCP/IP上でNETBOISを使えるようにしたわけです。これにより、NETBIOSのアプリケーションそのままに、TCP/IPを使って複数セグメントに分かれた大規模なネットワークにも対応可能になりました。 このNETBIOS over TCP/IPの機能があるため、何も設定していない状態で「ping コンピューター名」に応答が返ってくるわけです。 複数セグメントになったことで起きる問題 NETBIOS over TCP/IPによって複数セグメントに対応し、大規模なネットワークに対応できるようになりました。ですが、もともとNETBEUIは「ブロードキャスト」を多様することで簡単に接続できるようになっていたため、複数セグメントに分かれてしまうとNETBIOSのAPIがきちんとネットワーク全体で使えない、という問題が出てきてしまいます。 この問題を解決するために、セグメントを越えるために、出てきた技術がWINSです。各コンピューターがNETBIOS名とIPアドレスの対応付けをWINSサーバーに登録しておき、利用したい場合にはWINSサーバーに問い合わせることで、セグメントを越えることができるようになりました。 また、lmhostsファイルというファイルにもNETBIOS名とIPアドレスの対応付けを書くことができるようになっています。 WINSサーバーを使うかlmhostsファイルにそれぞれ記述することでセグメントを越えることが出来るようになっています。 NETBIOS名 ここまで見てきたようにNETBIOS名というのはもともとTCP/IPとは別のNETBEUIというプロトコルスタック上で使われていた名前です。WindowsがNETBEUIからTCP/IPに乗り換える際に、過去の遺産を持ってきた、そういう構造になっています。ですからはじめからプロトコルスタックにTCP/IPを採用していたUNIX系のOSではNETBIOS名という考え方は存在しません。 基本的には自分のNETBIOS名をコンピューターは知っていて、それが(ブロードキャストで)呼ばれたら変事をするような仕組みになっています。 UNIX系ネットワーク(TCP/IP)の歴史 hostsファイル TCP/IPでは他のコンピューターと通信する際にはIPアドレスを利用します。 IPアドレスを人間が全て記憶することは難しいため、hostsファイルにIPアドレスとそれにつけるコンピューターの名前(=ホスト名)を記述し、管理していました。全てのコンピューターにhostsファイルを記述する、というのがもっとも原始的な形態です。 個別のhostsファイルにホスト名とIPアドレスの対応付けを全て記述していたのでは、ネットワークにコンピュータが1台増えただけで、既存のコンピューター上の全てのhostsファイルを更新して回る必要が発生してしまいます。同じようにIPアドレスを変更したい、ホスト名を変更したいと思った場合も同様です。 このようにhostsファイルだけでは小規模なネットワークならともかく、大規模なネットワークでは事実上管理できません。 DNS hostsファイルの問題を解決する仕組みとして考え出されたのがDNSです。クライアントはDNSサーバーに問い合わせて、ホスト名とIPアドレスの変換を行います。 ただし、この際に単純にhostsファイルに記載されていたものをDNSサーバー上に登録しただけでは何百、何千、何万というレコードを1台のサーバーで管理しなくてはいけなくなります。DNSはインターネット上でも使われていますが、インターネット上のホストとなると何百万、何千万、何億という単位です。これを1台で全て管理したり、冗長化のために複数台にコピーしたり、というのはかなり効率が悪いです。 さらにもしかしたら全く同じ名前を持っているホストが存在しているかもしれません。この場合どちらかのレコードのみを登録するわけにもいきませんのでどちらかの名前を変更しなくてはいけなくなってしまいます。 そこでDNSには、このような問題を解決するためのしくみとして、「ドメイン」という概念が導入されています。「ドメイン」ごとにレコードを管理し、ホスト名のあとにドメイン名までつけて1つのホストを表します。たとえばこのブログが稼動しているサーバーはdyndns.bizというドメイン上のebiというホストです。ebi.dyndns.biz.というのが完全修飾ドメイン名(FQDN)になります。(※完全修飾ホスト名とは言わずに、完全修飾ドメイン名といいます。) ちなみにWINSにはこのような「ドメイン」という考え方は存在しませんので上記の問題をそのまま抱えています。ですので、マイクロソフトもWINSには見切りをつけていて、廃止の方向に向かっています。 ホスト名 見てきたように「ホスト名」はhostsファイルおよびDNSにて管理され、ドメインという概念を含んだものです。 NETBIOS名とは異なり、自分のホスト名に対してそのIPアドレスを返答するような仕組みは備わっていません。 Active DirectoryでDNSを導入 マイクロソフトはWindows2000でActive DirectoryというWindowsネットワークを管理する新しい仕組みを導入し、その中で名前解決の仕組みにDNSを導入します。ここから本格的にWindowsネットワークでもTCP/IP+DNSという仕組みを採用したわけです。 ですが、過去の資産を継承するためにNETBIOSの仕組みも存続させます。NETBIOS over TCP/IPも搭載していますし、NETBIOS名の名前解決の仕組みとしてWINSも健在です。 このようにして、WindowsネットワークはNETBIOS名とホスト名が混在するややこしい状態になりました。 ポイント - lmhostsファイルとhostsファイル、WINSとDNSとが技術的には対応付けられる。ただし、その技術が必要となってきた経緯は異なる。 - ホスト名はTCP/IP,Unixの文化から来ている。 - NETBIOS名はNETBEUI(プロトコルスタック)+NETBIOS(API)という過去の技術を継承しているために残っている。TCP/IPへとプロトコルスタックを変更する際にNETBIOS over TCP/IPという技術が導入され、これによりTCP/IPネットワーク上でNETBIOS(API)が利用できる。 - NETBIOS名とホスト名が混在しているのはWindowsネットワークだけ。 参考 - [Insider's Computer Dictionary [NetBEUI] － ＠IT](http://www.atmarkit.co.jp/icd/root/14/5787514.html) - [DNSの仕組みの基本を理解しよう](http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html) - [＠IT：基礎から学ぶWindowsネットワーク](http://www.atmarkit.co.jp/fwin2k/serial/index/index.html#baswinlan)

「インターネットに繋がらない」 - 初級編では直接、インターネットに接続されている環境での処理の流れを見てもらいました。今度は別のバリエーションとして、直接はインターネットに接続されておらず、Proxyを経由してインターネット上のWebサイトを閲覧するようなケースを考えてみます。 一般家庭でProxyを利用しているようなケースは極稀でしょうけれども、企業では様々な理由からProxyを利用しないとWebサイトの閲覧ができないように構成していることもあります。特にセキュリティに気を使っている企業ではProxyの利用は当たり前です。あとは、サイトを閲覧する際に実IPを隠すためにあえてProxyを利用するようなケースもあるかとは思いますが今回はそのあたりに関しては扱いません。例の如く別エントリにて解説予定です…。 Proxy接続の場合には通常の直接インターネットへ接続(Webサイトの閲覧)をする場合と比較すると以下のようなプロセスの違いがあります。 直接 Proxy経由 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 5．DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 6．該当のWeb Serverに接続する 7．Web Serverからコンテンツを得る 8．ブラウザにコンテンツを表示する 5．Proxyサーバーに接続する 6．Proxyサーバーからコンテンツを得る 7．ブラウザにコンテンツを表示する 大きな違いは以下の2点です。 DNSを使用した”名前解決”を実行しない(必要ない) 接続するのは常にProxyサーバー Proxyサーバーを利用する場合には、Proxyサーバーに実際のコンテンツの取得をお願いする形になります。つまりProxyサーバーは「直接」の場合の5,6,7の動作を行い、その結果をPCに渡してくれるわけです。 トラブルシュートの方法 トラブルシュートとしては、Proxyサーバーの設定およびProxyサーバーへの接続があります。 Internet Explorerの場合には「ツール」→「インターネットオプション」→「接続」タブ→「LANの設定」からProxyの設定を行います。 Proxyへの接続がきちんとできているかを確かめるには、「telnet Proxyサーバー ポート番号」を実行するとよいでしょう。コマンドを実行して、画面が真っ暗になれば接続できています。 「ローカルアドレスにはプロキシサーバーを使用しない」の意味 Proxy環境の場合によく問題になるのは「ローカルアドレス」という言葉の意味です。普通に「ローカルアドレス」と聞くと同一セグメントのIPアドレスなり、プライベートアドレスなりといったものを連想すると思いますが、これはそういう意味ではなくて「名前に.(ドット)が含まれていないもの」という意味になっています。通常WindowsネットワークではPC名のみで近くのサーバーへの接続(名前解決)ができるため、このような判断基準になっているのだろうと思います。 具体例をあげましょう。Proxyサーバーを利用し、かつ「ローカルアドレスにはプロキシサーバーを使用しない」のチェックが入っているとします。 pcname(ホスト名) pcname.test.local(FQDN) 192.168.1.1 上記の3つが全く同じホストを指している場合、1はホストに対して直接のアクセス、2と3はProxyサーバー経由のアクセスということになります。単純に.(ドット)が含まれているかどうかが判断基準です。 よく2や3の場合でも同じサブネットなんだからProxyサーバー経由ではなく直接接続してくれると勘違いしてしまうケースがあるので、きをつけてください。 2や3の入力方法でも直接接続させたい場合には除外設定を行えばよいです。 そもそもProxy接続をしなければいけないことをどのように知るのか Proxy接続が必要な環境であること自体を知る、あるいは直接接続はできないと判断するにはどうすればいいでしょうか。これはDNSの確認とHTTPポートでの接続の可否で判断できます。 外部のホスト名の名前解決ができるか まず、DNSに関して。DHCPなり固定IPなりできちんとしたDNSを割り振られていることを前提とします。この状態でnslookupにて外部ホストの名前解決ができるかどうかを確認します。 上記のように名前解決ができるようであれば、自らWebサイトへの接続が試行できるので、Proxyは必要ない環境の可能性が高いです。逆にここで名前解決ができないようであればProxyが必須の環境であるということがわかります。あるいは完全にインターネット上のホストへのアクセスができないか、です。 外部のホストに接続できるか 名前解決ができる環境であれば直接Webサイトへの試行を行うことができます。Webサーバーへの接続はtelnetでHTTPポートへの接続で試すことができます。 名前解決ができても外部ホストに接続できない場合や逆に名前解決ができなくても外部ホストに接続ができる場合などもあり得ます。ですが基本的には両方うまくいかなければProxy接続が必要な環境だ、ということがいえます。 Proxyの設定に関する注意点 ちなみにWindows上のアプリケーションの場合にはインターネットアクセスの際にIEのProxyの設定を参照するものも結構あるので注意が必要です。特に規定のブラウザをIE以外のブラウザに変更しているときには注意が必要です。IEのProxy設定にも設定を入れておきましょう。 また、サービスで動作しているプロセスがProxy設定を必要とするケースがあります。この場合には該当アカウントのプロファイル上でIEのProxy設定を行う必要があるものもあるので注意が必要です。 さらに、IEのProxyを見ないでWinHTTPの設定を見るアプリケーションもあります。さらにはIEでアクセスするくせにWinHTTPの設定を見るようなものも存在していますので(Microsoft Update等)、proxycfgコマンドでの設定が必要なケースもあります。このあたりには注意が必要です。 参考：How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site ...

「インターネットに繋がらない！」という発言をよく聞きます。テクノロジーを理解していないお客さんならともかく、プロとしてはこのような発言はしたくないものです。「インターネットに繋がらない」時には具体的にどのようなことが原因として考えられるのか考えてみます。 ※ここでは「インターネットに繋がる」という言葉の正確さに関しては議論しないことにします。 大まかな流れとその確認確認ポイント 通常お客さんが「インターネットに繋がらない」と言ったときにはブラウザでWeb上のコンテンツを表示できなくなったときでしょうから、そのときの大まかな流れを見てみます。 PCが起動する 有線または無線にてEthernetに接続する 固定またはDHCPにてTCP/IPの設定がなされる ブラウザにてURLが指定される DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 該当のWeb Serverに接続する Web Serverからコンテンツを得る ブラウザにコンテンツを表示する これはかなり大まかな流れであって、実際にはまだまだいくらでも細かく処理を記述することが可能ですが、最低この程度の粒度では事象を抑えてもらいたいです。 このレベルでの確認ポイントは以下です。 きちんとケーブルが刺さっているか IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 該当のWeb Serverに接続できているか コンテンツを得られるか それぞれ確認方法を紹介してみましょう。 きちんとケーブルが刺さっているか これはどうやって確認すればいいかというと････。目で見て確認してください(笑)。でも、せっかくなのでコマンドで確認する方法も紹介しましょう。 このように「ipconfig」というコマンドを使うとネットワークの状態を見ることができます。今、上の図ではきちんとIPアドレス等が表示されているので、この状態であれば「ケーブルがきちんと刺さっている」と言うことがわかります。ケーブルがきちんと刺さっていない場合にはここには「media disconnected」と表示されます。このように表示された場合にはケーブルが刺さっていない状態ですので、ケーブルの確認をしてください。 IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか ケーブルが刺さっていることを確認したら次はIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等のTCP/IPの設定がきちんとなされているかを確認します。これも先ほどと同じく「ipconfig」コマンドで確認できるのですが、「ipconfig」コマンドだけではDNSの設定が確認できないので「ipconfig /all」コマンドを実行することで確認します。 ここできちんとIPアドレス(IP Address)、サブネットマスク(Subnet Mask)、デフォルトゲートウェイ(Default Gateway)、DNS(DNS Servers)が設定されていることを確認します。 ここでこれらのパラメータを自分で設定している人(固定的に設定している人)と自動的に設定している人とで若干確認、修正方法が異なります。 固定になっているのか、自動になっているのかの判別は上記コマンド結果の「Dhcp Enabled」の部分がYesになっているかNoになっているかでわかります。上記のサンプルではDHCPが有効になっていて、DHCPサーバー(192.168.1.254)からTCP/IPの設定を自動取得していることがわかります。 固定で設定している場合には「インターネットプロトコル(TCP/IP)」のプロパティから手動で値を設定、修正します。 自動になっている場合にはDHCPサーバーがきちんと稼動して、正しい設定を配布してくれている必要があります。自動的に取得する設定になっているにもかかわらず「169.254.x.x」、あるいは「0.0.0.0｣というアドレスになっている場合には正常にDHCPサーバーから設定を取得できていない状態です。DHCPサーバーの正常動作を確認するか、あるいは固定で設定してしまうかなどの対応が必要です。 参考：APIPA - Wikipedia そもそもどんな値を設定すればいいのか、設定されていればいいのかわからない人はTCP/IPの基礎を勉強しなくてはいけないですね。後日書く予定です。 ここまでの設定の確認としては、「デフォルトゲートウェイまでのpingが通ることを確認する」という方法が有効です。 「ping デフォルトゲートウェイのIPアドレス」を実行して、Pingに対してReplyがあることを確認しましょう。 DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 次にDNSでの名前解決がきちんとなされているかの確認方法です。「nslookup」というコマンドをつかって「nslookup ホスト名」とすることで調べられます。「ホスト名」というのはURLのうち下の例で言うとxxxx.xxx.xxの部分です。 「http://xxxx.xxx.xx/yyy/xxx/」 http://の直後からはじめの「/」の前までの部分ですね。 このようにホスト名からIPアドレスへの変換がうまくいっている必要があります。そもそもここでスペルミスなどをすると以下のように答えが返ってきません。 ここがうまくいかない場合には以下の2つの可能性があります。 TCP/IPの設定でDNSの設定を間違えている(正しいDNSサーバーを利用していない) 接続しようとしている先のサイトの情報を保持しているDNSサーバーに障害が起きている どちらなのかを判断するためには、その他のホスト名の名前解決ができるかどうかを調べましょう。私はいつも「www.google.com」が解決できるかどうか試しています。 ここまでのこと(ケーブル、TCP/IP設定、DNS)を一度に試す方法があります。それは「ping www.google.com」を実行することです。 ケーブルが繋がっていなければPingに応答があるわけはありませんし、TCP/IPの設定がただしいからgoogleのサーバーまで通信できています。また、www.google.comをDNSをつかってIPアドレスに変換できているからPingが打てているのです。www.google.comのホストはきちんとpingのReplyを返してくれるので確認が取れるわけです。 該当のWeb Serverに接続できているか ここまでの確認でクライアント側のTCP/IPおよびDNSの設定は問題ないことがわかりました。もう少し上の層に視点を切り替えていきます。まずは、該当のWeb Serverに接続できているかどうかです。 ...

この層はイメージすることが難しいネットワークの層の中では比較的イメージしやすい層かもしれません。なぜなら目に見える(ものもある)ので。具体的には以下のようなものがレイヤー1に対応するものとして存在しています。 ネットワークケーブル リピータハブ モデム 一番具体的にイメージしやすいのはネットワークケーブルだと思います。ネットワークケーブルを使ってコンピューターとコンピューター(や、HUBなど)を接続すると、情報がやり取りできるようになります。Windowsでいえばファイルもコピーできますし、きちんと構成してあげればInternet経由で世界中のサーバーからWebページ、音楽、動画なども取得することができます。 このとき、ネットワークケーブルの中では何が起きているのでしょうか?色々なものが通るのだからものすごく複雑なものが、得体のしれないものが通っているのでしょうか? 実は非常に複雑･･･ではなく、ものすごくシンプルです。基本的に電気信号が通るだけです。しかも電圧が高い、電圧が低いの2パターンしかありません。2パターンしかないのだから、言ってしまえば人間が手で旗を上げている、下げている、ということと同じことしかやっていません。 2パターンしかないのに、PCで使える全てのもの(文字、画像、音声、動画、プログラム、その他なんでも)を全て伝えられるのは何でだろう?と思うかもしれませんが、それこそが「デジタル」のすばらしいところです。この部分に関して突っ込んでいくと今回のエントリの目的からどんどん離れていってしまいますので、そこにかんしては後日別エントリでまとめたいと思います。 さて、本題に戻ります。ネットワークケーブルはただ単に電気信号を通しているだけ、という話でした。リピータハブに関しても同じです。リピータハブは入力があった電気信号を他のすべてのポートに対して電気信号として流す、ということをやっているだけです。モデムは電気信号を電話回線に対して「ガガガ」と音声に変換して流したり、その逆をしたりしているだけです。 つまりレイヤー1に属するものたちは何も考えずに電気信号なり、音声なりを流す、あるいは変換して流す、というただそれだけだということです。そしてその信号を「デジタル信号」として上位の層(レイヤー2)に渡します。 OSI参照モデルを思い出してほしいのですが、OSI参照モデルではそれぞれの層が独立しているのがポイントです。一昔前までは物理層として物理的なケーブルしかありませんでしたが、今は無線LANのように電波をつかって通信するものがあります。ですが、有線だろうが無線だろうがきちんとTCP/IPで通信できるわけです。新しいテクノロジが出てきても関連する層でのみ対応を行えばよく、他の層は何も気にしなくてもよいのがポイントです。 参考 詳細編 実際のWebアクセスをレイヤーで見てみよう：ITpro

Windowsサーバーのインストールがとりあえず完了したら、次に行うことはネットワークの設定でしょう。ということで、今回からネットワーク(の入門)のお話がしばらく続く予定です。 ネットワークの説明をする際にはまずOSI参照モデルのお話が出てくるのがお約束です。OSI参照モデルとTCP/IPとの対応等については以下のあたりを確認してみてください。 OSI参照モデル - Wikipedia TCP/IP と OSI 参照モデル 第10回 OSI基本参照モデル――7階層による道案内で，データを迷わせない：ITpro TCP/IPとOSI参照モデル とりあえず4つだけリンクを張りましたが、「OSI参照モデル TCP/IP」とかそのあたりのキーワードで検索をすると、嫌というほど沢山ヒットすると思います。ネットワーク技術に関してはきちんとまとまった資料が書籍にしても、Webサイトにしても多数公開されているのが非常によい点だと思います。 閑話休題。とりあえずいくつかのページを見ながら以下のことに取り組んでみてください。 OSI参照モデルの7層のそれぞれの分割のされ方、役割の理解 OSI参照モデルと対比してTCP/IPの実装がどのように分割されているかの理解 いくつか解釈があるようですが、私なりの理解としては以下のようになります。 レイヤ1：物理層 物理的な接続。電気信号など。 レイヤ2：データリンク層 直接通信可能な機器同士の信号のやりとり。 レイヤ3：ネットワーク層 通信の経路選択、データ中継。複数の機器をまたいだ情報のやり取り。 レイヤ4：トランスポート層 通信の交通整理。エラー訂正、再送信、順序入れ替え等。 レイヤ5：セッション層 プログラム上での、通信の開始から終了までの手順。 レイヤ6：プレゼンテーション層 データの表現方法。 レイヤ7：アプリケーション層 具体的な通信サービス。 TCP/IPはOSI参照モデルのレイヤ3とレイヤ4に対応していて、レイヤ3がIPに、レイヤ4がTCPとUDPに対応しています。 いきなりこれだけのことを出されてもよく理解できないと思いますが、一番重要なことは「階層構造になっている」ということです。つまり、それぞれのレイヤに関しては「別のものに交換可能」ですし、「他の層のことは考えなくてもよい、それぞれの層どうしで話ができる」ということです。 たとえば、レイヤ1に関しては物理的な接続、電気信号の話です。どんなアプリケーションだろうとだれ宛のどんなデータだろうと、「電気信号」として伝えるだけでいいわけです。 たとえばレイヤ7に関しては具体的な通信サービスですので、それが具体的にどのような手段で相手に伝わっているかということは気にせず、「伝わること」を前提としておけるのです。 ・・・・ちょっと難しく、イメージが沸きづらいと思います。今後それぞれのレイヤーの具体例をあげながら話をしていこうと思うので、一通りその内容をみてからここを見直すとすっきりできると思います。