Network

今朝自動車のフロントガラスにかわいいメッセージが残っていました。 さて、今週のトピックスです。 - 2016年にGAしたAzureサービスを一覧にしてみた - Qiita 6 users はじめに この記事は 「Microsoft Azure - Qiita」 の16日目になります。 概要 2016年にGAしたサービスをまとめてみました。 Azureを振り返りながら今年を振り返ってみましょう。 General Availabilityとは Gener… [qiita.com ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fqiita.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 19 clicks 2017/02/10 - Introducing Refresh Windows on-demand option - Microsoft Community 1 user If your PC is running slow, crashes or is unable to update your Windows, this option may help you. This option starts fresh by reinst… ...

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

System Center Operations Managerは様々なデバイスをそれこそオンプレミスのサーバーからアプリケーションからクラウドまでなんでも監視できます。もちろんネットワークデバイスの監視もバッチリ守備範囲です。非常に簡単な操作でネットワーク機器群を監視可能です。 基本的にネットワーク機器にきちんとSNMPの設定が行われていれば、たった1つのネットワーク機器に対して監視を行えばあとは芋づる式にデバイスを発見して監視してくれます。 technet上では以下の記事にネットワークデバイスの検出方法が書かれています。 - [How to Discover Network Devices in Operations Manager](http://technet.microsoft.com/en-us/library/hh278846.aspx) 以下簡単な実行方法です。 まず、検出ウィザードを実行します。 検出するデバイスとして「ネットワークデバイス」を選択します。 検出の種類を選択します。ネットワークデバイスを全て監視したい場合には「再帰的検出」を選択すると手間を大幅に減らすことができます。 ここで、検出に使用するアカウントを作成する…という表現になっていますが、SNMPのコミュニティ名を指定するだけなのでちょっと「アカウント」という印象とは異なります。 アカウント(SNMPコミュニティ名)の指定が終わったら次はネットワークデバイスを指定します。 アカウント情報は監視するサーバーに配布されている必要があります。ここでは「はい」を選択します。 ネットワーク検出ルール実行直後はまだ状態は「保留中」のままになっています。しばらく我慢して待ちます。 しばらくすると状態が「プロープ中」になります。 検出が完了すると、ネットワークデバイスが監視されます。

ずっとまえに書いたブログの下書きが残ったままでもったいないので公開しちゃいます。Windows Server 2012の検証環境で複数セグメントをネットワーク管理者の手を煩わせずに作りたくてVyattaを使っています。かなり簡単にお手軽にルーターを構築できるので助かってます。2013年6月ごろの手順ですが、今でもほぼ変わっていないだろうと思います。 ダウンロード - Download Open Source Vyatta Core Releases | Vyatta.org Community [**http://www.vyatta.org/downloads**](http://www.vyatta.org/downloads) 新規仮想マシンを作成してISOファイルをマウントする。 仮想マシンを電源ONして、コンソールを開く。 id: vyatta, password: vyattaでログイン install systemを実行 ディスクは1つしか接続していなかったのに、なぜかディスクが2つ見つかり、ミラーにするかと聞かれて困惑する。とりあえずNoと答えておく。 あとは、基本的に全部規定の回答でインストール。特に迷うところもありませんでした。 Windows Server 2012の統合当初は色々とネットワーク周りで問題があったようだが、2013/06/20現在では特になんの問題もなく(統合)ネットワークアダプタが認識されました。楽でいいですね。 今回まず2つのネットワークをルーティングしたかったので、NICを2つ接続しています。 ネットワーク設定をするために、どちらがどちらのネットワークに接続されているのかを知る必要があります。色々方法はあると思いますが、私は動的に設定されたMACアドレスを確認しました。 vyatta側のMACアドレスはshow interfacesコマンドで確認出来ます。 set interfaces ethernetコマンドでアドレスを設定します。 その後、commitで反映、saveで設定を保存するします。これでOKです。 なお、使っている中でNICのMACアドレスが意図せず変更され違うNICとして認識されてしまい構成が反映されないことがありました。これを防ぐにはMACアドレスが動的に設定されたあとで、同じ値を静的に登録しておくのが良いのでは無いかと思います。 構成する上では以下の記事が非常に参考になりました。 - 高機能なLinuxベースのソフトウェアルーター「Vyatta」を使う - さくらのナレッジ [**http://knowledge.sakura.ad.jp/tech/278/**](http://knowledge.sakura.ad.jp/tech/278/)

最近はかなりSystem Centerに注力しているのですが、その中ですぐに取り掛かることになるにもかかわらず難しくてまだ良くわかっていないのがSystem Center Virtual Machine Manager 2012 SP1のネットワーク周りです。事前にOS、Hyper-Vマネージャーあたりで構成しておいてしまえばそのままその設定が引き継がれて、何も考えなくても使い出せてしまったりするので敷居は高くないものの実際には使っていない機能が多数ある・・・という事になりがちだと思います。 あちこちでいろんな人に聞いてみても結局SP1から大きく変わったこともありまだよくわかってなくて…という回答ばかりです。少しづつ理解を進めているのですが理解しきれないうちにもうSCVMM 2012 R2の足音まで聞こえてきてしまいました。 まとまったものとしては以下のブログが参考になりそうですが・・・、まだ執筆途中だったりします。 - [Virtual Networking in VMM 2012 SP1 – Part 1 - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2013/01/08/virtual-networking-in-vmm-2012-sp1.aspx) [Networking in VMM 2012 SP1 – Logical Networks (Part I) - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2013/02/14/networking-in-vmm-2012-sp1-logical-networks-part-i.aspx) - [Logical Networks (Part II) – How many logical networks do you really need? - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2013/04/29/logical-networks-part-ii-how-many-logical-networks-do-you-really-need.aspx) - [Logical Networks (Part III) – Network Isolation - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2013/05/22/logical-networks-part-iii-network-isolation.aspx) - [Logical Networks (Part IV) – PVLAN Isolation - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx) - [Logical Networks (Part V) – Network Virtualization - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2013/06/17/logical-networks-part-v-network-virtualization.aspx) ポスターもありますが…。 ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCVMM 2012 SP1のネットワーク周りが難しい | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/06/27/scvmm-2012-sp1%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%91%A8%E3%82%8A%E3%81%8C%E9%9B%A3%E3%81%97%E3%81%84/)

前回Hyper-Vの外部ネットワークについて解説しました。今回はHyper-Vの内部ネットワークとプライベートネットワークについて解説します。とはいっても、外部ネットワークが一番わかりずらいのでそれがわかってしまえばこちらは簡単です。 まず、下図がNICが1つだけ搭載されているサーバーにHyper-Vを有効化しただけの状態です。 内部ネットワーク ここに対して内部ネットワークを有効にすると以下のようになります。 内部ネットワーク用の仮想スイッチが内部的に作成され、それに接続された仮想NICが親パーティションに見えてきます。このスイッチに対してはもちろん子パーティションのホストも接続出来ます。 このように外部には出ていかないHyper-V内の内部的なネットワークが作成できるようになるわけです。これが内部ネットワークです。 プライベートネットワーク プライベートネットワークは内部ネットワークから更に親パーティションの仮想NICでの接続を省いたものです。 子パーティションが1台だとあまり存在している意味が無いですね。2台書いてみます。 このように子パーティション同士の接続のみが行えるスイッチになるわけです。 ここまで理解上で上の設定画面を見ると・・・・どうでしょうか意味がわかりますでしょうか？個人的にはなぜ外部ネットワークの時には親パーティションへの仮想NIC作成がチェックボックスなのに、内部では違うのか理解に苦しみます。こんな感じのGUIのほうが直感的じゃないですかね？ もっと言うと文言も変更したいです。 こんなかんじでどうでしょうか。どうでしょうかって言われても困りますね。ごめんなさい・・・。

Hyper-Vを一番はじめに触ってまず混乱するのがネットワーク周り、特に外部ネットワークの部分だと思います。図を用いながらなるべくわかりやすくなるように解説してみたいと思います。 Hyper-V導入前 まず、単純に1つのNICを持ったサーバーがあります。 このように、単純にサーバーが1つあり、NICが1枚ついており、単純に物理スイッチのポートに刺さっているだけです。何も難しいことはありませんね。この物理NIC1には普通にTCP/IPの設定がなされることになります。 Hyper-V導入 Hyper-Vの役割を導入します。この状態では見た目上は目立った変更はありません。NICの状態にも図にも変化無しとして良いと思います。ですが、私はHyper-Vにおいては「親パーティションと子パーティションは同じレベルで存在している」という捉え方をするほうが理解しやすいと思っています。なので、以下のように書き換えて理解することをおすすめします。 上記の図で言いたいことはHyper-Vの役割を有効にした時点で親パーティションも物理サーバーとは切り離されて、仮想化されているということです。ただ、まだ何も特別な設定をしていないので、物理NIC1は親パーティションに直接見えている状態です。 外部ネットワークの追加 ここでHyper-Vの仮想スイッチマネージャーで外部スイッチを新規に作成します。 すると、以下の様に仮想NICが親パーティションに見えてきます。 この状態は図で表すと以下のような状態です。 もともとの物理NICだったもの(画像では名前が「イーサネット」になっているもの)は、プロパティを見ると以下の状態となっており、仮想スイッチとして動作していることがわかります。 #個人的にはアイコンも変更すべきだと思うのですが。 新しく出来たvEthernetという名前のNICが仮想NICであり、親パーティションのメインのNICになったものです。TCP/IPのプロパティはこちらに引き継がれています。これは、下記の図の「管理オペレーティング・システムにこのネットワークアダプターの共有を許可する」のチェックがONになっているために生成されています。 つまり「管理オペレーティング・システムにこのネットワークアダプターの共有を許可する」=「親パーティションに仮想NICを1つ追加して、それをこの外部ネットワークとつながる仮想スイッチに接続する」という意味なわけです。このチェックを外せば親パーティションから仮想NIC1が消えることになります。 そして、生成された仮想スイッチはスイッチなわけですから複数のNICが接続できます。子パーティションを2つほど追加し、直接外部ネットワークに接続する様子は以下のようになります。 子パーティションは仮想NICを作成し、それを仮想スイッチに接続します。これは論理的には以下のように接続されていることと全く同じです。 物理ホストに2つNICがある場合 物理ホストには、ホスト管理専用のNICを設けることが推奨されています。これまでの図のように仮想スイッチ経由で仮想NICをもち、それをそのまま管理用にすることもできますが、トラブルが発生した時などの切り分けが難しくなるからですね。その場合誤ってやってしまいがちなのが以下のような構成です。 → 左がHyper-Vを有効にしただけの状態。右側がNIC2を外部スイッチにし、子パーティションを1つ追加し外部スイッチに接続している状態です。この時やってはいけないのは、親パーティションと子パーティションを同じセグメントに接続することです。親パーティションに注目した時に、物理NIC1と仮想NIC1が同じセグメントに接続してしまっていると、通信はどちらから発信されるかわかりません。この結果通信が出来たり出来なかったり不安定な状態になってしまいます。この間違いはHyper-V初心者はほぼ全員やるんじゃないかというくらいメジャーな構成ミスですので特に注意してください。 この状態を正すにはHyper-Vマネージャーにて仮想スイッチの設定から「管理オペレーティング・システムにこのネットワークアダプターの共有を許可する」のチェックを外せばよいです。すると以下のようになります。 親パーティションには物理NICが1つのみ割り当てられており、管理用に使用出来ますし、子パーティションはきちんと仮想スイッチ経由で外部ネットワークにアクセスできるようになっています。 これがHyper-Vの外部ネットワークの基本です。

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の基本です。

Windows Server 2012では2008 R2までとは異なりOSレベルでNICのチーミング機能が追加され、Microsoftがチーミングをサポートするようになりました。今までは各種HWベンダーのソリューションを用いてチーミングを構成していましたがWindows Server 2012以降ではOSのチーミング機能を用いてチーミングを構成し、サポートもマイクロソフトにしてもらう形が多くなるものと思います。特にHyper-V周りのサポートでは色々と混乱や初期に「サポートが無い」状態が続いたので管理者にとっても良い傾向だと思います。 このあたりのNICのチーミングの話に関してまとまった記事があったので紹介します。(英語) - [Windows Server 2012 NIC Teaming Part 1 – Back To Basics](http://www.aidanfinn.com/?p=13984) - [Windows Server 2012 NIC Teaming Part 2 – What’s What?](http://www.aidanfinn.com/?p=13997) - [Windows Server 2012 NIC Teaming Part 3 – Switch Connection Modes](http://www.aidanfinn.com/?p=14004) - [Windows Server 2012 NIC Teaming Part 4 – Load Distribution](http://www.aidanfinn.com/?p=14032) - Windows Server 2012 NIC Teaming Part 5 – Configuration Matrix Microsoftのドキュメントだと以下のあたりです。 - ネットワーク アダプターの負荷分散とフェールオーバー (LBFO) 詳細はリンク先を読んでもらうとして、ざっくりとした概要は以下のような感じです。 ...

今回は検証環境のネットワーク周りについて書きたいと思います。 検証時にやってはいけないこと 検証をする時には自由にサーバーを立てたりするわけですが以下のようなことをすると非常に大変なことになってしまいます。 - IPアドレスをバッティングさせてしまう きちんと通信できませんし、場合によってはもともと正しくそのIPアドレスを使っていた本来のホストが通信できなくなってしまうようなことにもなります。それが重要なサービスを行っているサーバーだったりすると……。 - DHCPサーバーを本番ネットワークで立ててしまう 検証用ネットワーク…のつもりで構成してあると、起動して間違ったDHCPサーバーからIPアドレスを受け取ってしまったホストがすべてきちんと通信できなくなります。私の所属する会社でも昔は新人が配属された直後に毎年のようにこの事故が起きてました…。 - ホスト名、ドメイン名をバッティングさせてしまう Windowsネットワークではホスト名やドメイン名は重複できません。特に同一セグメント内ではブロードキャストしてますので、ホスト名が重複しているというエラーが表示されちゃいます。同一セグメント内で同じドメイン名、特に同じBETBIOSドメイン名なんて作ってしまうとまともに動かなくなると思います。マニアックなところでは、ドメイン名と同じホスト名が存在してたりするとドメインに参加しているホストのすべてが起動するたびにホスト名の重複のエラーが表示されたりします。この時ホスト名同士が重複しているわけではないので原因を探すのにちょっと時間がかかったりします。 このようなことがありますので、検証用のネットワークはきちんと本番のネットワークから独立させようという話が出てきます。もちろん独立させるべきです。ただ、単純に独立させてしまうと今度は以下のような場面で不便です。 - Microsoft Updateを実行したいけどできない。 - 検証環境にファイルを持ち込んだり持ち出したりしたいけどできない。USBメモリ、UBS HDDは使用禁止だし…。 - 自分のPCからリモート接続できたら便利なのにできない…。 このようなことがあるので、検証環境を本番環境から安全に分離しつつ利便性を損なわない構成にしたくなります。 もっとも、セキュリティを最重視するのであればネットワークは完全に切り離されるべきですし不便であるべきです。部屋も別、携帯等の持ち込みも禁止……、というような環境もあります。私はそこまですると非効率すぎて逆に事故が増えるのではと思いますが…。 具体的な方法 いくつか具体的な対象方法を挙げてみます。 - 検証環境と本番環境の両方に接続するホストを作り、そのホスト上で必要なProxyを動作させる。ファイルの中継場所にする。 - 検証環境と本番環境の間にFWやNATを設け、必要な通信のみ行えるようにする。 - 検証環境からインターネットにアクセスする回線を別途設ける。 どれかひとつだけやればいいというわけでもなく、並行してやっても良いです。他にも色々なやり方があるとも思います。 また、検証環境が仮想環境上にある場合などはネットワーク的には完全に切り離しつつコンソールにアクセスすることが基本機能でできますね。最近はもうこういう環境の方が多いかもしれませんね。ただ、Hyper-Vのコンソールなどはコピペすらまともにできず酷いもんですが…。 よく使うソフト 私がよくつかうソフトを一応紹介しておきます。実はあまりよく調べて選んでいるわけではないのですが便利に使わせてもらっています。 DeleGate Home Page (www.delegate.org) Hyper-Vの物理ホストあたりにはProxyとしてDeleGateを仕込んでおくことが多いです。 BlackJumboDog ちょっとした検証の時にGUIでちょちょいっと設定して動かせちゃうので重宝します。Proxy以外にも色々なサーバーになれてしかもデバッグ表示が優れているので検証用途には重宝しています。

このエントリでは典型的な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ポート枯渇 - パケットキャプチャ ...

tdiaryへのコメントスパムがまた大量に来てます。ごみをたくさん流してしまって本当にごめんなさい。スパムフィルタをさらに改良しないといけないのですが、このレベルだと通常のコメントとの判別もなかなか難しいので困ったものです。 コメントは単一IPからではなく、複数のIPから来てます。でも、コメントもほぼ一緒ですし、明らかに同じプログラムが動作しているようです。bot networkなんですかね。怖いですね。 自宅サーバーはへなちょこPCで運用しているので、ちょっと大量のアクセスがくると、それだけでひーひー言ってしまってまともに動かなくなってしまいます。サーバーを増強したり、IDSを入れたり、対応の仕方はいろいろありますが、本格的に対応する気力が足りません・・・。

今回はマルチホーム構成時の注意点についてです。マルチホームというのは要するにNICが2つ以上あって、複数のネットワークに足を出している状態のことです。結構な頻度でマルチホーム構成を選択し、やってはいけない構成でトラブルに遭遇するケースを見ています。しっかり抑えておきましょう。 デフォルトゲートウェイは1つだけ まず、一番初めに理解してほしいのは「デフォルトゲートウェイを2つ以上設定してはいけない」ということです。よく理解していない人は多くのケースで2つNICがあったら2つゲートウェイを設定してしまうようです。 でも、ちょっとよく考えてみてください。デフォルトゲートウェイというのは、自分が所属していないネットワークに向かって通信するときにパケットを投げる相手ですよね?それが2つ設定されていたら、どっちに投げたらいいんでしょう?困ってしまいますよね? どっちに投げてもきちんと相手まで届く構成であれば問題がおきないこともあるでしょうけれども、やはりこれはよくない構成です。場合によっては通信できないことになるでしょう。 - デフォルトゲートウェイは1つだけ設定する(1つのNICだけで入力し、ほかのNICでは空白にしておく) - 必要な経路に関してはスタティックルートを記述する このようにしておかなくてはいけません。 スタティックルートを記述 スタティックルートの記述･･･といってピンとこない方も多いかもしれませんね。基本的にNICが1つであれば必要ない設定ですから。でも2つ以上になったら、「このネットワークアドレスに向けての通信は、こっちの足からあのルーターに投げる」ということをしっかりと記述してあげる必要があります。 Windowsではこの設定は「route」コマンドで実施できます。経路の追加はroute addコマンドです。コマンドの説明は例のごとく@ITにお願いしちゃいます。 - [route - ルーティングテーブルの表示／設定を行う](http://www.atmarkit.co.jp/fnetwork/netcom/route/route.html) 注意点としては、再起動しても消えないように設定するには-pオプションをつける必要があることです。route printコマンドで経路情報を表示した際に、きちんと追加した経路が「Persistent Routes」として表示されることを確認しておきましょう。そうでないと、うまくいったと思っていたら1月くらいたって再起動したらまたおかしくなったなんていうことになってしまいます。 DNSを2つ以上設定しない またデフォルトゲートウェイの次に気をつけてたいのはDNSの設定です。特にInternet側とIntranet側なんていうようにNICが分かれていた場合、Internet側のNICにはインターネットの名前解決ができるDNSを、Intranet側のNICには社内のDNSを設定したくなる人も多いかと思います。 でも、よく考えてみてほしいのですが、両方に問い合わせるわけにはいきませんよね。もしも両方のDNSに同じドメインが存在したりしていたうえに異なるレコードが登録されているような場合には(これはありえないことではありません)、通信しようとするたびに名前解決の結果が異なるようなことにもなってしまいます。これはやはりだめです。 DNSに関してはどれが正解ということはないです。そのホストの必要に応じて、正しいDNSを参照させる必要があります。「両方のDNSを参照したい」と思ってしまうのなら、それはDNSの設計、構成が間違っている可能性があります。場合によってはhostsファイルを併用してもいいでしょう。 DNSへの登録に気をつける マルチホームの場合にはDNSへの登録にも気をつけてください。特に何も考えないと、ホストについている2つ以上のIPアドレスをすべて登録して、ラウンドロビンになってしまいます。特にDCでこれをやってしまうとかなりクリティカルな障害にもつながってしまいますので、特に気をつけてください。 DCに関してはマルチホーム時のマスタブラウザの問題もあるのでそもそもマルチホームにしないほうが良いです。でも、それでもどうしてもDCをマルチホームにしたいのであれば、Aレコードの自動登録をやめさせる必要があります。DCはNetlogonサービスが定期的に自身のDCとして動作するためのレコードをDNSに定期的に登録に行くようになっているからです。このあたりの手順は以下のKBを参考にしてください。 - [Active Directory communication fails on multihomed domain controllers](http://support.microsoft.com/?scid=kb%3Ben-us%3B272294&x=7&y=17) その他まだまだありますが･･･ 今回紹介したこと意外にもマルチホーム構成の時の注意点は色々あります。特にDMZとLANに足をだしていて、DMZ側のIPでサービスを提供しているようなときに、入力と出力で使うNICが異なるようになってしまったりとか･･･。2つ経路があるときに意図的に片方のネットワークを使わせようと思ってもうまくいかなかったりとか･･･。バックアップ専用のネットワークを作ろうとしたりするときとか･･･。 このあたりはちょっと複雑になりすぎるので、また機会を改めて解説させてもらおうと思います。とりあえず今回紹介した注意事項が基本中の基本ですので、まずはここから気をつけていってみていただければと思います。 参考URL - [マルチホーム コンピュータのデフォルト ゲートウェイ設定](http://support.microsoft.com/kb/157025/ja) - [[NT]同一ネットワークに複数のアダプタを接続した場合の障害](http://support.microsoft.com/kb/175767/) - [マルチホーム化されたブラウザに関する問題](http://support.microsoft.com/kb/191611/ja)

今回はサブネットマスクの理解です。私も「255.0.0.0」、「255.255.0.0」、「255.255.255.0」以外のサブネットマスクだとすぐにはピンとこないのですが、理屈を抑えておけば理解は簡単です。是非仕組みを理解しましょう。 サブネットのマスクである まず、そもそも「サブネットマスク」という言葉ですが、これは『「ネットワーク」を複数の「サブネットワーク」に分割するための「マスク」』というように私は理解しています。 ネットワークは分割される TCP/IPのネットワークは大きく扱うこともできるのですが、ブロードキャスト(同一ネットワーク上の全てのホストに対してパケットを送る)が数多くとびかってしまい、これがネットワーク全体のパフォーマンスを下げてしまったり、ホストに対しても負荷をかけてしまったりするため、適当な大きさに「分けて」使うということをします。同時に、セキュリティ上の理由からも複数のネットワークに分けておき、ネットワークの分け目の部分でパケットのコントロールを行うようなこともあります(ファイアウォール)。 とまぁ、このようなわけでネットワークを分割するニーズがあります。 クラス、CIDR 昔はネットワークの分割方法としては以下の5つだけでした。 - クラスA(0.0.0.0-127.255.255.255) - クラスB(128.0.0.0-191.255.255.255) - クラスC(192.0.0.0-223.255.255.255) - クラスD(224.0.0.0-239.255.255.255) - クラスE(240.0.0.0-255.255.255.255) ですが、これだとちょっと粒度が大きすぎるということで、CIDRという手法が一般的に用いられるようになりました。これはルーターがルーティングする際の情報を集約できるようにするための手法なのですが、これがそのままホスト上のTCP/IPの設定にも反映されているわけです。これによって、サブネットマスクのビット長は可変になりました。 うん。ちょっと良くわからない説明になってきてますね。今回はルーターの話は省略して、ホスト上のサブネットマスク周りの話に焦点を絞って、もうちょっと具体的に説明しようとしてみます。 IPアドレス、サブネットマスク、ネットワークアドレス IPアドレスがあります。 - IPアドレス1 - 192.168.1.1 - IPアドレス2 – 192.168.1.130 唐突ですが、問題です。「2つのIPアドレスは同一ネットワーク上にあるでしょうか、それとも別ネットワークにあるでしょうか?」 昔なら(5つのクラスしかなかったときならば)答えは「同一ネットワーク」でした。ですが、今現在としては「サブネットマスクが提示されていないからわからない(どちらでもありうる)」ということになります。 それでは具体的にサブネットマスクを提示してみます。 - パターン1 IPアドレス1 - 192.168.1.1 / 255.255.255.0 - IPアドレス2 – 192.168.1.130 / 255.255.255.0 - パターン2 IPアドレス1 - 192.168.1.1 / 255.255.255.128 - IPアドレス2 – 192.168.1.130 / 255.255.255.128 - パターン3 IPアドレス1 - 192.168.1.1 / 255.255.255.192 - IPアドレス2 – 192.168.1.130 / 255.255.255.192 それぞれのパターンで同一ネットワークか別ネットワークにあるかわかりますでしょうか?判別するには「IPアドレスをサブネットマスクでマスクしてあげて、ネットワークアドレスを求め、それを比較する」ことが必要です。また、コンピューターの中では全て0,1で計算されているので、このあたりは2進数に変換すると非常に理解しやすくなります。2進数にしてから考えて見ます。 ...

今回の話題はWindowsネットワークに関してです。まずは一番基本的なところから、ということで2台のWindowsPCをネットワークで接続することから始めます。 まず接続する(レイヤー1) まず2台のPCを接続する必要があります。接続するには主に以下のような方法があります。 ハブ(スイッチングハブ、あるいはリピータハブ)を用意し、それぞれのPCをハブに接続する。ケーブルにはストレートケーブルを使う。 クロスケーブルを使い、2台のPCを直接接続する。 それぞれ無線LANのアクセスポイントに接続する。 どの方法でも構いません。下位レイヤに上位レイヤが無影響でいられるところがOSI参照モデルのメリットです。(参照：OSI参照モデルとTCP/IP) APIPA(Automatic Private Ip Addressing)を理解する 接続がすんだら次はネットワークの設定…なのですがその前に今の状態を確認してみましょう。 何もネットワークの設定をしていない状態で以下のコマンドを実行してみてください。 ping もう一台のコンピューター名 どうでしょうか?何も設定していないのにpingに応答があったと思います。(応答がない場合には後述する「通信できない原因」を参照してください)もうちょっと見てみましょう。「スタート」→「ファイル名を指定して実行」にて「\もう一台のコンピューター名」を入力してみてください。結果は環境やパスワードの設定などによって異なるのですが以下のような挙動のはずです。 パスワード入力を求められた コンピュータに接続でき、ウインドウが開いた さらに言うと、「マイネットワーク」を開いて適当にたどってもらうと、そこにもう一台のコンピューターも表示されているはずです。表示されるまでには時間がかかるのでまだ表示されていないようであれば10分程度待ってからもう一度表示してみてください。 つまり、何も設定していないのにもうネットワーク的に接続されていて、しかも、コンピューター名をお互いに認識できているわけです。Windowsは知識がないユーザーのために「とりあえず刺せば繋がる」ようになっているわけですね。 このときネットワークの設定はAPIPAという機構が働いて設定されています。アドレスは169.254.0.0/16の範囲から重複しないように選ばれます。ipconfig /allで設定を確認することができます。 この機能、親切だし便利ではあるのですが「設定されるまでに時間がかかる」「インターネットには接続できない」という致命的な問題もあり、実際にはよく分かっていない人がわけもわからず使ってしまっていることをのぞけばまず使われていません。 ネットワークの設定をする(レイヤー3) では、きちんとネットワークの設定をしていきましょう。現在はTCP/IPがデファクトスタンダードですので、WindowsのネットワークにおいてもTCP/IPの設定をすることになります。設定は以下の手順で行えます。 「マイネットワーク」を右クリック→「プロパティ」→「ローカルエリア接続」(※使用するネットワークアダプタ)を右クリック→「プロパティ」→「インターネットプロトコル(TCP/IP)」→「プロパティ」 ここで2台のコンピューターのネットワーク設定を以下のように設定します。 同一のネットワーク 重複しないIPアドレス 今はプライベートなネットワークを作ろうとしていますのでIPアドレスとしてはプライベートIPアドレスを設定すべきです。具体的には以下のアドレスの範囲から選択します。 範囲 サブネットマスク 10.0.0.0 - 10.255.255.255 255.0.0.0 172.16.0.0 - 172.31.255.255 255.240.0.0 192.168.0.0 - 192.168.255.255 255.255.0.0 実際には2台であれば192.168.1.0/24のネットワークを使って、192.168.1.1, 192.168.1.2というIPを割り当てることが慣習的に多いです。 しかし、上記のプライベートIPアドレスの範囲であれば何を使っても構いません。さらに言うと上記のプライベートIPアドレスの範囲を超えてグローバルIPアドレスの範囲を使っても通信は問題なく行えます。ただし、特殊用途のIPアドレスとして割り当てられている範囲もあるため、適当に設定すると通信できないこともあり得ますので、素直にプライベートIPアドレスを使うべきでしょう。 デフォルトゲートウェイとサブネットマスク このとき、デフォルトゲートウェイとDNSサーバーに何を入れればいいのか迷うかもしれませんが、今回の構成ではネットワーク上に存在しないわけですから何も入力しなくて構いません。あるいは何か適当なIPアドレスを入力しても構いません。このような構成は検証環境等ではよくあります。 ここでひとつ注意点です。たまにデフォルトゲートウェイに値が入っていないと正常に動作しないアプリケーションがありますので注意してください。(単にソフトウェアのつくりが悪いだけなのですが) 例：Outlook 2007 と Exchange Server の接続を試みたときに、エラー メッセージ “アクションを完了できません。Microsoft Exchange Server への接続が利用できません” または “Your Microsoft Exchange Server is unavailable” が表示される 通信してみる ここまででWindowsネットワークの設定が完了しました。 ...

ホスト名、それに対応するIPアドレス。それがどのようにホスト上にキャッシュされるのかについて見てみます。なお、ここではNETBIOS名に関しては言及しません。ホスト名限定の話です。 キャッシュする様子を見てみる まずは単純にホストに対してpingを実行する、というケースに対し、このときの動きをキャッシュを含めてみてみましょう。 まず、キャッシュを確認してみます。コマンドは「ipconfig /displaydns」です。 C : \ D o c u m e n t s a n d S e t t i n g s \ A d m i n i s t r a t o r > i p c o n f i g / d i s p l a y d n s W i n d o w s I P C o n f i g u r a t i o n 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a R e c o r d N a m e . . : 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a . R e c o r d T y p e . . : 1 2 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r P T R R e c o r d . : l o c a l h o s t l o c a l h o s t R e c o r d N a m e . . : l o c a l h o s t R e c o r d T y p e . . : 1 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r A ( H o s t ) R e c o r d . . : 1 2 7 . 0 . 0 . 1 .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, “Courier New”, courier, monospace; background-color: #ffffff; /white-space: pre;/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } キャッシュ上にはlocalhostとローカルループバックの逆引きのレコードしか登録されていません。 ...

「インターネットに繋がらない」という事象をテーマにして以下2つのエントリを書きました。 「インターネットに繋がらない」 - 初級編 「インターネットに繋がらない」 - Proxy編 今回はVPN編です。 VPN接続の場合にはさらに話が複雑になります。VPN接続の場合には以下の4つのパターンが存在することになります。 VPN接続ではない直接接続しているネットワークを使って直接インターネットに接続 VPN接続ではない直接接続しているネットワーク上のProxyをつかってインターネットに接続 VPN接続先のネットワークを使って直接インターネットに接続 VPN接続先のネットワーク上のProxyを使ってインターネットに接続 Proxyの設定をしていないときに1の経路になるのか、3の経路になるのかは、VPNの設定上でコントロールをします。 ここの「リモートネットワークでデフォルトゲートウェイを使う」というチェックボックスがまず1つ目のポイントです。 チェックが入っていなければ直接接続されているネットワークから別ネットワークにアクセスする(パターン1) チェックが入っていればVPN接続先のネットワークから別ネットワークにアクセスする(パターン3) もちろんどちらの場合にも「初級編」で解説した内容が当てはまりますが、1点注意点として、VPN接続時の参照DNSはVPN接続先のDNS設定よりも直接接続されているネットワーク上の設定が優先されるようです。(手元のWindowsXP SP3で確認) 次に、IEの中に「ダイアルアップと仮想プライベートネットワークの設定」という項目があります。 この中に「プロキシサーバー」の設定があります。ここが2つ目のポイントです。VPN接続先のProxyサーバーを使うにはここの部分にProxyの設定を入力する必要があります。ここに設定がなされていればパターン4になるわけです。 直接インターネット接続に出る経路とVPN経由の経路とであまりスピードが変わらないような場合には問題にならないかもしれませんが、特にダイアルアップ接続など帯域が細い経路が存在している場合には、きちんと帯域の太い経路からインターネットアクセスを行わせるように構成することが重要ですね。

「インターネットに繋がらない」 - 初級編では直接、インターネットに接続されている環境での処理の流れを見てもらいました。今度は別のバリエーションとして、直接はインターネットに接続されておらず、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 ...

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