ネットワークスペシャリスト合格に役立ちそうな情報纏め

# ネットワークスペシャリスト合格に向けた纏め

あくまで自分の知識整理のための纏めです。自分が保有知識として問題ないと思われる分野については割愛します。本纏めは[ネスペイージス](https://www.infraexpert.com/info/netspecial1.html)様の情報を骨子に、各所から集めた情報や自分の知識で肉付けしています。



## 各種プロトコル


### ARP

* ARPパケットは
  * OSI参照モデルのネットワーク層で動作する（IPと同じ）
  * イーサネットフレームにカプセル化される
* ARPリクエスト
  * ブロードキャストで送信される
  * 知りたいノードのIPアドレスが格納されている
* APRリプライ
  * ユニキャストで送信される
* RARP
  * MACアドレスからIPアドレスを得るプロトコル
  * 現在はほぼ使用されていない
  * IPアドレスを持たないと通信できない機器であるにも関わらずIPアドレスの設定ができない機器がある場合に使用される
  * 自分のMACアドレスはわかることから、そのMACアドレスをRARPリクエストとして送り、RARPサーバがIPアドレスを教えてくれる
* ARPキャッシュとARPテーブル
  * ARPキャッシュがARPテーブルに残っていればARPリクエスト・レスポンスのやりとりなしに通信可能
  * ARPテーブルは「arp -a」で確認可能
  * ARPキャッシュは一定時間後に消えるが、今すぐ削除したい場合は「arp -d」で削除可能
  * デフォルトで登録されている情報は、
    * 192.168.0.255→同ネットワークのブロードキャストアドレス
    * 224.0.0.22, 239.255.255.250→マルチキャストアドレス
    * 255.255.255.255→ブロードキャストアドレス



### ICMP

* IPプロトコルのエラー通知や制御メッセージを転送するためのプロトコル

* 通信状態確認のために使われる

* OSI参照モデルのネットワーク層で動作するプロトコル

  * pingやtracerouteはこのICMPプロトコルを使用したプログラム
  * 正確にはIPプロトコルの上位に位置する

* ICMPメッセージは以下のように構成される

  | 各フィールド | 英語表記 | ビット数 | 各フィールドの説明                                           |
  | ------------ | -------- | -------- | ------------------------------------------------------------ |
  | タイプ       | Type     | 8 bit    | ICMPメッセージの機能タイプの値が入る。値は下表を参照。       |
  | コード       | Code     | 8 bit    | ICMPメッセージの詳細な機能コードの値が入る。値は下表を参照。 |
  | チェックサム | Checksum | 16 bit   | エラーがないかどうかをチェック。                             |
  | データ       | Data     | 可変長   | ICMPの「タイプ」により長さが異なる。                         |

* ICMPメッセージは大きく2種類に分かれる

  * 問い合わせ（Query）
    * このQueryによりあるノードから特定のノードに対する通信状態を確認することができる
    * このQueryを利用した代表的なプログラムがpingとtraceroute
  * エラー通知（Error）
    * ノード間の通信で経路途中でパケットが廃棄されたりした場合に、その原因を送信元のノードにエラー通知する

* ping

  * ネットワークの診断プログラム
  * Windowsの場合、pingを打つとデフォルトで4回のICMPメッセージが送信される
  * 通信先ノードの途中経路のネットワーク機器でICMPだけブロックしているケースがある
    * この場合はTCP／IP通信は問題ない
  * 「 192.168.0.254からの応答： 転送中にTTLが期限切れになりました 」の場合、ルータ側の設定ミスによるルーティングループが原因であることがほとんど

* traceroute

  * あるホストから宛先のホストまでに到達するためにどのネットワーク経路を使用しているのかがわかる
  * Windowsの場合はICMPを、LinuxではUDPを使用する
  * 仕組みとしては、宛先のホストに向けたICMPパケットにおけるTTLを１から順に増やしていき、都度、通信経路のノードからTime Exceededのリプライを受け取ることにより、経路を把握していく



### TCP

* ポートはコンピュータが通信を行うために通信先のアプリケーションを特定するための番号のこと

  | ポート番号のタイプ     | ポート番号の範囲 | 説明                                                         |
  | ---------------------- | ---------------- | ------------------------------------------------------------ |
  | ウェルノウンポート番号 | 0～1023          | IANAで管理。サーバのアプリケーションに割り当てられるポート番号。 |
  | 登録済みポート番号     | 1024～49151      | IANAで管理。独自に作成したアプリケーションに割り当てられるポート番号。 |
  | ダイナミックポート番号 | 49152～65535     | クライアント側のアプリケーションに自動的に割り当てられるポート番号。 |

* 登録済みポート番号は独自に作成されたアプリケーションに割り当てられる

  * IANAにより管理されている

* ダイナミックポート番号はアプリケーションプロセスの要求に応じて動的に割り当てられるポート番号のこと

  * クライアント側のアプリで使用される番号

* 登録済みポート番号は一般的にサーバに割り当てられますが、登録済みポート番号がクライアントに割り当てられる時もある



### TCPヘッダのフォーマット

| 各フィールド       | ビット数 | 各フィールドの説明                                           |
| ------------------ | -------- | ------------------------------------------------------------ |
| 送信元ポート番号   | 16 bit   | 送信元のポート番号の値。                                     |
| 宛先ポート番号     | 16 bit   | 宛先のポート番号の値。                                       |
| シーケンス番号     | 32 bit   | 送信したデータの順序を示す値。「相手から受信した確認応答番号」の値。 |
| 確認応答番号       | 32 bit   | 確認応答番号の値。「相手から受信したシーケンス番号」＋「データサイズ」。 |
| データオフセット   | 4 bit    | TCPヘッダの長さを示す値。                                    |
| 予約               | 6 bit    | 全ビット「0」が入る。将来の拡張のために用意されている。      |
| コントロールフラグ | 6 bit    | URG、ACK、PSH、RST、SYN、FINの6つのビットで構成されている。 　これらのビットは「1」の値が入る（フラグを立てる）場合に意味をなす。 |
| ウィンドウサイズ   | 16 bit   | 受信側が一度に受信することができるデータ量を送信側に通知するために 　使用される。送信側は、この値のデータ量を超えて送信することはできない。 |
| チェックサム       | 16 bit   | TCPヘッダとデータ部分のエラーチェックを行うために使用される値が入る。 |
| 緊急ポインタ       | 16 bit   | コントロールフラグのURGの値が「1」である場合にのみ使用されるフィールド。 　緊急データの開始位置を示す情報が入る。 |
| オプション         | 可変長   | TCPの通信において、性能を向上させるために利用する。例えば 　TCPコネクションの際に、MSSを決定するために使用されたりします。 |
| パディング         | 可変長   | TCPヘッダの長さを32ビットの整数にするために 　詰め物(Padding)として空データの 「 0 」 の値を入れることにより調整する。 |

* 以下の表はTCPヘッダのフィールドにあるコントロールフラグの詳細

| コントロールフラグの詳細 |                                                              |
| ------------------------ | ------------------------------------------------------------ |
| ビット                   | 値が「1」である（フラグが立っている）時の意味                |
| URG (Urgent)             | 緊急に処理すべきデータ含まれていることを意味する。           |
| ACK (Acknowledgement)    | 確認応答番号のフィールドが有効であることを意味する。コネクション確立時以外は値が「1」。 |
| PSH ( Push )             | 受信したデータをバッファリングせずに、即座にアプリケーション（上位）に渡すことを意味する。 |
| RST ( Reset )            | コネクションが強制的に切断されることを意味する。何らかの異常を検出した場合に送信される。 |
| SYN ( Synchronize )      | コネクションの確立を要求することを意味する。                 |
| FIN ( Fin )              | コネクションの正常な終了を要求することを意味する。           |

* SYN, ACKで接続要求と応答を表し、それぞれ、0で無効、1で有効を意味する
* シーケンス番号は３ウェイハンドシェイクの開始時にランダムに設定され、以降は「相手から受信した確認応答番号」となる
* 確認応答番号は以下の値となる
  * ３ウェイハンドシェイク時は「相手から受信したシーケンス番号」に１を加算した値
  * 「相手から受信したシーケンス番号」に「データサイズの値」を加えた値
* 切断要求はFINビットが１になる
* 確認応答番号はFINへの確認応答の場合、「相手から受信したシーケンス番号」に１を加算する



#### MSSについて

* MSS（Maximum Segment Size）は１つのTCPパケットで運ぶことができるデータ量のことを指している

* 一般的には最大サイズはEthernetフレーム（1518byte）では、MSSは1460バイトになる

  * よってホストA→ホストBで14600バイトのTCPデータを送信したい場合、10回に分割する必要がある

  * ３ウェイハンドシェイクの際のSYNパケットで双方向に伝えられ、両者の値のうち小さい値が採用されて双方向通信の際に使用される

    

#### 通信効率の向上（ウィンドウ制御）

* パケット送信の都度、相手先からACKがかえってくるようでは通信速度が遅くなってしまう
  * そこでACKを待たずに一度に送信できるデータ量を定めている
    * これをウィンドウサイズという
    * ウィンドウサイズは３ウェイハンドシェイク時にデータを受信する側のホスト→送信側のホストへと伝えられる
  * スライディングウィンドウとは、ウィンドウサイズ分のデータをセグメント分割して送り、一部のセグメントについてACKが返ってきた場合、返ってきた分のセグメント分をスライドさせて送ることができる仕組み（[参考](https://www.itbook.info/study/tcp9.html)）



#### 通信効率の向上（フロー制御）

* スライディングウィンドウにより送信側はどんどんデータを送れるが、受信側の処理能力が追いつかなくなることがある
  * この場合、受信側はウィンドウサイズを小さくし、その値を送り直す
  * 再び処理能力が回復した場合はウィンドウサイズを大きくし、通知する



### UDP

#### UDPの用途

1. 音声や映像などのリアルタイム性のあるデータを転送する場合
2. 複数の相手に同じデータを同時に転送する場合
   * TCPは１対１のコネクションを確立する必要があるのでユニキャストしかでない
   * １対Nの通信を行う際はUDPが適している
3. 信頼性が必要なく、少量のデータを転送したい場合
   * クライアントPCとDNSサーバの通信は、クライアントPCからの１回の問い合わせとそれに対するDNSサーバからの応答１回のデータ転送で通信が完了する
     * このような少数少量のデータ通信に３ウェイハンドシェイクを用いるTCPでは通信ロスが多い

| プロトコル         | TCP                          | UDP                         |
| ------------------ | ---------------------------- | --------------------------- |
| 主な上位プロトコル | HTTP、Telnet、FTP、POP・・・ | DNS、NTP、DHCP，SNMP ・・・ |



### DHCP

### 仕組み

1. はじめは自身のIPアドレスもDHCPサーバのIPOアドレスもしらないので、ブロードキャストでDHCP Discoverメッセージを送る
2. DHCP Discoverメッセージを受け取ったDHCPサーバは、アドレスプールからIPアドレスを選択してDHCPクライアントに提案する（DHCP Offer：ユニキャスト）
3. DHCPクライアントは提案されたIPアドレスを使うことを通知するため、DHCP Requestをブロードキャストで送信する
4. 最後にDHCPサーバはDHCPクライアントが使用するIPアドレスなどの設定情報をDHCP Ack（ユニキャスト）で送信する



#### DHCPリレーエージェント

* DHCPサーバがDHCPクライアントと同一セグメントにいない場合（DHCP DiscoveryやRequest等のブロードキャストメッセージはL3デバイスを越えられない）に使用するルーターに具備されている機能
* ルーターはDHCP関連のブロードキャストメッセージを受け取った場合、ユニキャストに変換してDHCPサーバに転送する



### DNS

#### ドメイン名の構造

![img](https://www.infraexpert.com/studygif/tcpip40.gif)

| ドメインレベル                                 | 説明                                                         | ドメイン名の例                            |
| ---------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------- |
| トップレベルドメイン ( Top Level Domain )      | トップレベルドメイン(TLD)では、国別、地域、 　商用などを表すドメインとなっている。 | jp (日本)　us (アメリカ)　com (商用)      |
| セカンドレベルドメイン ( Second Level Domain ) | セカンドレベルドメイン(SLD)では、組織の種類 　を表すドメインとなっている。ただしトップレベル 　ドメインによりこのポリシーは異なる。 ※1 | co (一般企業) ac (教育機関) go (政府機関) |
| サードレベルドメイン                           | サードレベルドメインでは、具体的な企業名や 　組織などを表すドメインとなっている。ただし、 　トップレベルドメインによりこのポリシーは異なる。 | yahoo (ヤフー) keio (慶応義塾) ntt (NTT)  |
| フォースレベルドメイン                         | フォースレベルドメインは、「ホスト名」に位置づけ 　されるドメインです。一般的にWebサーバであれば 　「www」として、FTPサーバであれば「ftp」とする。 | -                                         |



#### DNSの構成

| DNSの構成 | 役割                                                         | 使用される機器                 |
| --------- | ------------------------------------------------------------ | ------------------------------ |
| DNSサーバ | ドメイン名とIPアドレスの対応表を保持するホスト、 　またはソフトウェアのこと。各階層ごとに存在する。 | Windowsサーバ、Linuxサーバなど |
| リゾルバ  | DNSサーバに問い合わせを行うホスト、または 　ソフトウェアのこと。DNSクライアントとも呼ばれる。 | Windows OSなどのパソコンなど   |



各階層のDNSサーバはプライマリ／セカンダリDNSサーバにより冗長構成を取ることで耐障害性を高めている。両サーバ間では定期的にゾーン転送（あるドメインについてその中のドメイン名とIPアドレスなどが対応づけられたデータベース）を転送して同期をしている。

各DNSサーバ（権威DNSサーバ）へ再帰的に問い合わせるリゾルバをフルリゾルバ、もしくはDNSキャッシュサーバという。フルリゾルバがどの程度キャッシュを持続させるかはTTLの値による。



#### DNSのパケット

リゾルバがDNSサーバに行うドメイン名からのIPアドレスの名前解決にはUDP（ポート番号53）を使用します。一方、DNSサーバとDNSサーバとがゾーン情報のファイル転送を行う場合 TCP(ポート番号53）を使用します。

※ AWSのDNSサービスはRoute53という。53はDNSが使用するポート番号に由来している模様。



#### 名前解決の仕組み

![img](https://www.infraexpert.com/studygif/tcpip42.gif)

* Aレコード
  * ドメイン名に対してIPアドレスを紐付けるレコード
  * Aレコードの逆はPRTレコード
  * １ドメインに複数のIPを紐付けるとDNSラウンドロビンというDNSを用いた負荷分散が可能となる
* NSレコード
  * DNSサーバが使う対応表（ゾーンファイル）の中身で、管理を委託しているDNSサーバの名前が書かれている行のこと
  * 上図では、例えばルートサーバに問い合わせると、ルートサーバは「comであればcomのDNSサーバに問い合わせて」というNSレコードと、「comのDNSサーバのIPアドレスはx.x.x.x」というAレコードを返却し、次の階層のDNSサーバに処理を委譲する

#### 逆引きの仕組み

##### in-addr.arpa [ドメイン](http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3)って何？

[逆引き - Wikipedia](http://ja.wikipedia.org/wiki/逆引き)

> [IPv4](http://d.hatena.ne.jp/keyword/IPv4)の場合、in-addr.arpa [ドメイン](http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3)を使って逆引きが行なわれる。

「in-addr.arpa [ドメイン](http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3)を使って」と書いてありますが、in-addr.arpa [ドメイン](http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3)とはなんでしょう。

http://itpro.nikkeibp.co.jp/word/page/10009069/

> [DNS](http://d.hatena.ne.jp/keyword/DNS)（domain name system）上で逆引きを実現する仕組み。
> ＜略＞
> ホスト名-[IPアドレス](http://d.hatena.ne.jp/keyword/IP%A5%A2%A5%C9%A5%EC%A5%B9)変換の仕組みと同様に，[IPアドレス](http://d.hatena.ne.jp/keyword/IP%A5%A2%A5%C9%A5%EC%A5%B9)に名前を付けたものがin-addr.arpaアドレスである。例えば192.168.0.1は1.0.168.192.in-addr.arpaと表記する。

逆引きを実現する仕組みがin-addr.arpa [ドメイン](http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3)のようです。

正引きの場合は、以下のようにまず「ルートネームサーバ」へ問い合わせて、どんどん問い合わせていき [IPアドレス](http://d.hatena.ne.jp/keyword/IP%A5%A2%A5%C9%A5%EC%A5%B9)をしっているサーバにたどり着きます。

[![f:id:japanrock_pg:20090602203200p:image](https://cdn-ak.f.st-hatena.com/images/fotolife/j/japanrock_pg/20090602/20090602203200.png)](http://f.hatena.ne.jp/japanrock_pg/20090602203200)

逆引きの場合は以下のようになります。

[![f:id:japanrock_pg:20090602203159g:image](https://cdn-ak.f.st-hatena.com/images/fotolife/j/japanrock_pg/20090602/20090602203159.gif)](http://f.hatena.ne.jp/japanrock_pg/20090602203159)
図参照（ http://www.atmarkit.co.jp/flinux/rensai/bind02/bind02.html ）

#### ゾーンファイルとリソースレコード

 ゾーンファイルの書き方についてもある程度知っておく必要がある。

![img](https://www.infraexpert.com/studygif/tcpipz47.gif) 

| 項番 | 項目                     | 説明                                                         |
| ---- | ------------------------ | ------------------------------------------------------------ |
| ①    | $TTL                     | DNSサーバがゾーンファイルのデータをキャッシュする時間を指定（デフォルト：86400秒） |
| ②    | $ORIGIN                  | 対象ドメイン名を補う。例えば「 IN NS ns1.infraeye.com. 」を IN NS ns1 のように省略可。 |
| ③    | @                        | ドメイン名を表す。このゾーンファイルでは @ は「 infraeye.com 」と同じ意味をあらわす。 |
| ④    | ns1.infraeye.com.        | このゾーンファイルのデータを持つプライマリーDNSサーバ        |
| ⑤    | postmaster.infraeye.com. | このドメインの管理者のメールアドレス。管理者との連絡用に使用。 　「 postmaster.infraeye.com. 」 = 「 postmaster@infraeye.com 」 |
| ⑥    | Serial ( 2012062501 )    | ゾーンファイルのバージョンを表す数字。管理者が自由に記載する。ゾーンファイル 　更新日＋管理番号を表す ( YYYYMMDDNN ) の10桁使用が多い。DNS情報を更新 　する場合、このシリアル番号を現在よりも大きな値として更新される必要がある。 　DNS情報を更新した場合、自動で更新される場合はこの更新値を意識する必要はない。 |
| ⑦    | Refresh ( 10800秒 )      | セカンダリDNSサーバが、プライマリDNSサーバにゾーン転送後に 　再度ゾーン情報を取得しようと試みるまでの時間 |
| ⑧    | Retry ( 3600秒 )         | セカンダリDNSサーバが、Refreshでゾーン情報の更新が失敗した場合に 　再度Refreshを試みるまでの時間。 |
| ⑨    | EXPIRE ( 604800秒 )      | セカンダリDNSサーバが、ゾーン情報のリフレッシュができない状態が続いた場合、 　セカンダリDNSサーバが持っているゾーン情報をどれだけの時間利用するかの時間。 |
| ⑩    | Minumum TTL (86400秒)    | 存在しないドメイン名のキャッシュを維持する時間。存在しないドメイン名を問い合わせると 　キャッシュサーバは他の正規な情報と同様、この存在しないドメイン情報も指定時間保持する。 |

＄ORIGINは相対ドメイン名（.で終わらないドメイン指定）に付加されるドメイン名を指定する

#### DNSのパケットサイズ

RFC 1034/1035で標準化されたDNS仕様では、UDPを使用した問い合わせおよび応答メッセージサイズが512バイトまでに制限されている。これは、現在インターネットで広く用いられているIPv4において、64バイトのヘッダーを含む576バイトまでのデータを一度に受信できるデータグラムとして保証することを義務付けられていることに由来する（RFC 791で定義）。

IPパケットのフラグメンテーションが発生する場合、パケットのロスや到着順序の入れ替わりなどを考慮した複雑な処理が必要になる。DNSではこのような処理によって負荷が増大することを避けるため、DNSメッセージサイズについて、UDPヘッダー、IPヘッダーとの合計が576バイトを超えない512バイトを最大サイズとして採用した。

512バイトを超えるDNSメッセージのやりとりには、TCPやDNSの拡張機能であるEDNS0を利用する必要がある。

#### キャッシュとネガティブキャッシュについて

コンピューターシステムなどにおいては、無駄を防ぐために、頻繁に利用されるデータやアクセスコストの高いデータを、例えばメモリーのような高速な記憶領域に一時的に格納しておく機能が利用される。これを「キャッシュ」と呼ぶ。

　キャッシュDNSサーバーでは名前解決の効率を上げるために、名前解決の際に得られた情報を一時的にキャッシュとして保持する。また、検索対象が存在しなかった結果も同様にキャッシュとして保持するが、これは「ネガティブキャッシュ」と呼ぶ。

<iframe id="cxWidget_0.4814542626604681" name="cxWidget_0.4814542626604681" width="100%" height="190" src="https://cdn.cxpublic.com/articleCenterInBody_20190703.html#media=html&amp;asId=0000000164657642&amp;sid=1127153793923352357&amp;width=100%25&amp;height=190&amp;resizeToContentSize=true&amp;useSecureUrls=true&amp;ctx=https%3A%2F%2Fwww.atmarkit.co.jp%2Fait%2Farticles%2F1506%2F02%2Fnews011.html&amp;usi=jgym0pgggm62z834&amp;rnd=1558147528&amp;prnd=k1x30ft4sn14p45q&amp;tzo=-540&amp;parentElementId=cxWidget_0.4814542626604681" scrolling="no" frameborder="0" style="display: block;"></iframe>

DNSの名前解決は、クライアントからの名前解決要求を受けたキャッシュDNSサーバーが、権威DNSサーバー群との間でドメイン名の反復検索を行い、その結果をクライアントに返すことによってなされる。一方で、人気のあるWebサイトのドメイン名などではその名前解決は繰り返し行われることになるため、その度にキャッシュDNSサーバーが反復検索を行うのは、キャッシュDNSサーバーと権威DNSサーバー群の双方にとって効率が悪い。そのためキャッシュDNSサーバーは、名前解決の際に得た情報を一定期間キャッシュとして保持し、クライアントからの問い合わせに対する応答に再利用する。

また、一般的に存在しないドメイン名の検索はキャッシュDNSサーバーと権威DNSサーバーの双方にとって負荷が大きい。そのため、キャッシュDNSサーバーは名前解決要求が否定応答となる（検索対象が存在しなかった）場合にも情報をキャッシュし、その名前の検索を繰り返さないようにする（ネガティブキャッシュ）。

DNSではこれらのキャッシュ機能を用いることにより、名前解決処理全体の効率化を図っている。

#### DNSラウンドロビン

* 1つのFQDNに複数のIPアドレスを紐付け、アクセスがある度に順番に別のIPアドレスを回答する方式
* 単純にIPアドレスを返すと、故障したサーバのIPアドレスも返してしまうため、故障したサーバのIPアドレスが登録されているDNSのAレコードを削除する必要がある

#### サブドメインへの問い合わせに対するDNSの権限移譲について

以下のようにNSレコードとAレコードを登録しておく必要がある

 ![img](https://image.itmedia.co.jp/ait/articles/1501/15/dnstips_subdomain_fig01.gif) 

### HTTP

#### URLの構造

![img](https://www.infraexpert.com/studygif/tcpip46.gif)

| URLの構成 | 説明                                                         |
| --------- | ------------------------------------------------------------ |
| スキーム  | アクセスするプロトコルを指定する部分。HTTPによるWebアクセスを行うためには「http」と入力。 HTTPにSSLを使用した暗号化によるWebアクセスを行うためには「https」と入力。ポート番号443。 WebブラウザでFTPサーバにアクセスしたい場合は「ftp」 と入力する。 |
| ホスト名  | アクセスするホスト名を指定する部分。DNSではFQDNと呼ばれている部分。 　ホスト名の後にポート番号を指定することができる。ポート番号を省略した場合はデフォルトで 　「http」 でアクセスする場合ポート番号に「80」を使用する。つまり、以下の入力結果は同じ意味。 「http://www.infraexpert.com/」＝「http://www.infraexpert.com:80/」 |
| パス      | Webブラウザで表示させたいWebページのファイル名を指定する部分。ファイル名を指定しない場合 　デフォルトで「index.html」のファイル名が呼び出される。つまり以下は同じWebページが表示される。 　「http://www.infraexpert.com/」＝「http://www.infraexpert.com/index.html」 |



#### HTTPリクエストメッセージ

![img](https://www.infraexpert.com/studygif/tcpip48.gif)



| HTTPリクエストの構成 | 説明                                                         |
| -------------------- | ------------------------------------------------------------ |
| リクエスト行         | Webサーバに要求する情報を示す。メソッド、URI、HTTPバージョンの情報がある。 　メソッドとはWebサーバに要求を示すコマンドのこと。URIとはリクエストの対象となるデータ 　を指す情報のこと。HTTPバージョンとは、Webブラウザがサポートするバージョンのこと。 |
| メッセージヘッダ     | WebサーバにWebブラウザの情報を示す。具体的に、Webブラウザ側でサポートする 　データのタイプ、データの圧縮方法、ブラウザの種類などの情報がある。 |
| 空白行               | Webサーバにメッセージヘッダーの終わりを伝えるために使用する。 |
| メッセージボディ     | Webサーバにデータを送るために使用する。例えば、Webページ上で入力欄がある場合 　そこに入力したテキスト情報をWebサーバに送るために使用。入力情報がなければ空白。 |

| メソッドの種類 | 説明                                                         |
| -------------- | ------------------------------------------------------------ |
| GET            | データを取得することをWebサーバに要求                        |
| HEAD           | データそのものは要求せず、メッセージヘッダだけを取得することをWebサーバに要求 |
| POST           | Webサーバに、データを送信                                    |
| PUT            | Webサーバに、ファイルをアップロード                          |
| DELETE         | Webサーバ上にあるデータを削除することを要求                  |
| CONNECT        | 例えばプロキシサーバなどに、トンネルの確立を要求             |



#### HTTPレスポンスメッセージ

![img](https://www.infraexpert.com/studygif/tcpip49.gif)



| HTTPレスポンスの構成 | 説明                                                         |
| -------------------- | ------------------------------------------------------------ |
| ステータス行         | Webブラウザに、Webサーバでの処理結果を伝える。 　HTTPのバージョン、ステータスコード、説明文などの情報がある。 |
| メッセージヘッダ     | WebブラウザにWebサーバの情報を示す。具体的に、サーバの種類 　返信するデータのタイプ、データの圧縮方法などの情報がある。 |
| 空白行               | Webブラウザにメッセージヘッダーの終わりを伝えるために使用する。 |
| メッセージボディ     | HTML文書、画像ファイル、動画ファイルなどのデータを格納するために使用する。 |

| ステータス コード | 説明                                                         | ステータスコード例                                           |
| ----------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 100番台           | 情報 続きの情報があることを伝える。                          | 100 ( Continue ) 続きの情報があるのでリクエストして！        |
| 200番台           | 成功 Webサーバがリクエストに処理できたことを伝える。         | 200 ( OK ) リクエストを無事に処理した！                      |
| 300番台           | リダイレクト 別のURLへリクエストし直すように要求する。       | 301 ( Moved Permanently )                                    |
| 400番台           | クライアントエラー クライアントのリクエストに問題があり処理できなかった事を伝える。 | 404 ( Not Found ) 指定したURLのデータは存在しない！          |
| 500番台           | サーバエラー サーバ側に問題があり処理できなかったことを伝える。 | 503 ( Service Unavailable ) サーバの負荷が高くて処理できない！ |

#### Cookie

#### cookieの概要

動作イメージ(https://triple-underscore.github.io/RFC6265-ja.html)

```
== サーバ → UA ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com

== UA → サーバ ==

Cookie: SID=31d4d96e407aad42
```

サーバーがHTTP(S) Responseに Set-Cookieというヘッダで情報を送ると、UAは後続のHTTP(S) Requestにおいて、Cookieというヘッダにその情報を載せてサーバーに返す。

ただし、UAはSet-Cookieを無視してもいいし、任意のタイミングで内容を破棄してもいい。

##### cookieの属性

属性は、UA側でのCookieの管理方法を規定するためにあります。
サーバーからのSet-Cookieの情報の一部として付与されるので、UAはそれに従います。
（UA側からのリクエスト時には付与されない）

- Path
  - 異なるパスで送るCookieを制御できるため、pathによってサービスが違う場合に使える。
  - ただし、異なるパスへのCookie付与はできてしまうため、完全性は保証されない。
- Domain
  - 指定すると、下位ドメインにまたがってCookieを扱える。
  - サブドメインと共有したい意図がなければ指定するべきでない。
- Secure
  - 一般にはSSL通信専用として扱われる。
  - セッション情報を管理するなら必須。
- Expires
  - 指定しなければ、セッション（定義はブラウザ次第）が終われば破棄される。
- Max-Age
  - ↑とほぼ同じ。定義の仕方が異なる程度。
- HttpOnly
  - jsなどで操作することを許可しない。
  - XSSなどで悪意のあるスクリプトによって値が読み取られることがない。

Cookieは「セッションのためのトークンを保持する」という目的で扱われることが多いので、適宜設定しておく必要があります。

### SMTP&POP

POP3の場合はメール受信の際にメールサーバにユーザ名とパスワードの情報を送信して認証が行われますが、SMTPの場合は認証が行われていません。SMTPが使用されるのがメーラからメールサーバに送信するためだけなら、SMTPでも認証必須で良いかもしれませんがメールサーバ間のメール転送にもSMTPが使用されるため、SMTPがPOP3と同様に認証を必須とした場合、任意のドメインのメールサーバからメールを転送できなくなるのでSMTPは認証を必須としていないのです。これを悪用し、悪意を持った第三者が契約しているメールサーバとは別のサーバからメールを送信することもできてしまいます。



* OP25B

  * OP25Bとは、自身が契約しているISPのメールサーバにメールを送信するのではなく、他のメールサーバに出て行こうとするメールを遮断するものです。スパムメールの多くは、自身の契約したISPのメールサーバを介さずに、インターネット上のセキュリティの甘いメールサーバ（あるいは悪意のあるメールサーバ）に直接送信されていたことから、ISP各社がOP25Bを採用することで、近年スパムメールは減ってきています。

* サブミッションポート

  *   OP25Bはスパムメール対策として、かなり効果のある対策であったのですが、正しく利用しているユーザに弊害のある対策でもありました。例えば、ホテルなどの外出先でインターネット接続する場合、ホテルが契約しているISPのメールサーバを利用できる訳ではないですし、また自身が契約しているISPのメールサーバにアクセスしようとしても、ホテルが契約しているISP側でOP25Bが実施されているのでメールが届きません。この弊害を解決するためにサブミッションポートが利用されるようになりました。サブミッションポートはクライアントPCの「メーラからメールサーバにメールを送信する際に使用する宛先ポート（587）」です。今までと同様にプロトコルにはSMTPを使用しますが、宛先ポートが「25」ではなく「587」を使用します。

      これにより、宛先ポート「587」のSMTPパケットは遮断されている訳ではないので、外出先から自身が契約しているISPのメールサーバにメールを送信できます。ただしこのサブミッションポートでも認証がない場合結局は、スパマーも宛先ポートを「587」に変更してメールを送信すればいいだけとなってしまうので、このサブミッションポート宛てにアクセスしてきた通信にはSMTP認証が行われます。SMTP認証はメールを送信する際にユーザ認証を行い、認証された場合にメールを送信する技術です。サブミッションポートはあくまでメーラーからメールサーバにメールを送る際に使用するポートなので、メールサーバからメールサーバへのメールの送信は引き続き、認証を行わない宛先ポート番号25のSMTPを使用するので全て丸くおさまります。自宅にいる時はSMTPの宛先ポートを25、外出している時にはSMTPの宛先ポートを587にその都度変更るのは手間なので、あらかじめ宛先ポート587に設定しておくのが一般的です。自宅でもサブミッションポートでもアクセスできるので「25・587」のどちらを指定しても問題ありません。プロバイダにもよる。

    　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

### Telnet・SSH

ともにアプリ層のプロトコルでリモートでサーバ操作等を行う際に用いる。Telnetはパスワード情報含め全てのデータが暗号化されないため、現状、主にSSHが使われている。



#### SSHのバージョン

  SSHには2種類あります。SSH1（SSHプロトコル version 1）と、SSH2（SSHプロトコル version 2）。
SSH1とSSH2とでは当初「認証方式」に違いがありました。SSH1ではRSA公開鍵暗号、SSH2ではDSA
公開鍵暗号方式を採用した認証を行っていました。「RSA」か「DSA」なのかが違いとしてありました。

しかし後にSSH2においてもRSA公開鍵暗号による認証が可能になりました。さらにDSAよりRSAの方が
安全性が高いことから、SSH2の認証もRSA公開鍵暗号が主流となっています。これでは、SSH1とSSH2
ともに同じ認証方式を採用しているのでSSHのバージョンの違いがないのではと思われるかもしれないが
SSH1に比較してSSH2の方がより安全性が高いという違いがあります。SSHクライアントとSSHサーバが
SSH1とSSH2をサポートしている場合は「 SSH2におけるRSA公開鍵暗号 」による認証が推奨となります。  



### FTP・SFTP

FTP通信では2つのTCPコネクションを利用しています。1つは制御用、もう1つはデータの転送用となります。
制御用コネクションはコントロールコネクション、データ転送用コネクションはデータコネクションといい、
コントロールコネクションは、ログインするためのユーザ名やパスワード情報やファイルの転送方法などの
命令と応答などのために使用され、データコネクションは転送されるデータの送受信のために使用されます。

![img](https://www.infraexpert.com/studygif/tcpip64.gif)



#### FTPの仕組み

![img](https://www.infraexpert.com/studygif/tcpip65.gif)



⑤のFTPクライアントからのファイル転送の要求に対して、⑥でFTPサーバからデータコネクションの接続を
開始します。この時はポート番号21ではなくて20を使用してアクセスします。また、データコネクションで
FTPサーバから接続要求を行うモードはアクティブモード、FTPクライアントから接続要求を行うモードは
パッシブモードといいます。アクティブモードかパッシブモードを使用するかはFTPクライアントで設定する。
データ転送が終了すると再びコントロールコネクションで処理の終了の制御を行って、FTP接続は終了します。

※アクティブ・パッシブ、はFTPサーバ絡みた場合に積極的か受け身かを考えると分かりやすい。

FTPサーバがインターネットなどの外部にいる場合、外部からの接続要求の開始はFirewallのセキュリティ
ポリシーで許可されない場合があるのでその時は内部から接続要求を開始するパッシブモードを使用します。



### SNMP

SNMPは、管理する側のSNMPマネージャ、管理される側のSNMPエージェントの2つにより構成されます。
SNMPv1、SNMPv2c、SNMPv3のバージョンがあり、SNMPv3ではセキュリティ機能が強化されています。
最近は、サーバなどに高価なSNMPマネージャのソフトウェアをインストールしてSNMPマネージャを導入
するのではなく、クライアントPCに無償のSNMPマネージャをいれて導入するようなケースなどもあります。
※SNMPマネージャには HP Software、Cisco Works、JP1 (HP OpenView NNMのOEM）、PNDDA（低価格）などがあります。



![img](https://www.infraexpert.com/studygif/tcpip69.gif)



#### MIBとは

  MIB (Management Information Base) とは、SNMPエージェントが持っている機器情報の集合体のこと。
SNMPマネージャとSNMPエージェントはこのMIBをやりとりすることで、SNMPエージェントのCPU使用率、
インターフェースの使用状況等を確認しています。MIBにより分類された情報はツリー構造で管理されます。

MIBにある情報の1つ1つをオブジェクトと言います。例えばツリーの上から「iso、org、dod、internet」
などがオブジェクトです。どのオブジェクトもOID (オブジェクトID)で示されます。OIDは、MIBツリーの
階層を通るパスを表すものです。例えばオブジェクトの「dod」は「iso⇒org⇒dod」を辿っていくことから「dod」のOIDは「1.3.6」です。例えば「cisco」のOIDは 1.3.6.1.4.1.9。rootから順にピリオドで区切る。  





![img](https://www.infraexpert.com/studygif/tcpip71.gif)

  このMIBには、標準MIBと拡張MIBがあります。標準MIBは標準化されているものですが、MIB1とMIB2が
あります。現在ではMIB2を使用するのが主流です。拡張MIBはベンダ固有のもの（ciscoなど）があります。

MIBは、SNMPエージェントにて保持しているものですが、SNMPマネージャはエージェントの保持している
MIBの内容から現在の状態を判断するため、SNMPマネージャにも、MIBの情報をインストールする必要が
あります。SNMP管理する機器のMIBの情報（MIBファイル）は、メーカのサイトからダウンロードできます。  



#### RMON(Remote Monitoring MIB)

RMON（アールモン）は、Remote Monitoring MIBの略称です。通常のMIBは、例えばネットワーク機器の
インターフェースや機器単体を監視するパラメータ群から構成されていますが、RMONではネットワークの
回線を監視するパラメータ群から構成されています。RMONにより通信トラフィックの統計情報が得られます。
RMONを利用した代表的なSNMPのアプリケーションはMRTGです。とても有名で役立つフリーソフトウェア。



#### SNMPメッセージ

| SNMPメッセージ  | 送信側           | 意味                                                         |
| --------------- | ---------------- | ------------------------------------------------------------ |
| Get Request     | SNMPマネージャ   | SNMPエージェントから得たい情報を、OIDを指定して要求          |
| GetNext Request | SNMPマネージャ   | 直前に指定したOIDの次のOIDを指定して要求。                   |
| Set Request     | SNMPマネージャ   | SNMPエージェントの設定変更を行いたい場合、OIDを指定して要求  |
| Get Response    | SNMPエージェント | SNMPマネージャから要求されたOIDに対して、値を挿入して返信    |
| TRAP            | SNMPエージェント | SNMPエージェントが機器の状態に変化があった場合、自発的に送信 |



#### SNMPコミュニティ

SNMPコミュニティとは、SNMPで管理するネットワークシステムの範囲のことです。SNMPマネージャと
SNMPエージェントとの間で、同じコミュニティ名にすることで情報を共有することができます。監視対象
ごとに異なるコミュニティ名を設定することにより、効率的な管理とアクセス権限の分離を実現できます。

![img](https://www.infraexpert.com/studygif/snmpz01.gif)



図の通り、コミュニティごとにMIBへのアクセス権限を分けることができます。MIBへのアクセス権限は
RO、RW、Read-write-all の3種類があります。MIBへの書き込み（RW）できるということは、たとえば
SNMPマネージャがSNMPエージェントであるルータを強制的に再起動（MIBへ書込）できるようになります。

| MIBへのアクセス権限 | 説明                                        |
| ------------------- | ------------------------------------------- |
| RO                  | Read-only。MIB情報の読み取りが可能          |
| RW                  | Read-write。MIB情報の読み書きが可能         |
| Read-write-all      | コミュニティを含めてMIB情報の読み書きが可能 |



#### SNMPのバージョン

| SNMPバージョン | RFC         | 説明                                                         |
| -------------- | ----------- | ------------------------------------------------------------ |
| SNMPv1         | RFC 1157    | SNMPコミュニティによる平文認証。SNMPトラップにおける再送確認なし。 |
| SNMPv2c        | RFC 1901    | SNMPコミュニティによる平文認証。SNMPトラップにおける再送確認あり。 |
| SNMPv3         | RFC 2273～5 | ユーザ単位の暗号化されたパスワード認証。SNMPトラップにおける再送確認あり。 |

SNMPv2で使用されるメッセージは、上述の５つだけでなく、以下の２つも定義されている。

| SNMPメッセージ  | 送信側           | 意味                                                         |
| --------------- | ---------------- | ------------------------------------------------------------ |
| GetBulk Request | SNMPマネージャ   | 一括参照要求と言われるように、高速に複数の管理情報を取得。   |
| Inform Request  | SNMPエージェント | SNMPエージェントからマネージャへ通知する時に確認応答も要求。 |



　SNMPv3では、SNMPv2と同じように上記の 7 つのSNMPメッセージを使用することができます。そして、
SNMPv3では、コミュニティ名ではなくUSM（User-based Security-Model）と呼ばれる、ユーザごとの
パスワード認証機能と、VACM（View-based Access Control Model）と呼ばれる、ユーザごとにアクセス
可能なMIBの範囲を定義できる機能が備わっています。

SNMPv3のUSMにおけるユーザ認証には以下の3つのセキュリティレベルがあります。セキュリティレベルの
用語はメーカによって異なります。以下の表は、Cisco機器におけるセキュリティレベルの説明となります。

| セキュリティレベル | 認証       | 暗号化     | 結果                                           |
| ------------------ | ---------- | ---------- | ---------------------------------------------- |
| noAuthNoPriv       | ユーザ名   | なし       | ユーザ名だけを使用して認証。暗号化なし         |
| authNoPriv         | MD5 or SHA | なし       | HMAC-MD5 or HMAC-SHAを使用して認証。暗号化なし |
| authPriv           | MD5 or SHA | DES or AES | HMAC-MD5 or HMAC-SHAを使用して認証。暗号化あり |

SNMPv3を使用する場合、SNMPマネージャとエージェントの両方がSNMPv3に対応している必要があります。



### NTP

  NTPはstratumと呼ばれる階層構造を持っており、最上位のNTPサーバが原子時計やGPSの正確な
時刻源から正しい時刻情報を得て、下位のNTPサーバはそれを参照して時刻同期を行っていきます。
最上位のNTPサーバは「stratum 1」であり、階層を降りるごとにstratumの値が増えていきます。
最大でstratum 15までNTPサーバを構築できます。なお、stratum 16には同期できません。

  ![img](https://www.infraexpert.com/studygif/tcpip80.gif)



#### NTPの仕組み

NTPクライアントは、NTPサーバから伝えられる時刻情報をそのまま自身のシステムクロックに同期させる
訳ではありません。NTP情報はネットワークで伝送されるので遅延が発生しています。このネットワークの
遅延を反映した上でNTPクライアントは時刻同期を行います。以下の4つの時刻情報のやりとりを行います。



| 時間軸 | NTPパケットでやりとりされる４つの時刻情報 |
| ------ | ----------------------------------------- |
| T1     | NTPクライアントのクエリの発信時刻         |
| T2     | NTPサーバのクエリの受信時刻               |
| T3     | NTPサーバの応答の発信時刻                 |
| T4     | NTPクライアントの応答の受信時刻           |



![img](https://www.infraexpert.com/studygif/tcpip83.gif)



上図前提はクライアントとサーバは、まだNTP同期を取っておらず時間にズレ（遅延）があるとします。
また、ネットワーク内の遅延時間が送信と受信とで等しいとします。往復遅延時間は「パケットの往復時間」
から「サーバの処理時間」を引いたものであることから、(T4-T1) - (T3-T2) の公式により2秒となります。
クライアントの時計の遅延時間は上図の時間軸のズレを確認しなくても、公式によっても3秒だと導けます。



### syslog

  syslogはIPネットワーク上でログメッセージを転送する標準規格でありクライアント/サーバ型プロトコル。
syslog送信側（Ciscoルータなど）はsyslog受信側（Linuxサーバなど）にログ情報をテキストメッセージで
送信します。syslogメッセージはUDPまたはTCPポート番号の514を使用してsyslogサーバに送信されます。

  

#### ファシリティとプライオリティ

 ファシリティは正確に言えば「ログの種別」のことであり、分かりやすくいえばメッセージの「出力元」
のことです。ファシリティには以下の種類があり、ファシリティを使用することでメッセージの出力元に
応じてログの出力先を制御できます。Linuxでは「 * 」を使用することで全ファシリティを選択できます。

 

| ファシリティ     | 説明                           |
| ---------------- | ------------------------------ |
| auth、authpriv   | 認証サービス ( login、su など) |
| cron             | cron                           |
| daemon           | 各種デーモン                   |
| kern             | カーネル                       |
| lpr              | 印刷システム                   |
| mail             | メールシステム                 |
| news             | ニュースサービス               |
| syslog           | syslog機能                     |
| user             | ユーザープログラム             |
| local0 ～ local7 | 独自の設定                     |



  プライオリティはメッセージの優先度を表します。プライオリティはemergが最も高く、debugが最も低い
ことを意味します。指定したプライオリティよりもレベルが高いものが全て記憶されるので、例えばcritを
指定した場合、crit、alert、emergレベルのログが記録されます。特定のプライオリティを指定したい場合、
プライオリティの前に = をつけます。noneは例外指定したファシリティのログを除外する役割を持ちます。

 

| プライオリティ | 説明                                     |
| -------------- | ---------------------------------------- |
| emerg          | 非常に危険な状態                         |
| alert          | 危険な状態                               |
| crit           | 危険な状態                               |
| err            | 一般的なエラー                           |
| warning        | システムからの警告                       |
| notice         | システムからの重要な通知                 |
| info           | システムからの情報                       |
| debug          | デバッグ情報                             |
| none           | ファシリティ無効（メッセージを送らない） |



### VoIP

* SIP

  * セッションを確立する際に用いるプロトコル

  * TLSで暗号化するのが一般的

  * UA（User Agent）と呼ばれる端末同士が直接通信できるようにするもの

  * トランスポート層はUDP/TCPの両方に対応しているが、デフォルトはUDP

  * SDP（Session Description Protocol）と呼ばれる記述構文を使ってボディ部を記述する

    *  RTPのIPアドレス情報などをSDPとしてメッセージ・ボディに含めて送信 

  * 相手先を “sip:alice@example.com” のようにURIで記載する

  * IP電話の利用者は事前にSIPサーバのレジストラ（レジスタサーバ）に自身のIPアドレスと電話番号などを登録する必要がある

  * INVITEメッセージのメッセージボディ部の[m]フィールドに自身が用いるポート番号を記載する

    * 相手からのメッセージにもボディ部の[m]フィールドにポート番号が記載されている

  * ボディ部の[a]フィールドを見るとPCMU/8000とある。これは、性符号化方式にPCM（μ-low）を使用しており、１秒間におけるサンプリング回数が8000回であることを表している。

    * サンプリング間隔（周期）は1sを8000で割ればよい
    * PCM符号化方式では音声データを64kbit/sの速度で送る。

    ![SIPメッセージの中身はHTTPベース](https://image.itmedia.co.jp/ait/articles/0711/16/r20_5min_SIP_03.gif) 

* RTP

  * 音声を運ぶプロトコル
  * 暗号化及び認証可能なSRTPにするのが一般的

#### SIPの通話までの流れ

 ![SIPの通話から終了まで](https://image.itmedia.co.jp/ait/articles/0711/16/r20_5min_SIP_04.gif) 

#### 転送する際には

* REFERメソッドを用いる
* REFERリクエストのヘッダにはRefer-toフィールドがあるので、このフィールドに転送先のSIP URIを入れる
* 電話端末X→Y→（転送）→Zとなる場合、Yが転送先のZに対して行う会話をセカンダリコールという

#### プレゼンス機能

* ユーザはプレゼンスサーバに対してPUBLISHメソッドを用い、自身のステータスの登録、更新を行う
* ユーザの状態が更新されたときに通知を受取りたい場合はSUBSCRIBEメソッドを使ってプレゼンスサーバに事前に申し込む
* 申し込んだユーザの状態が変更されたときにはNOTIFYメソッドで通知が届く

#### インスタントメッセージング

* MESSAGEメソッドを用いてメッセージボディに相手に送りたいメッセージを入れて通信する



#### VoIPのよく問われる問題

* NATやFirewallとの相性の悪さ

  * SIPではヘッダ部ではなく、ペイロードに埋め込まれたIPアドレス宛に応答パケットを生成する。通常のNATで変換されるのはヘッダ部のIPアドレスのみであり、ペイロードに含まれたIPアドレスはプライベートIPアドレスであるため、返信パケットがNATへ到着できない。

  * この場合、NATにおいてペイロードに埋め込まれたIPアドレスもグローバルIPアドレスに変換するように機能拡張すればよい。

  * しかし、SIPが暗号化されていた場合、暗号化されたペイロード部のIPアドレスを変換することはできない。

  * 対処方法としては以下が挙げられる。

    * NAT機能を実装している機器（通常、Firewall）で直接、SIPを受ける、つまりSIPのプロキシを行う
    * SIP URIとIPアドレスの関連付けを管理できる機能を持った機器を用意し、DMZ等においてSIP通信を仲介させる

  * 以下がとても詳しいので要参照

    >  SIP要点まとめ（ネットワークスペシャリスト直前対策） | のこのこIT珍道中 https://nokonokonetwork.com/sipvoip%E9%96%A2%E9%80%A3-%E8%A6%81%E7%82%B9%E3%81%BE%E3%81%A8%E3%82%81-%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B9%E3%83%9A%E3%82%B7%E3%83%A3%E3%83%AA%E3%82%B9%E3%83%88 

## Ethernet

### LANの規格

| 規格                 | IEEE         | 媒体アクセス制御方式 | 伝送メディア         | トポロジー   | 伝送速度     |
| -------------------- | ------------ | -------------------- | -------------------- | ------------ | ------------ |
| イーサネット         | 802.3        | CSMA/CD              | 同軸ケーブル         | バス型       | 10Mbps ～    |
| UTPケーブル          | スター型     |                      |                      |              |              |
| 光ファイバーケーブル | 拡張スター型 |                      |                      |              |              |
| トークンリング       | 802.5        | トークンパッシング   | STPケーブル          | リング型     | 4M or 16Mbps |
| FDDI                 | -            | トークンパッシング   | 光ファイバーケーブル | 二重リング型 | 100Mbps ～   |



| 100Base-TX                      |                                                              |
| ------------------------------- | ------------------------------------------------------------ |
| MAC (Media Access Contorl) 副層 | 媒体アクセス制御。MACアドレスのアドレッシング機構を提供する。フレームの 送受信方法、フレームの形式、誤り検出方法なども規定。物理層の上に位置する。 |
| LLC (Logical Link Control) 副層 | 論理リンク制御。イーサネットやトークンリングなどのネットワーク媒体の種類の違いに 関係なく、ネットワーク層からネットワーク媒体を同じ手順で利用できるようにするもの。 |



#### イーサネットの命名規則

イーサネットの規格名は、伝送メディア（ケーブルの種類）や伝送速度により以下の命名規則があります。
ここでは100Base-TXを例に解説します。100Base-TXの読み方は「ヒャクベースティーエックス」です。



| 100Base-TX |                |                                                              |
| ---------- | -------------- | ------------------------------------------------------------ |
| 100        | 伝送速度       | 「10」の場合は10Mbps、「100」の場合は100Mbps、「1000」の場合は1000Mbps。 |
| Base       | 伝送形式       | 「Base」はベースバンド方式の意味。イーサネットでは現在ベースバンド方式以外はない。 |
| TX         | ケーブルの種類 | 数字の場合は最大セグメント長※1、アルファベットの場合はケーブルの種類を意味する。 　「T」はUTP、「F」は光ファイバー、「X」の場合FDDIの技術の使用※2 を意味する。 |

※1　10Base5の最大ケーブル長は「500M」なので「5」ですが、10Base2の最大ケーブル長は「200M」ではなく「185M」です。
※2　100Base-TXはFDDIの物理層規格を借用しているので「X」が名称として付け加えられています。



イーサネットとして、10Base5 ⇒ 10Base2 ⇒ 10Base-Tの順番で標準化されたので当初は同軸ケーブルを
使用したバス型のトポロジーを採用していましたが、バス型のトポロジーでは一箇所に故障が発生した場合
その同軸ケーブルに接続したネットワーク全体が通信できなくなるので、10BaseTが登場してからはすぐに
UTPケーブルとハブ（集線装置）を使用したスター型のトポロジーに移行していきました。以降バス型は衰退。

| 規格名   | IEEE       | 伝送媒体                    | コネクタ | 最大長 | トポロジー |
| -------- | ---------- | --------------------------- | -------- | ------ | ---------- |
| 10Base5  | IEEE802.3  | 同軸ケーブル                | AUI      | 500m   | バス       |
| 10Base2  | IEEE802.3a | 同軸ケーブル                | BNC      | 185m   | バス       |
| 10Base-T | IEEE802.3i | UTPケーブル (2対のCAT3以上) | RJ-45    | 100m   | スター     |



#### ファストイーサネット（100Mbps）

通信速度を100Mbpsにしたイーサネット規格。最も使用されている規格が100Base-TXです。100Base-T4
が使用されることは先ずありません。最大ケーブル長の100mを超える配線が必要な場合は、100Base-FX
が使用されますが、そのような配線は一般的にギガビットイーサネットで行います。なお、100Base-TXに
対応した機器は10Base-Tも対応しており、対向機器の状況に応じ10 or 100Mbpsのどらかを使用できます。



| 規格名     | IEEE       | 伝送媒体                    | コネクタ | 最大長 | トポロジー |
| ---------- | ---------- | --------------------------- | -------- | ------ | ---------- |
| 100Base-TX | IEEE802.3u | UTPケーブル (2対のCAT5以上) | RJ-45    | 100m   | スター     |
| 100Base-T4 | IEEE802.3u | UTPケーブル (4対のCAT3以上) | RJ-45    | 100m   | スター     |
| 100Base-FX | IEEE802.3u | 光ファイバ （マルチモード） | ST       | 400m   | スター     |



#### ギガビット・イーサネット（1Gbps）

通信速度を1000Mbpsにしたイーサネット規格。現在は、エンドユーザのPCとLANスイッチ間の通信速度が
100Mbpsが一般的であることから、バックボーンのネットワークではギガビットイーサネットにすることが
一般的になっています。ギガビットイーサネットには以下の規格がありますが、1000Base-CXは、あまり
使用されることはありませんが、工場などのノイズが多い場所でも高い通信速度を求められる状況では使用。
1000BaseT/SX/LXについては機器が持っているインターフェース、ケーブル配線距離に応じて使用します。



| 規格名      | IEEE        | 伝送媒体                      | コネクタ | 最大長 | トポロジー |
| ----------- | ----------- | ----------------------------- | -------- | ------ | ---------- |
| 1000Base-CX | IEEE802.3z  | STPケーブル                   | RJ-45    | 25m    | スター     |
| 1000Base-T  | IEEE802.3ab | UTPケーブル                   | RJ-45    | 100m   | スター     |
| 1000Base-SX | IEEE802.3z  | 光ファイバ （マルチモード）   | SC or LC | 550m   | スター     |
| 1000Base-LX | IEEE802.3z  | 光ファイバ （マルチモード）   | SC or LC | 550m   | スター     |
| 1000Base-ZX | Cisco独自   | 光ファイバ （シングルモード） | LC       | 100Km  | スター     |



### イーサネットの伝送メディア



### イーサネットフレーム



### スパニングツリー

イーサネット（L2）における経路冗長化技術。 イーサネットにおいて経路を物理的に冗長化するとループが発生するが、各スイッチでSTPを有効化すると論理的にループのないネットワーク（ツリー）を構成できる。また、経路で障害が発生した際には再度、ツリーを構成し直し、自動で経路を切り替えることが可能。

 ![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2017/05/stp-summary1.png) 



近年はリンクアグリゲーションという技術により、L2の経路冗長と同時に負荷分散も可能になりましたので、実装されることは少なくなってきています。 さらに、ポートにPCを挿すだけでもリンクアップが遅れるなどの害もあるので、初期設定で有効なスイッチではそれが理由ですぐに無効にされるケースがほとんどです。STPの中にもPVSTP, Rapid PVSTP, MSTPという、VLAN単位での負荷分散をするものもありますが、リンクアグリゲーションに比べると設定の容易性も機能も劣ります。



#### ルートブリッジの決定

1. STPが有効なスイッチはBPDUを送信する。

2. BPDUは以下のようにブリッジID（8byte）の情報を含む。

   ![img](https://www.infraexpert.com/studygif/stpz3.gif) 

3. 各スイッチは隣接スイッチから送られてきたBPDUのブリッジIDと自信のブリッジIDを比較する。

4. 比較する際はまずブリッジプライオリティを比較し小さいスイッチがルートブリッジとなる。（プライオリティが同じ値であればMACアドレスを比較する）

#### ルートポート（RP）の選出

 スパニングツリーではルートブリッジの選出後、ルートポートと呼ばれるポートを選出することになります。ルートポートは、ルートブリッジに最も近いポートです。非ルートブリッジごとに１ポートがルートポートになります。何をもって最も近いかですが、それは「 ルートブリッジに至るパスコストが最も小さいこと 」を指します。ルートブリッジに至るパスコストの合計値の事をルートパスコストと言います。下図を解説します。ルートブリッジはパスコスト 0 でBPDUを送信します。非ルートブリッジのSWBとSWCのポート①では受信したBPDUのパスコストに自身のコスト値 4 を加算するので、SWBとSWCのポート①のルートパスコストは4 となります。次にSWBとSWCもBPDUを送信し合い、受信したBPDUのパスコストに自身のコスト値 19 を加算するので、SWBとSWCのポート②のルートパスコストは 23 。ルートポートは非ルートブリッジごとに1ポートずつ選出されるので、SWBではポート①がRPになります。そしてSWCではポート①がRPになります。 

 ![img](https://www.infraexpert.com/studygif/stpz5.gif)  



#### 指定ポート（DP）の選出

 スパニングツリーでは、ルートブリッジを選出して、ルートポートを選出した後は指定ポートを選出します。指定ポートは各リンク（セグメント）でルートブリッジに最も近いポートです。以下は指定ポート選出ルール。

　○　各リンクごとに1ポートが指定ポートになります。
　○　ルートブリッジの全てのポートは必ず指定ポートになります。
　○　指定ポートは「最も小さいルートパスコストのRPを持つスイッチ側のポート」が指定ポートになります。下図では、SWA⇔SWB、SWA⇔SWC、SWB⇔SWCの3つのリンク（セグメント）があります。各リンク毎に指定ポート（DP）が選出されます。ルートブリッジの全ポートはパスコストが 0 なので指定ポートになります。次に、SWB ⇔ SWC間の指定ポート（ DP ）の選出ですが、各スイッチのRPのルートパスコストを見るのでSWBのルートパスコストは 4、SWCのルートパスコストは 4 であることから、ルートパスコストは同じです。ルートパスコストが同じ場合には、送信元ブリッジIDの値を比較します。送信元ブリッジIDが最も小さい値のポートが指定ポートになります。SWBの方がブリッジID小さいことからそのポート②が指定ポートになります。 

 ![img](https://www.infraexpert.com/studygif/stpz6.gif) 



#### 非指定ポート（NDP）の選出

 ルートポート、指定ポートにも選出されなかった残りのポートが非指定ポートになります。非指定ポートではデータフレームが送受信されない（BPDUは受信する）ブロッキング状態になり、これでループを回避します。


　　　　　　　　　　![img](https://www.infraexpert.com/studygif/stpz7.gif) 

 ◇　STPツリーは「 ルートブリッジの選出 ⇒ ルートポートの選出 ⇒ 指定ポートの選出 ⇒ 非指定ポートの選出 」のフローで決定。

 　1. ルートブリッジは、ブリッジID（ ブリッジプライオリティ + MACアドレス ）が最も小さい値を持つスイッチが選出される。
  　2. ルートポートは、①各ポートのルートパスコスト ②送信元ブリッジID ③送信元ポートID の順で最も小さい値を持つポート。
  　3. 指定ポートは、①各スイッチのRPのルートパスコスト ②送信元ブリッジID ③送信元ポートID の順で最も小さい値を持つポート。 



### PPP（Point to Point Protocol）

* PPP（Point to Point Protocol)という言葉のとおり、点（Point）から点（Point）への通信プロトコルである。ようは、1対1の通信で利用されるプロトコル。
* データリンク層のプロトコルである。つまり、IPアドレスなどには関与しない。
* アナログ電話やISDNでのダイヤルアップで使われたことが、皆さまには馴染み深いかもしれない。 
* 過去問ではPPPに関して、「WANを介して二つのノードをダイヤルアップ接続するときに使用されるプロトコルで、リンク制御やエラー処理機能をもつもの（H20秋AP午前-問55）」と述べている。
* 過去問では、PPPに関して「リンク確立フェーズの後に認証プロトコルを実行することができる（H20NW午前　問33）」と述べている。ここでいう認証プロトコルはPAP(Password Authentication Protocol)とCHAP(Challenge-Handshake Authentication Protocol)である。
* PAPやCHAPは言葉の通り、パスワード認証プロトコルであり、PAPやCHAPによって、ダイヤルアップにおける認証を行う
* PPPを拡張したのがEAP（Extensible Authentication Protocol）である。
* イーサネット上でPPPを利用するのがPPPoE(PPP over Ethernet）である。

 ![ppp](http://livedoor.blogimg.jp/securityadmin/imgs/c/2/c285398e.jpg) 

1. PAP（Password Authentication Protocol）**
   IDとパスワードを平文で流す

2. CHAP（Challenge Handshake Authentication Protocol）**
   - メッセージダイジェストを使うので、パスワードが暗号化して流れる。
   - 過去問ではCHAPの説明として、「PPPのリンク確立後、一定の周期でチャレンジメッセージを送信することによってユーザ認証を繰り返すプロトコルである（H17NW午前　問29）」と述べている。 

### PPPoE

イーサネット（Ethernet）上のPPPだからPPPoE(PPP over Ethernet)です。。ATM上のPPPも存在し、PPPoAと言います。従来インターネット接続はPPPによるダイヤルアップ接続でした。PPPであれば、ユーザ認証ができるし、どれだけ接続したかの管理（課金管理）も可能です。ところがADSLやBフレッツのように、LAN（イーサネット）で接続する場合は、ユーザ認証ができません。

HUBにつなげば誰でもLANを利用が使えますから、それと同じ理屈ですね。そこで、ユーザ認証機能を持つPPPの仕組みを、イーサネット上でり利用するために、PPPoEが使われるようになりました。過去問では、PPPoEに関して、「シリアル回線で使用するデータリンクのコネクション確立やデータ転送を、LAN上で実現するプロトコル(H19NW午前問 37)」と説明しています。
以下の図を見てください。まず、Bフレッツなどのインターネットの物理的な接続構成は以下のようになっています。
![jpg3](http://livedoor.blogimg.jp/securityadmin/imgs/5/7/575acb44.jpg)

パソコンはルータやONUを経由してNTTなどのキャリアの光回線に接続されます。キャリアでは、BAS（Broadband Access Server）というPPoEを受信する装置があります。PPPのときのRAS（リモートアクセスサーバ）と同じです。そこから、ISP（プロバイダ）に接続されます。認証の流れは以下のようになっています。
PCは通信キャリアのBASにてPPPoE接続をします。PPPoEの設定で入力した「ユーザ名@プロバイダ名」（samon@isp-1.xxx)とパスワードを送信します。NTTのように、ISPのプロバイダが選べる通信キャリアの場合は、BASにて@以降のプロバイダ名を見て、プロバイダに認証を転送します。このときのプロトコルはRadiusです。ここで認証が許可されると、インターネットにプロバイダ経由で接続されます。
![pppoe2](http://livedoor.blogimg.jp/securityadmin/imgs/5/b/5b766fc4.jpg)

PPPoEの処理は、PPPoEサーバであるBASとPPPoEクライアントソフトで実現します。最近のOSには、PPPoEのソフトが入っていますので、ソフトを使っている感覚は少ないかもしれません。以前の古いOSでは、フレッツ接続ツールなどの、PPPoE接続用のソフトを別途インストールしていました。
IPアドレスは、固定で割り当てることも、自動で取得することも可能です。ただし、この自動付与の仕組みはDHCPとは異なります。



### PPTPとL2TP

 インターネット上のIPネットワークで使用されている [ IP ] にはPPPのような認証機能はありません。一方で [ PPP ] はWANのシリアル回線のように、2点間がポイントツーポイント接続されている回線　でしか利用できません。ではどのようにFlet's( IP )網でPPPoEのPPP認証を行っているのでしょうか。それは、PPPフレームをIPデータグラムに埋め込み [ カプセル化 ] して送信を行い、認証サーバーの受信側でカプセル化解除を行うことにより実現しています。このようにある通信プロトコル上で異なる通信プロトコルを透過的に伝送することを [ トンネリング ] と言います。PPPはL2のデータリンク層であることから、この場合は [ レイヤ2トンネリング ] と言われます。L2トンネリングの種類は以下です。
 

| L2トンネリング プロトコル | L2トンネリングプロトコルの開発元            | L2のカプセル化対象 | 暗号化サポート |
| ------------------------- | ------------------------------------------- | ------------------ | -------------- |
| PPTP                      | Microsoft, 3Com, Lucentの開発したプロトコル | PPP                | MPPE           |
| L2F                       | Ciscoの開発したプロトコル                   | PPP                | ×              |
| L2TP                      | IETF標準化( RFC2661 ) - PPTPとL2Fの統合     | PPP                | ×              |

L2F、L2TPなどのL2トンネリングプロトコルには暗号化機能がないことから、暗号化をさせるためにL3トンネリングプロトコルである IPsec を併用します。また、L2Fにおけるカプセル化には、L2Fのヘッダーを使用しますし、L2TPにおけるカプセル化にはL2TPヘッダーを使用しますが、PPTPの場合ややこしいことに、カプセル化にGREヘッダーを使用します。では、詳細を分かりやすく説明します。 

 PPTPでは、発信元のVPN機器をPAC（PPTP Access Concentrator）と定義して、受信側のVPN機器をPNS（PPTP Network Server）と定義しています。PPTPでは、このPACとPNSとの間で、セッション及びトンネルを確立して通信を開始することになります。PPTPの実装 ＝ Microsoftネットワーキングと位置づけられていることもあり、PACとなる実際のVPN機器は一般的に [ Windows 7 / 8 ] などでありPNSとなる実際のVPN機器は一般的にWindows 2008 Server / Windows Server 2012などになります。 

| PPTPにおけるPACとPNSの通信手順 ( Windowsの場合 ) |                                                              |
| ------------------------------------------------ | ------------------------------------------------------------ |
| ①PPP or PPPoE or PPPoA 接続                      | PPP ( ダイヤルアップ、ISDN接続) またはPPPoE ( ADSL/FTTH ) 接続により グローバルIPを取得しインターネット接続を行う。= PNSへのIP到達性の確立 |
| ②トンネルの確立 1                                | PACからPNSへ制御コネクションを確立する。コネクション確立のためにTCPを使用してPAC ( 送信元ポート番号任意 ) からPNS ( 宛先ポート番号1723 ) |
| ③トンネルの確立 2                                | 先に確立したTCPコネクションを使いPPPフレームを送受信するための 　PPTPトンネルを確立する。このPPTPトンネルはGREによるカプセル化を意味する。 |
| ④セッションの確立                                | PPTPトンネルの確立後、PPPセッションを開始してユーザ認証、IPの付与を受ける。 |
| ⑤実際の通信 （IPデータグラム送受信）             | PACであるWindowsクライアントと、PNS配下の社内ネットワークとで通信開始。 |

 ![img](https://www.infraexpert.com/infogif/pptp1.gif) 

### L2F

L2FはPPTP同様に、PPPヘッダーまでがカプセル化の対象となりレイヤー2で動作するプロトコルです。PPTPはトンネル確立のための制御コネクションにTCP、PPPフレームのカプセル化にGREを使用するのに対し、L2Fはトンネル確立のための制御コネクションとカプセル化の両方にUDP(1701)を使用します。現在ではL2Fが使用されることはほぼなく、L2FとPPTPを組み合わせたL2TPを使用するのが一般的です。

　　　![img](https://www.infraexpert.com/infogif/l2tp0.gif) 

### L2TP

L2TPはPPTPとL2Fのトンネリングプロトコルの仕様を統合してIETFにより標準化されたプロトコルです。L2TPはPPTPのトンネル制御とL2Fのフレーム構造に似た方式を採用しています。PPTPでVPNトンネルを構築する際に定義していた発信側となるPACは、L2TPではLAC（L2TP Access Concentrator）と定義し受信側となるPNSは、L2TPではLNS( L2TP Network Server ) と定義しており、このLACとLNSとの間でVPNトンネルを構築します。トンネルとセッションの確立のためにL2F同様にUDP（1701）を使用します。


　　　![img](https://www.infraexpert.com/infogif/l2tp1.gif)

また、PPTPでは1つのVPNトンネルで1つのユーザセッションしかやり取りできませんでしたがL2TPでは1つのVPNトンネルで複数のユーザセッションをやりとりできることからFlet's網などで採用されています。LACとLNSがパスワードを共有 ( Shared Secret ) していれば、L2TPではVPNトンネルの認証もできます。



| L2トンネリングプロトコル | カプセル化           | VPNトンネルの 発信側/受信側 | トンネル認証 | 1つのVPN トンネル |
| ------------------------ | -------------------- | --------------------------- | ------------ | ----------------- |
| PPTP                     | GREを使用            | PAC/PNS                     | ×            | 1つのセッション   |
| L2F                      | L2F/UDP(1701)を使用  | NAS/HG                      | ×            | 複数のセッション  |
| L2TP                     | L2TP/UDP(1701)を使用 | LAC/LNS                     | ○            | 複数のセッション  |



#### 主なVPNプロトコルの比較表

| VPN プロトコル | 何のプロトコル上で 伝送できるか | 何のプロトコルを 伝送できるか | マルチキャスト 伝送は可能か | データ暗号化 完全性保障 | ポピュラーな ソリューション           |
| -------------- | ------------------------------- | ----------------------------- | --------------------------- | ----------------------- | ------------------------------------- |
| IPsec          | IP                              | L3 ( IP )                     | ×                           | ○ IPsecのみでOK         | ＩＰユニキャストの トンネリング       |
| GRE            | IP                              | L3 ( IP. IPX, etc)            | ○                           | × 代替案：GRE/IPsec     | ルーティングプロトコル のトンネリング |
| L2TP           | UDP/IP, IP, ATM, FR             | L2 ( PPP) L3 ( IP, IPX, etc ) | ○                           | × 代替案：L2TP/IPsec    | PPPの延長とした 認証ネットワーキング  |



## IPv4

### MTUとMSSの違い

 ![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2016/12/mtu-mss.png) 

#### MTU (Maximum Transmission Unit)

MTU は [IP](https://milestone-of-se.nesuke.com/nw-basic/ip/ip-address/) ベースの考え方で、NW 機器やホストが送受信できる、**IP ヘッダを含めた最大サイズ**（バイト数）のことを言います。

[Ethernet](https://milestone-of-se.nesuke.com/nw-basic/ethernet/ethernet/) の最大サイズが規格上は "1518 Byte" までであり、Ethernet のヘッダ＆FCS を差し引いた "**1500 Byte**" が大抵の機器のインタフェースのデフォルト値となっています。

しかし、最近は Jumbo フレームという独自規格が出現しており、9000 Byte 等の大きいサイズの指定も増えてきています。

#### MSS (Maximum Segment Size)

MSS は [TCP](https://milestone-of-se.nesuke.com/nw-basic/tcp-udp/tcp-udp-summary/) ベースの考え方で、**TCP ヘッダを含めない最大サイズ**（バイト数）のことを言います。

この設定値は NW 機器にはなく、クライアントやサーバ等の**ホスト端末**に設定が入っています。大抵は MTU の設定に沿って、IP と TCP のヘッダ 40 Byte 分を差し引いた、"**1460 Byte**"になっています。

### ウィンドウサイズとは

TCPウィンドウサイズとは、クライアントやサーバ等のホストがTCP接続する際にどのくらいのパケットを受け入れられるかを示す値です。受信バッファとも呼ばれます。

TCPヘッダにある Window フィールドを使って、「自分がどれくらいの Byte 数の通信を受け入れられるか」を相手に示す仕組みになっています。

MSS は 1 パケット当たりのパケットサイズに影響を与えますが、Window Size は ACK 無しにどのくらいの TCP ペイロード(MSS)を受信できるかに影響を与えます。

以下に Window Size と MSS(≒MTU)との違いを示します。

 ![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2018/12/tcp-window-size-1v2.png) 

#### スライディング Window

**スライディング Window** は、**自身のバッファの懐具合をリアルタイムで相手に伝える仕組み**で、**フロー制御の実装**になります。最初に決定した Window の規定量から、TCP セグメントを受信して処理中のために使用中のバッファを差し引いた値を、同じく「Window」フィールドを使って相手に伝えます。

![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2016/12/sliding-window.png)

その Window フィールドを受信した相手はまたそれに応じたデータ分を、ACK 無しに送ることができます。つまり、**メモリバッファに余裕があるときは窓を開け、余裕が無くなってきたら窓を閉める**動きをするのです。この仕組みにより通信を効率化します。

ただし、これはあくまで、**ホストの受信バッファがこれだけある、という、ホストだけの都合である**ことに注意して下さい。

#### TCP の輻輳制御の実装

##### スロースタートアルゴリズム

前回の例で、いきなり 2MB 分送ると（ホストではなく）ネットワークのキャパシティオーバーになってしまう可能性があります。そうなるとまた効率が悪いので、**ネットワークの都合も考える必要があります**。スロースタートはネットワークの都合を考慮した**輻輳制御の実装**です。RFC5681 で定義されています。

このアルゴリズムを管理するパラメータとして以下2つがあります。共に単位は Byte です。

1. **Congestion Window (CW)**
2. **Slow Start Threshold (SST)**

**CW** は基本的に **MSS の整数倍**です。初期値/MSS の数だけパケットを送信し、送信データが SST の値に達するまで倍に増やしていきます。

閾値を超えたら輻輳を検知するまで、数パケットずつ増やしていき、輻輳を検知した場合は CW は初期値に戻り、SST は RTO 発生直前の CW の半分にセットされます。

このように『増やすときは数パケットずつ足し算、減らすときは掛け算』という方式を "**Additive-Increase, Multiplicative-Decrease (AIMD)**" と呼び、RFC2861 に記述されています。

なお、**輻輳の検知方法としては2つ**あり、1つは RTO の時間が経っても ACK が返されない場合、もう1つは RTO 内だが Dup ACK によりパケットロスが検知された場合です。

![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2016/12/slow-start-algorithm.png)

なお、**Windows10 では、CW の初期値は10\*MSS になったようです**。（Windows8.1までは 4*MSS)



### VRRPの仕組み

**VRRP**とは、Virtual Router Redundancy Protocol の略で、クライアントPC側で1つしか設定できない**デフォルトゲートウェイ(ファーストホップルータ: FHR)を冗長化する技術**です。

具体的には、**VRRP対応ルータ(L3スイッチでも可)を2台以上同じセグメントに併設**し、それぞれ異なるIPアドレスを設定し、それらを**1つのVIP(Virtual IP)アドレスでグループ化**します。VIPは、正常時にMasterとしたいルータの物理IPアドレスと同じにすることが基本です。VIPと同じ物理IPアドレスを持つルータを IP Address Owner と呼びます。**IP Addres Owner は Priority が255 となり、Preemptは無効化できません**。HSRPのようにVIPを物理IPアドレスとは異なるIPにした場合はこれらの制約が無くなります。

このVRRPにより、**クライアントPCからはルータが1台であるように見せかけます**。

ルータが1台故障した際もスタンバイしているルータがVIPアドレスを引き継ぎ、通信を継続させることができます。



 ![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2017/03/vrrp1.png) 



#### VRRPの動作概要

VRRP では VIP に対する仮想MACアドレスは "00:00:5E:00:01:[VRID] という形式になります。**VRID(CiscoではHSRPに倣いグループと呼びます)**はルータへの設定時に指定する必要があります。先程の図の例では、VRID は"30"に設定しており、これを16進数に直すと"1E"となるので、仮想MACアドレスは"00:00:5E:00:01:1E"となります。

PC は[デフォルトゲートウェイ](https://milestone-of-se.nesuke.com/nw-basic/routing/host-routing/)へ送信するためにデフォルトゲートウェイである "10.1.12.1"の MACアドレスを ARP で調べます。これはVIPですので、**MasterルータはそのVIPに対する仮想MACアドレスをARP応答で返します**。するとPCはその仮想MACアドレスへ向けてフレームを送信します。

上記の流れは、R2 が Master ルータが切り替わっても同じ動作になります。

R1の障害時には、Backup ルータであるR2は、R1から定期的に受信していた Advertisement を10秒間まったく受信しなくなると、R1 に障害があったと判断し、自身が Master に昇格します。その際、[Gratuitous ARP](https://milestone-of-se.nesuke.com/nw-basic/ethernet/gratuitous-arp/) により VIP に対する MACアドレス更新を同セグメント全員にブロードキャストします。これにより、素早い切り替えが可能になります。



#### VRRPの切り替わり時間と切り替わりのトリガー

VRRP では Master ルータのみが1秒間隔で Advertisement を送信しますが、Backup ルータは、3秒間この Advertisement を受信できないと、Master ルータに昇格します。

つまり、VRRP の切り替わり時間は3秒で、切り替わりのトリガーはMasterルータのAdvertisement が受信できなくなることです。



### VRFとは

 VRF（Virtual Routing and Forwarding）は、1つのルータ上で独立した複数のルーティングテーブルを保持できる技術です。VRFにより、1台のルータ上でインスタンスごとにルーティングテーブルを保持することができるため、例えばカスタマーごとにルーティングテーブルを保持できます。VRFの技術を実装させることで、IP-VPNのようなWANサービスを実現することができます。IP-VPNでは、MPLSの技術が使用されていますと説明しましたが、その他にも今回紹介するVRFの技術が使用されています。 



### IPSecとSSL

* SSL
  * セッション層で実装
  * アプリケーション依存 例）HTTPはHTTPSのためのSSLを実装
   * SSLに対応していないアプリケーションでSSL通信を行う場合は、専用のClientソフトを入れる必要がある。
   * リモートアクセス向き 
 * IPSec
   * ネットワーク層で実装
   * アプリケーションに依存しない
     - 組織間アクセス向き
   * ユーザ認証方法や、NAPTの仕様が標準化されていない
   * IPSecでリモートアクセスVPN環境を構築する場合、組織内のネットワークにVPNゲートウェイ装置を設置し、ユーザー側のクライアント端末には専用のVPNクライアントソフトウェアを導入する必要がある。さらに、インストール後にはVPNゲートウェイ装置に設定されているパラメータと同じ値をVPNクライアント上でユーザー自身が設定する必要がある。

#### IPSec

##### IPSecを構成するプロトコル

| IPsecプロトコル | 役割                                                         | プロトコル種別      |
| --------------- | ------------------------------------------------------------ | ------------------- |
| AH              | パケットが改ざんされていないかどうか認証を行う。(HMAC) <br />パケットの暗号化はできない。 | IPプロトコル番号 51 |
| ESP             | パケットが改ざんされていないかどうか認証を行う。(HMAC) <br />パケットのペイロード部の暗号化 ( DES or 3DES or AES ) を行う。 | IPプロトコル番号 50 |
| IKE             | 秘密鍵情報の交換を安全に行う。IKEは [ ISAKMP/Oakley ] のこと。<br />つまり、ISAKMPプロトコル上でOakley鍵交換の手順を実装したもの。 <br />Diffie-Hellman鍵交換のアルゴリズムはOakleyコンポーネントの１つ。 | UDPポート番号 500   |

##### IPSecのイメージ

 先の説明どおり、IPsec自体はセキュリティアーキテクチャなので下図の通り枠組み規定しているだけです。
従って、IPsec通信の際に実際に使用するプロトコル、暗号化アルゴリズムを選択していく必要があります。
例えば上記説明したIPsecプロトコルにはAH、ESP、AHとESPの3つの選択肢があるのでそれを選択します。
その他にも、この後のIPsecの解説を読めば分かると思いますが、暗号化、認証、鍵交換などを選択します。 

 ![img](https://www.infraexpert.com/studygif/ipsecz16.gif) 



##### トランスポートモードとトンネルモード

 ![img](https://image.itmedia.co.jp/ait/articles/0011/27/pc-tunnelmode.gif) 

まずSPIであるが、これは前述のとおりだ。ESPを受信した側ではこの値を見て、復号化のための暗号化アルゴリズムと暗号鍵を選び出す。次のSequence Numberは、文字どおりパケットに付ける通し番号である。これは、悪意を持った第三者が通信内容を傍受して得たパケットを、当事者のふりをして送りつけることで、通信を横取りする「リプレイ攻撃（再送攻撃）」に対抗するためのものだ。送信側はパケットを送信するたびに、このSequence Numberをカウントアップしてゆき、受信側でもこの番号の順序を確認することで、不正なパケットを排除する。 

そして最後の認証データは、「完全性の確保」と「認証」の機能を担うものである。この中身は、「MAC（Message Authentication Code）」といわれるデータが入れられる。MACは、通信内容とパスワードを合わせたものに対して、ハッシュ関数と呼ばれる計算方法による演算を施した計算結果である。ハッシュ関数により、任意の大きさのデータから、数十ビットから数百ビットの固定長データが生成される。特にIPSecでは、ハッシュ関数として「メッセージ・ダイジェスト」と呼ばれるものが使われる。メッセージ・ダイジェストは、計算結果から元データを推測できない、どのような元データに対してもそれぞれ違うものであれば同一の計算結果を生じる確率が極めて小さい、という特徴を持っている。メッセージ・ダイジェストの代表的なアルゴリズムとしては、MD5が挙げられる。



##### IPSecで注意すべき点

　IPSec/ESPでは、ESPヘッダが追加され、NAT-Traversalではさらにポート番号変換用のUDPヘッダも追加されるため、IPSecなしで通信する場合と比較して一度に転送可能なデータ量が減少する。送受信するデータサイズが媒体のMTUサイズを超過する場合には、パケットはフラグメント（断片化）される。一般にフラグメントが多数発生するとデータの転送性能に影響を与えるため、可能な限りフラグメントが発生しないようにエンドポイント間で最大のMTUサイズ（PMTU）を検出する仕組みを有するVPNクライアントもある。

　しかし、経路上のルータが最適なMTUサイズ情報を含むICMP（Internet Control Message Protocol）メッセージの通過を拒否している場合は、送信元に最適なMTU値が戻されないため通信ができないことになる。

　VPNクライアントによっては、ネットワークカードを追加、ダイヤラソフトウェア（AOLなど）をインストールする場合に、1度VPNソフトウェアをアンインストールする必要がある。これは、VPNクライアントの仮想アダプタを新しくインストールしたネットワークカードアダプタにリンクさせる必要があるためである。

 ![図3 IPSecVPNで意識すべきMTU](https://image.itmedia.co.jp/ait/articles/0310/18/r20ssl_vpn03.gif) 



##### 運用管理面の注意点

　IPSecVPNでリモートアクセスVPN環境を構築する場合、組織内のネットワークにVPNゲートウェイ装置を設置し、ユーザー側のクライアント端末には専用のVPNクライアントソフトウェアを導入する必要がある。さらに、インストール後にはVPNゲートウェイ装置に設定されているパラメータと同じ値をVPNクライアント上でユーザー自身が設定する必要がある。定義するパラメータには以下のようなものがある。

**・IKE（フェイズ1）パラメータ**

- Diffie-Hellmanパラメータ
- 暗号化アルゴリズム（DES、3DES）
- ハッシュアルゴリズム（SHA1、MD5）
- ライフタイム

**・IPSec（フェイズ2）パラメータ**

- 暗号化アルゴリズム（DES、3DES）
- ハッシュアルゴリズム（SHA1、MD5）
- ライフタイム

**・VPNドメインネットワーク**

**・[DNS](https://www.atmarkit.co.jp/icd/root/23/5786923.html)サーバアドレス／[WINS](https://www.atmarkit.co.jp/icd/root/96/5787496.html)サーバアドレス**

　日ごろIPSecに関してあまりなじみがないユーザーにとって、上記のパラメータを間違いなく設定することは非常に困難である。入力ミスが1つあるだけでVPNコネクションは確立できないのである。このような状況では、管理者がエンドユーザーをサポートする負荷は非常に大きくなる。実際、カスタマがリモートアクセス環境においてIPSecVPNの導入を躊躇（ちゅうちょ）する大きな理由の1つが、エンドユーザーのサポート負荷が大きい点である。これを解決するために、IPSecVPN製品を提供するベンダでは、VPNゲートウェイ側で定義したパラメータをVPNクライアントに配布する機能を提供している。その機能を利用することで面倒なパラメータ設定をユーザーに任せることを解決できる。

　それに対して、SSL-VPNを導入した場合、Webインターフェイスのアプリケーションを利用する限りでは、ユーザー端末にはSSLに対応したブラウザソフトウェアのみインストールされていればよい（現在提供されている環境であれば、実際は何も行わなくてもよい）。しかし、Webインターフェイスのアプリケーション以外を利用する場合は、SSL-VPN装置からJavaアプレットのダウンロードや、Windowsアプリケーションをユーザー端末にインストールする必要がある。特にJavaアプレットの場合、利用するたびにダウンロードする必要があり、さらに起動までに時間がかかる。





#### SSL

##### SSL-VPNの接続方式

1. リバースプロキシ方式

   リバースプロキシは、外部ネットワークからプライベートネットワークにアクセスする方法です。HTTP通信をSSL化したhttpsから始まるURLを入力して、VPN装置にアクセスします。VPNにて発信元のクライアント情報を認証することにより、プライベートネットワークにアクセスできます。頻繁に利用される接続方式で、ウェブブラウザさえあれば構築可能です。

   ただしメールサーバなど、Webブラウザに対応していないアプリケーションには使えません。そのような場合は、VPN装置がアプリケーションから手に入れた情報を画面上に出力するシステムの構築が必要です。

2. ポートフォワーディング

   ポートフォワーディングは、Webブラウザに対応していないアプリケーションにもSSL-VPNを構築できる手法です。ただし、動的にポート番号を変更しなければならないアプリケーションには利用できません。

   あらかじめ許可する端末のIPアドレスとポート番号を定義する必要があるためです。モジュールは、アクセスしてきたアプリケーションのデータを取得できるように設定されます。

   

   ##### ポートフォワーディングの手順

   1. VPN装置にHTTPSでアクセスする
   2. 外部端末にポートフォワーディング用モジュールを追加する
   3. VPN装置との間にSSLトンネルを確立する
   4. アクセスしてきた端末データを取得する
   5. データをVPN装置に送信する
   6. 受け取ったデータを復号化して抽出
   7. 予め登録されたサーバー情報と照合してアクセス先を指定する
   8. サーバーからの応答を受け取ってデータをSSL化する
   9. リモートアクセス端末に送信

3. L2フォワーディング

   ポート番号を動的に変更するアプリケーションにも適用できる方式です。

   IPアドレスやポート番号が記録されたパケットをカプセル化しているため、VPN装置にIPアドレスやポート番号を定義する必要がありません。SSLトンネル確立時は、全てのデータが仮想NIC内を通るように設定されます。

   

   ##### L2フォワーディングの手順

   1. VPN装置にHTTPSでアクセスする
   2. 外部端末にポートフォワーディング用モジュールを追加する
   3. VPN装置との間にSSLトンネルを確立する
   4. アクセスしてきた端末データを仮想NICに送信する
   5. 内部ネットワーク宛の場合、モジュールによってSSL化
   6. SSL化されたデータをVPN装置に送信
   7. 受け取ったデータを復号化し抽出
   8. 抽出したデータをサーバに送信
   9. サーバから仮想NICに返されVPN装置に回送
   10. VPN装置がデータをSSL化する
   11. モートアクセス端末に送信

##### SSLの接続シーケンス

 ![図1 SSLシーケンス](https://image.itmedia.co.jp/ait/articles/0309/13/r20ssl_vpn01.gif) 



##### SSLサーバ証明書とは

 SSLサーバ証明書とは「SSLによる暗号化通信」と「Webサイトの運営者の身元証明」の2つの機能をあわせ持つ電子証明書のことです。発行された電子証明書はWebサーバにインストールして利用します。 

 ![img](https://www.infraexpert.com/studygif/ssl1.gif) 



##### SSLサーバ証明書の導入

SSLサーバ証明書の導入は、通常は以下のようなフローで行います。

1. SSLサーバ証明書を導入するサーバでのCSRの生成
2. オンライン申請、及び各種申請資料の送付
3. 認証局（CA）で、CSRに署名を行いサーバ証明書として発行
4. 認証局（CA）のルート証明書、及び発行されたサーバ証明書の受領とインストール
5. 検証完了後にリリース



##### SSLサーバ証明書を導入するサーバでのCSRの生成 - 用語の理解

| 用語                         | 説明                                                         |
| ---------------------------- | ------------------------------------------------------------ |
| CSR                          | CSR（Certificate Signing Request）は、認証局（CA）に提出する署名要求のこと。 <br />CSRは、「 公開鍵とディスティングイッシュネーム 」を合わせた電子データのこと。 <br />CSRは、SSLサーバ証明書をインストールするサーバ側で生成する。 |
| コモンネーム                 | SSLサーバ証明書をインストールするサーバのURLのFQDN部分のこと。 <br />https:// から一番最初に表示される "/ "までの部分が該当する。 <br />https://www.infraexpert.com/study/　の場合は、www～.comまでが該当。<br />https://192.168.0.100/index.html　の場合は、IPアドレスが該当。 |
| ディスティングイッシュネーム | 証明書の"サブジェクト"に格納されている情報 <br />コモンネーム、Webサイトを運営する組織に関する各種情報 |

##### CSRの概念


　　　　　![img](https://www.infraexpert.com/studygif/ssl6.gif)



　##### ディスティングイッシュネームとは

CSRを生成するためには、以下の情報から構成されるディスティンイッシュネームを決める必要がある。
ここで指定した文字列がそのままサーバ証明書の情報として反映される。下記の項目と入力例については通常のSSLサーバ証明書に適用できる内容であり、EV SSLサーバ証明書の場合は下記の入力例と異なる。



| 項目 | 意味         | 内容                                                         | 入力例              |
| ---- | ------------ | ------------------------------------------------------------ | ------------------- |
| CN   | コモンネーム | サーバにSSL通信する際に入力するブラウザのURL情報。 <br />FQDNまたはIPアドレスを入力する。 | www.infraexpert.com |
| OU   | 部門名       | 部門、部署名など任意の識別名称                               | myhobby             |
| O    | 組織名       | Webサイトを運営する組織の正式英語名称                        | infraexpert Corp.   |
| L    | 市区町村     | Webサイトを運営する組織の所在地                              | Minato-ku           |
| S    | 都道府県名   | Webサイトを運営する組織の所在地                              | Tokyo               |
| C    | 国別番号     | 国別コード                                                   | JP                  |


例えばANAさんでは、EV SSLサーバ証明書ではなく通常のSSLサーバ証明書を利用されているので入力例を見てみます。重要なポイントとして、SSL暗号化通信の際にWebブラウザは指定したURLアドレスと接続先のWebサイトの証明書のCN（コモンネーム）が一致しているどうかを検証します。この値が一致しない場合はブラウザは警告メッセージを表示させます。

　　　　　　　　![img](https://www.infraexpert.com/studygif/sslz6.gif)



##### SSL/TLSハンドシェイク

 ![img](https://www.infraexpert.com/studygif/security42.gif) 

* Client Hello

  SLの通信開始をクライアントからサーバに通知するメッセージ。メッセージに含まれている内容は以下です。

  SSL/TLSのバージョン、乱数、セッションID、クライアントが利用できる暗号化方式と圧縮方法の一覧。

* Server Hello
  クライアントからのClient Helloの送信された一覧情報に基づいて、サーバは使用する暗号化とハッシュ関数のアルゴリズムを決定してクライアントに通知します。Server Helloに含まれている内容は以下の通りです。
  SSL/TLSのバージョン、乱数、セッションID、サーバ側で決定した暗号化方式と圧縮方法の一覧。

* Server Certificate（省略される場合もある）
  サーバからクライアントに向けて、SSLサーバ証明書を送信します。その証明書を発行した認証局の証明書や、上位の認証局の証明書を含むなど、ルート証明書までの証明書リスト（証明書チェーン）を含んでいます。

* Server Key Exchange（省略される場合もある）
  SSLサーバ証明書を保持していないサーバである場合、またはServer Certificateで送信したSSLサーバ証明書に公開鍵が含まれない場合に共通鍵を交換するための公開鍵を送信するメッセージです。

* Certificate Request（省略される場合もある）
  クライアント認証を行う場合、サーバがクライアントに対してクライアント認証用の証明書を送るように要求するメッセージです。Certificate Requestには、サーバが信頼するルート証明書のリストを含んでいます。

* Server Hello Done
  クライアントに対して、Server Helloから始まる上述のメッセージが完了したことを通知します。

* Client Certificate（省略される場合もある）
  サーバからCertificate Requestメッセージを受信した場合にサーバに対してクライアント証明書を送信します。
  この際にルート証明書までの証明書リスト（証明書チェーン）も送信します。

* Client Key Exchange
  クライアントとサーバだけが知り得る共通鍵を生成するために、プリマスタシークレットと呼ばれる乱数情報を生成します。クライアントは、生成したプリマスタシークレットをサーバの公開鍵を使用して暗号化した上で、サーバに送信します。

* Certificate Verify（省略される場合もある）
  Client Certificateメッセージを送信した場合、クライアント証明書に対する署名データとしてこのメッセージを送信します。サーバから、Certificate Requestがなかった場合にはClient Certificateとともに省略されます。

* Change Cipher Spec
  以上のメッセージのやりとりにより、クライアントとサーバだけがプリマスタシークレットを共有したことになります。乱数とプリマスタシークレットを使用して「マスターシークレット」を生成します。そして、このマスターシークレットから共通鍵を生成します。以降は、この共通鍵を使用した暗号化通信を行うことを通知するために、クライアントはサーバにChange Cipher Specメッセージを送信します。

* Finished
  クライアントがサーバ認証に成功して共通鍵を共有できたことをサーバに通知します。

* Change Cipher Spec
  サーバ側でも同様に、受信したプリマスタシークレットと乱数をもとにしてマスターシークレットを生成して共通鍵を生成します。共通鍵を生成できるとクライアントにその旨をChange Cipher Specで通知します。

* Finished
  サーバがクライアント認証に成功して、共通鍵を共有できたことをクライアントに通知します。

##### CRL （Certificate Revocation List） とは

 CRLとは有効期限よりも前に失効させたデジタル証明書の一覧です。有効期限よりも前に失効させるというのは、例えば証明書の誤発行や証明書の秘密鍵紛失で悪用されるのを回避するための処置です。認証局では、そのような証明書をCRLに登録して管理します。CRLは日本語では証明書失効リストと言いますが、正確にはPKIにおける公開鍵証明書のリスト（ 証明書のシリアル番号のリスト ）のこと。 

###### 証明書の有効性のチェック

デジタル証明書が失効していないものなのかをチェックする方法は大きく以下の2パターンがあります。

1. CRLファイルをダウンロードしてローカルチェック
   デジタル証明書の受け取り側は、デジタル証明書とCRLを照合することで証明書が現在も有効であるかを確認できます。CRLは認証局（CA）から定期的に最新情報が配布されるので、それをダウンロードします。クライアント視点から解説すると、サーバ証明書の有効性をチェックする場合、Webサイトなどから受信したサーバ証明書のシリアル番号とCRLに登録された証明書のシリアル番号を照合して有効性を確認可能。


　　　　　![img](https://www.infraexpert.com/studygif/ssl13.gif)


　SSL-VPN接続などでは、クライアントPCから提示されたクライアント証明書の有効性をチェックする場合、
　例えばCisco ASAが指定したCRL参照先に問い合わせ、そのクライアント証明書の有効性をチェックします。



2. OCSP（Online Certificate Status Protocol）によるオンラインチェック

   クライアントがCRLファイルをダウンロードしてチェックする手法の場合は、保存したCRLファイルが最新とは限らないので定期的にダウンロードする必要がありますが、ここで紹介するOCSPを使用したオンラインチェックでは、デジタル証明書の有効性をリアルタイムで確認できて、クライアントの処理も軽くなります。OCSPは、X.509公開鍵証明書の失効状態を取得するための通信プロトコルです。CRLの手法の代替手段として策定された実装です。OCSPクライアントがOCSPサーバ（ OCSPレスポンダ ）に対してデジタル証明書の有効性を確認させることでクライアントが自力でのCRL取得や照合する手間が省けます。


　　　　![img](https://www.infraexpert.com/studygif/ssl14.gif)



### マルチキャスト

#### マルチキャストを有効にする方法

送信元（239.1.1.1）と同一セグメント

* ブロードキャストパケットが届くので、特に設定はいらない。アプリケーション側が勝手に処理する。
* 同一セグメントにはマルチキャストといっても、ブロードキャストと同じ処理になる。（※ここは仕方がない。マルチキャストは、参加した端末のあるルータを選んで送信することができるが、そのルータから先の端末へはブロードキャストと同様になる）

送信元（239.1.1.1）と別セグメントの場合

* ルータでマルチキャストを有効にする。
* 端末では、239.1.1.1からのマルチキャストを受信したいことをルータに告げる。（IGMPを利用）
* ルータが複数ある場合には、ルータ間でのマルチキャストのやり取りを行う。（PIMを利用）
* 実際のマルチキャストの通信はマルチキャストのプロトコルであるPIMを利用する。

##### マルチキャストプロトコル

代表的なものにはPIM（Protocol Independent Multicastがあります。それ以外には、DVMRPなどがある。
大きく２つの種類があります。

1. dense（密な）モード
   言葉のとおり、密な環境で利用する。企業内LANでの利用をイメージすればよい。
   企業内LANは帯域が広いので、すべてのルータにマルチキャストパケットを送りつける。その後、不要なルータからはプルーニング（prune=余分なものを除く）メッセージを受け取り、そのルータを除外する。

2. sparse（希薄な）モード
   言葉のとおり、希薄な環境で利用する。インターネットの世界やWANをイメージすればよい。
   インターネットの世界は帯域が狭いので、Denseモードのように全ルータにに送りつけていては、帯域が足らない。
   そこで、ランデブーポイント（RP）を設置し、RPまで送信する。そこからはツリーが作成される。
   ※ランデブーとはフランス語rendez-vous、「待ち合わせ場所」の意味。
   送信者からRPへ向かって作成される”送信元ツリー”と受信者からRPへ向かって作成される”共有ツリー”が待ち合わせ場所（rendez-vous）にて落ち合うことが語源。

   

##### Ｑ＆Ａ

1. 複数のルータがある場合、端末（ＰＣ）はどのルータと処理をする？
   同じグループ内でＩＰアドレスが大きいほうが代表ルータが選出されます。ＰＣは代表ルータと通信します。
2. 端末からIGMP参加メッセージを送る方法は？
   通常はアプリケーションが自動で実施する。
3. マルチキャストはTCP？UDP？
   UDPです。TCPで使う3wayハンドシェークが行えません。
4. マルチキャストの設定はデフォルトで有効？
   ルータで、デフォルトは無効になっている。つまり、インターネットでは、デフォルトのルータでは、マルチキャストが無効になっているので、使えない。
   IP-VPNサービスにおいても、マルチキャストが使えるサービスもあれば、利用できないサービスもある。その場合、広域イーサなどのL2サービスを利用することも選択肢ですね。

##### 設定メモ

IGMP Snoopingはマルチキャストを利用するL2SWに設定し、有効にする。マルチキャストを有効にしないSWでは無効にする。

具体的には、L3SWの場合、Vlan単位でip pim dense-mode
L2は全体にigmp-snooping、Vlan単位でigmp-snooping enable

##### マルチキャストのMACアドレス、IPアドレス

MACアドレスは IPアドレスから変換される特別なアドレスを使うのです。例えば、224.255.0.1であれば、
01-00-5e-7f-00-01
・「01-00-5e」は固定
・「7f」は2オクテット目の最初の1ビットを0にする。つまり、255は「11111111」→「01111111」=7f
・「00-01」はIPアドレスの3オクッテット目と4オクテット目をそのまま 

IPアドレスはクラスDの先頭4ビットが1110で始まるものです。具体的には、「224.0.0.0 ～ 239.255.255.255」です。

#### IGMP

* IGMP（Internet Group Management Protocol)はルータと端末間において、マルチキャストグループへの参加と脱退手続きを行うプロトコル。過去問では、IGMPに関して「ホストがマルチキャストグループへの参加や離脱を通知したり、ルータがマルチキャストグループへ参加しているホストの有無をチェックするときに使用するプロトコル（H20NW午前　問30）」と述べている。
* IGMPでは、参加メッセージを送信したホストを、マルチキャストのグループごとに管理している。
  ※ただ、実際に管理しているのは1台のホストのみ（Ciscoの場合？Last Reporter)
  なぜ1台かというと、1台以上あるかどうかが重要。すべてのホストを管理する必要がない。1台以上あれば、マルチキャストパケットを受信し、0台であれば破棄する。
* ホストはIGMPの参加メッセージを送るし、マルチキャストのルータもホストに送信し、メンバの参加状態を確認する。ここはversionによっても異なり（たぶん）、動作も複雑なので、ここでの説明は割愛する。 

 ![ネットワークスペシャリスト_IGMP1](http://livedoor.blogimg.jp/securityadmin/imgs/1/c/1c9d62b0.png) 

##### IGMPスヌーピング

 せっかくマルチキャストしていても、ルータ配下ではブロードキャストされてしまう。これを、該当ホストのみに送るための機能がIGMPスヌーピングである。IGMP snoopingに対応した装置（特にL2スイッチがポイント）であれば、該当のグループによみパケットを転送するので、無駄なトラフィックが流れない。マルチキャストの本来の概念だと思う。
※snoopとは「のぞき見する」の意。IGMPパケットをのぞき見（IGMP joinを確認)して、該当ポートにのみマルチキャストパケットを転送する。 



## IPv6

IPv6では、TOSフィールドやチェックサムフィールドはありません。また、IPアドレス空間は、128ビットです。

IPv4網をIPv6で通すためには、6to4によるトンネリング（またはカプセル化）を使う。

### IPv6のアドレス表記

IPv6は、128ビットの値を16ビットずつ「:」を使って8つに区切り、16進数で表す。

例）1111：2222：3333：4444：5555：6666：7777：8888ループバックは::1/128

### IPv6アドレスの種類

IPv6アドレスの種類IPv4との比較も含めて、以下の表に記載する。

|                  | IPv4 | IPv6                                                         |
| ---------------- | ---- | ------------------------------------------------------------ |
| ユニキャスト     | ○    | グローバルユニキャストアドレス <br />ユニークローカルユニキャストアドレス<br />リンクローカルアドレス（リンクローカルユニキャストアドレス） |
| マルチキャスト   | ○    | マルチキャストアドレス                                       |
| ブロードキャスト | ○    | 廃止                                                         |
| エニーキャスト   | -    | △                                                            |



エニーキャストアドレス宛に通信をすると、グループの端末のどれかが応答する。例として、DNSサーバで考えてみましょう。ユニキャストであれば、1台のDSNサーバとしか通信ができません。エニーキャストを使えば、グループのどれかのDNSサーバが応答するので、冗長化および負荷分散がもできます。ただ、実際の機器でこのエニーキャストアドレスを実装している例は多くありません。

リンクローカルスコープあるリンクのみで利用される。ルータを超えない。（例）リンクローカルアドレスリンクローカル（ブロードキャストドメイン内の、隣接するネットワーク）で利用できるIPアドレス。これがあれば、ルータなどで区切られていないネットワーク内の通信が可能になる。アドレス体系はfe80::/10 プレフィックスは常にfe80::/64　
グローバルスコープ通常のアドレス例、グローバルユニキャストアドレス

### プライベートアドレスとグローバルアドレス

以下に整理してみた

|                            | IPv4                                                         | IPv6                                                         |
| -------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| プライベートアドレス       | クラスA：10.0.0.0/8 クラスB：172.16.0.0/12 クラスC：192.168.0.0/16 | ユニークローカルユニキャストアドレス fd00::/8が自由に利用できる。 |
| グローバルアドレス         | 上記以外                                                     | グローバルユニキャストアドレス 2000::/3　※二進数では「001」で始まる |
| （リンクローカルアドレス） | APIPA（Automatic Privete IP Addres）に よる自動プライベートIPアドレス 169.254.X.X | リンクローカルユニキャストアドレス fe80::/10                 |

リンクローカルアドレスは、IPv4のプライベートアドレスやグローバルアドレスとは別に、常に設定される。たとえば、ユニークローカルユニキャストアドレスを設定してみよう。ネットワークの設定でIPv6アドレスを設定する。（※アドレスは過去問のものを拝借）

参考）[traincat.net様]( https://traincat.net/blog/neko/archives/000424.html )の以下の語呂合わせが覚えやすいかも。

> ・fe80::/10：リンクローカルアドレス
>
> > 鉄也を十分リンスしろ
>
> 鉄：fe(鉄の化学式より)
> 也：8
> を：0
> 十分：/10
> リンス：リンク(ローカルアドレス)
>
> ・fc00::/7：ユニークローカルユニキャストアドレス
>
> > FC Tokyo 7人のユニークな住所はプライベートな話題
>
> FC：fc
> Tokyo："o"の部分2箇所から"00"
> 7人：/7
> ユニーク：ユニーク(ローカルユニキャスト)
> プライベート：プライベートIPアドレス

#### IPv6アドレスの詳細

グローバルユニキャストアドレスについてIPv4のグローバルIPアドレスと考えてもらえばいい。

プレフィックスは、グローバルルーティングプレフィックス（nビット）とサブネットID（64-nビット）に分けられる。

上を書き直すとこうなる[グローバルルーティングプレフィックス nビット][サブネットID 64-nビット][インターフェースID 64bit]

たとえば、2001:dc3:222::/48というグローバルアドレスを公的な機関から割り当てられたとする。企業では、サブネットワークとして、任意の番号をつければよい。

### IPv6ヘッダの構成

* IPv4では13項目の情報が存在したが、IPv6では8項目に削減されてシンプルになった。
* シンプルになったからヘッダ長も短くなったかと期待した。しかし、40バイトなので、IPv4ヘッダの2倍である。まあIPアドレスそのものが4倍になり32バイトが必要なので、これは仕方がないだろう。

基本ヘッダ
1)バージョン(4ビット)：バージョン6
2) Traffic Class (8ビット)
3)フローラベル(20ビット)
4) ペイロード長(16ビット)
5)Next Header(8ビット)：
6)Hop Limit(8ビット)：
7)送信元IPアドレス(128ビット）：
8)宛先IPアドレス(128ビット）：

これ以外に、IPsecの機能を持つ場合は拡張ヘッダで行う。基本ヘッダはIPv4と異なって40バイトに固定されている。

基本ヘッダの中のNext Headerに、拡張ヘッダの内容が記載される。
拡張ヘッダの内容は、ホップバイホップオプション以外はルータで確認する必要がない。なので、ルータの処理は軽減される。

##### 拡張ヘッダ

1)ホップバイホップオプション：中継ルータが処理すべきオプションが格納される。内容はあいまい。
2)宛先オプション：宛先ノードが処理すべきオプション。内容はあいまい。
3)ルーティングヘッダ：経由すべきルータを指定するソースルーティングのようなもの
4)フラグメントヘッダ：Path MTU Discoveryにより最適なMTUを調査するためのヘッダ。MTUが分かればそのサイズにフラグメントされる。
5)認証ヘッダ：AHのヘッダを格納　←ここがIPsec
6)暗号化ヘッダ：ESPのヘッダを格納　←ここがIPsec

参考：[日本ネットワークインフォメーションセンター](https://www.nic.ad.jp/ja/newsletter/No32/090.html)

## メールプロトコル

ここは簡単なものは割愛。POPとIMAPの違いは覚えておくこと。

### SMTP

#### SMTPの送信手順

クライアント　　⇒　　　SMTPサーバ

HELO（クライアントのホスト名を通知）
MAIL　FROM（クライアントのメールアドレス）
RCPT　TO（宛先のメールアドレス）
DATA（メールヘッダ＋メール本文）
QUIT（コネクションの終了） 

### APOP（Authenticated　Post　Office　Protocol）

POP3では、パスワードを平文で送っている。APOPはAuthenticated　POPなので、認証されたPOPという意味である。ちょっと直訳とは離れている気がしないでもないが、パスワードを暗号化して送る。ただし、メール本文は暗号化されない。

### POP3S（POP3 over SSL)

APOPはパスワードのみ暗号化されるが、POP通信そのものをSSLで暗号化するのがPOP3Sである。httpに対するhttpsと同じ位置づけで、POP3に対するSSL対応がPOP3Sである。ポート番号は**995**。

H21NW午後1問2の穴埋めにて、ポート番号995のプロトコルを問う出題があった。

メールソフトは対応しているものが多いが、メールサーバ側ではそれほど普及していないのが現実だと思う。
以下がメールソフト（WindowLiveメール）
![pop3S](http://livedoor.blogimg.jp/securityadmin/imgs/6/4/6435147c.jpg)

### PGPとS/MIMEの違い

* PGP
  * 公開鍵と秘密鍵を生成し、公開鍵を受信者に送付する。受信者は公開鍵で複合する。
* S/MIME
  *  S/MIMEは,メールの送信者と受信者の間で公開鍵基盤(以下,PKIという)を利用して,送信者が付与した**ディジタル署名**を受信者が検証することによって,メールとして転送されるデータの完全性の確保と送信者の確認ができる。さらに, PKIは,S/MIMEにおいてメールとして転送されるデータの機密性を確保するためにも利用される。ここで用いられる非対称暗号(RSA暗号)では,秘密鍵と公開鍵が1対1に対応している。ある秘密鍵を使用して暗号化した情報は、秘密鍵と対を成す公開鍵で復号できる。また、公開鍵を使用して暗号化した場合、秘密鍵で復号できる。一般に,非対称暗号は,暗号化するデータ量が多くなると,対称暗号に比べて処理時間が長くなる。効率性の観点から,S/MIMEでは,メールの本文を対称暗号で暗号化し,この暗号化に使用した共通鍵を,非対称暗号で暗号化する。この仕組みによって,送信者が指定した受信者だけがメールを読むことができるので,データ転送の安全性が高まる。


PGPにおいて、公開鍵は正しいという保証はない。
整理すると
①S/MIME
CAが署名することによって、保証される。
「国が許可しているベリサインが署名しているから大丈夫だろう。」
②PGP
信じるしかない。だれも保証しない。
PGPでは互いに署名しあう。PGPで互いに署名しあうサイトも存在し、こまかなルールが決められている。私が信頼する○○さんが署名している△△さんの証明書だから信頼しようという考え。「友達の友達は皆友達」ですね。

ふつうはフィンガープリントを広く配布することで、公開鍵の信頼性を高めている。

■フィンガープリント
直訳すると「指の印刷」とでも言うのであろうか。「指紋」を意味しているのかな。
フィンガープリントとは、ハッシュ値である。
デジタル署名における署名部分と同じ。

「公開鍵」　　　　　　　　　「フィンガープリント」
AAAAAAAAAAAAAAAAAAA　→　　　　　aaa

PGPにおいて公開鍵が信頼できなければ、すべてのセキュリティが崩れる。
そこで、フィンガープリントをメールの署名に入れるなどして広く公開しておけば、
公開鍵をハッシュ化し、フィンガープリントと一致することで正しさを証明できる。

### OP25B

OP25B(Outbound Port 25 Blocking）とは、直訳の通り、外部へのSMTP（25）通信をブロックする（実際には、プロバイダのファイアウォールでブロックしていることでしょう）。これにより、不正メールを防止する。
実際に実行しているのはプロバイダであり、この仕組みを導入したプロバイダは、利用者にその案内を送っていることであろう。
内部のセグメントから外部へのSMTP（25番ポート）通信を拒否するのであるが、内部のセグメントからのSMTPは、プロバイダのメールサーバからのSMTP通信のみで十分との判断からである。ボットネットによる被害が広がる中、自プロバイダ内の感染したPCから外部へのSPAMメールなどを防ぐ狙いである。

プロバイダ外のメールサーバに送りたい場合は、サブミッションポート587を利用しする。ただし、SMTP AUTHを利用する必要がある。




## Wireless LAN

### チャネルとサブキャリア

無線 LAN (Wi-Fi) では 2.4 GHz 帯と 5 GHz 帯を使って相手と通信します。具体的には、これらの周波数帯の中からさらに 20 MHz の幅をもつ『**チャネル (ch)**』を使って通信します。2.4 GHz 帯は最大 4 チャネル、5 GHz 帯は 19 チャネルが使えます。

 ![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2019/07/wifi-summary-02.png) 

現在の無線は **OFDM** (Orthogonal Frequency Division Multiplex) という技術が使われており、この方式では 1 チャネルの 20 MHz 幅の中にさらに小さい帯域で区切った複数の小さい波『サブキャリア』を作り、それらが bit 情報を伝達します。

#### チャンネルボンディングとは

IEEE802.11n 以降では速度向上のために、『**チャネルボンディング**』と呼ばれるサブキャリア数を増やす手法が実装されました。

仕組みとしては単純で、11n 規格では 1 チャネルの 20 MHz の場合は 52 個のサブキャリアを含めますが、2 チャネルを束ねて 40 MHz 幅として 108 個のサブキャリアを使えるようにできるのです。

 ![img](https://milestone-of-se.nesuke.com/wp-content/uploads/2019/07/wifi-summary-12.png) 

チャネルボンディングでは隣り合うチャネルを連続して使うことができるため、分割損が無くなります。隣のチャネルの通信相手が異なる場合は干渉してしまいますが、**チャネルボンディングでは両チャネルが同じ通信相手であるため**、OFDM による効率化的な分離が図れるのです。これによりデータ搬送用サブキャリア数は 2 倍より多くなり、速度は 2 倍以上(108/52 倍) になります。

#### MIMOとは

MIMOとは Multi-Input/Multi-Output のことで、『同一周波数帯の信号をアンテナの数だけ同時に送信する』技術です。 例えば無線 AP と PC が共に、MIMO 用のアンテナを 2 個搭載していれば転送速度は 2 倍になるし、アンテナが 3 個なら 3 倍、4 個なら 4 倍となります。MIMO はチャネルボンディングとは全く原理・仕組みの異なる技術であり、MIMO はチャネルボンディングと同時に利用することが可能です。

MIMO は速度向上だけでなく、精度向上にも貢献します。これは音に例えると、『色々な人が発声する中で、1つの耳で特定の 1 人の声を聞き分けるより、2 つの耳で 2 人の声を聞き分けるほうが易しい』ことを表す**『両耳効果』と似ています**。



### 無線LAN規格

| IEEE802.11 ( 無線LAN規格 ) の詳細 |              |                                                              |
| --------------------------------- | ------------ | ------------------------------------------------------------ |
| IEEE802.11b                       | 伝送規格     | 2.4GHz帯での最大11Mbpsの無線LANの物理層仕様                  |
| IEEE802.11a                       | 伝送規格     | 5GHz帯での最大54Mbpsの無線LANの物理層仕様                    |
| IEEE802.11g                       | 伝送規格     | 2.4GHz帯での最大54Mbpsの無線LANの物理層仕様                  |
| IEEE802.11i                       | セキュリティ | 802.11のMAC層を拡張し、セキュリティ機能と認証機構を強化するための仕様 |
| IEEE802.11e                       | QoS関連規格  | 802.11のMAC層を拡張し、QoS機能を追加するための仕様           |
| IEEE802.11n                       | 伝送規格     | 実効速度100Mbps以上の伝送速度を実現するための仕様（2009年9月標準化） |
| IEEE802.11ac                      | 伝送規格     | 802.11n後継の理論上6.93Gbpsの伝送速度を実現する仕様（2014年2月標準化） |



#### 無線LANの優先制御

* 無線LANのQoSの規格はIEEE802.11eに定められている

* 優先度に基づくQoSを実現するには、優先度の高いキューから順にパケットを送信する

  

### 無線LAN - BSSとESS

無線LANのインフラストラクチャモードで、1つのAPとそのAPの電波内にいる配下の無線LANクライアントで構成されるネットワークを BSS（Basic Service Set）といいます。複数のBSSで構成される無線LANのネットワークは ESS（Extended Service Set）といいます。これらのIDが無線LAN通信で重要となります。


　　![img](https://www.infraexpert.com/studygif/wireless10.gif)



BSSIDとは文字通りBSSのIDです。無線LANにおけるネットワーク識別子の1つであり48ビットの数値です。このBSSIDは通常、その無線LANネットワークのアクセスポイントのMACアドレスと同じものとなります。ESSIDとは文字通りESSのIDです。無線LANにおけるネットワークの識別子の1つであり最大32文字までの英数字を設定できます。ESSIDは無線LANを構成する機器（APや無線LAN端末）に設定する必要があります。


　　![img](https://www.infraexpert.com/studygif/wireless11.gif)



無線LANでは、ESSIDが同じもの同士が通信することができます。ESSIDが異なっている場合、無線LANの電波がお互いに届く範囲であっても、伝送規格や周波数が同じであっても無線LAN間での通信はできません。

※ESSIDにはどのAPにも接続できるANYという特殊なESSIDもありますが、AP側でこの機能を無効にしておくことが一般的。

#### 無線LAN - SSIDとESSIDの違い

SSIDとは無線LANにおけるアクセスポイントの識別子です。ESSIDとは、アクセスポイントの識別子であるSSIDを複数のアクセスポイントを設置したネットワークにおいても使用できるように拡張した識別子のこと。

このように厳密にはSSIDとESSIDの意味は異なりますが、本来、ESSIDの意味であるにも関わらず、SSIDの用語が使用されているケースが多いです。現在の企業ネットワークにおける無線LAN導入の実態を考えますと、無線LAN導入に１台だけのAP導入というケースは少なく「ESSID」を識別子として使用していることが一般的。
※WindowsのバージョンによりSSIDやESSIDの設定項目が「ネットワーク名」という名称になっています。

#### 無線LAN - ローミング

無線LANにおいて、ローミングとは無線LANクライアントが異なるAP間を渡り歩けるような機能のことです。例えば下図の通り、AP1の電波の届く範囲内にいたWLAN端末「Z」が、AP2の電波の届く範囲内に移動した場合でも通信が可能である状態をローミングといいます。このローミングの前提として渡り歩く範囲のAPのESSIDは全て同じであることが必要です。また、使用するチャネルにおいても接続するAPと同じである必要がありますが、最近の無線LAN端末は「使用するチャネルを自動検出」するのでチャネルの手動設定は不要です。


　　![img](https://www.infraexpert.com/studygif/wireless12.gif)




無線LANクライアントがセッションを切らずにローミングができるよう、異なるチャネルのセルを10％～15％オーバーラップさせることが推奨されます。無線LANスイッチ（コントローラ）はこのオーバーラップの範囲を自動調整しますが、無線LANスイッチを導入しない場合は電波調査を行い適切な場所にAPを設置しましょう。
※現在の企業ネットワークで無線LANスイッチ（コントローラ）を導入しないことは、ほとんどありません。


　　![img](https://www.infraexpert.com/studygif/wireless12.5.gif)

※ 有線LAN側のネットワークと継続的な論理接続が維持するローミングにおいても、ローミング時にはAPとの再認証が発生します。
※ 無線LANスイッチを導入した場合、認証方式がWeb認証であっても802.1X認証であってもローミング時に再認証は発生しません。なぜなら、認証成功時の情報を無線LANスイッチに記憶しており、ローミング時にこの情報を利用するので再認証が発生しません。

#### 無線LAN - CSMA/CAとは

CSMA/CAは、Carrier Sense Multiple Access with Collision Avoidanceの略であり、無線LANの通信規格のIEEE802.11a、802.11b、802.11g の通信手順として採用されているものです。CSMAは、CSMA/CDと同様に、通信開始前に伝送媒体上（無線LANでは電波）に、現在通信をしているホストがいないかどうかを確認するというCarrier Sence（CS）、複数のホストが同じ伝送媒体を共有して現在他のホストが通信していない場合は、通信を開始するというMultiple Access（MA）のCSMAです。そして、Carrier Senceにより通信できる状態分かっても CSMA/CA の場合はさらにランダムな時間だけ待機してからデータを送信します。


　　　　　　![img](https://www.infraexpert.com/studygif/wireless16.gif)


無線LANではフレーム衝突を検出できないため、この手法で衝突を回避（Collision Avoidance）します。

WLAN の端末は「ランダムな時間を待ちデータの伝送を開始」としていますが、正確には下図のとおりDIFSと呼ばれる時間において電波を検知しなければ、電波上で信号が流れていないと判断して、その後ランダムな時間（バックオフ）を待ち、データの伝送を開始します。APから端末へと送信される Ack はSIFSと呼ばれる時間を待った後に送信されます。このAckのやりとりで、データの信頼性を高めています。


　　　　![img](https://www.infraexpert.com/studygif/wireless17.gif)


　※IEEE802.11e の EDCA によるQoS制御は、管理者が制御可能な値のIFSやバックオフを調整することにより実現しています。



| CSMA/CAの用語説明 |                                                              |
| ----------------- | ------------------------------------------------------------ |
| ビジー状態        | 電波が使用中である状態。一方、アイドル状態とは電波が未使用である状態のこと |
| バックオフ        | フレームの衝突を回避するために、フレーム送信を待機するランダムな時間 |
| DIFS              | ビジー状態のチャネルから信号が検出されなくなり、アイドル状態に移行したと判断されるまでの時間 |
| SIFS              | フレーム送信間隔における最短の待ち時間。Ackフレームなどは、SIFSを待ってから送信される |


以上のとおり有線LANの半二重で使用されるCSMA/CDと同じように、IEEE802.11a/b/g 通信においては半二重の通信を行っており、ある瞬間においてアクセスポイントが通信しているWLAN端末は一台だけです。人が見ると複数端末が同時に通信しているように見えますが、実際には複数の通信が順番で行われています。

#### 無線LAN - CSMA/CA with RTS/CTS

無線LANでは「隠れ端末」という問題が発生することがあります。下図のとおり、WLAN端末間において電波を通しにくい遮蔽物があったり、WLAN端末間に距離がありすぎて互いの電波を検知できない場合はCarrier Senceによりビジー状態と認識できないため互いにフレームを送出する結果、フレームの衝突が発生していまいその結果、スループットが低下してしまいます。この「隠れ端末問題」を回避するためにIEEE802.11ではRTS/CTSを用いたCSMA/CAで、この問題を解消しています。先ほど紹介したAckによるCSMA/CA with Ackに対して、今回紹介する技術は CSMA/CA with RTS/CTS による無線通信の制御です。



　　　![img](https://www.infraexpert.com/studygif/wireless18.gif)


CSMA/CA with RTS/CTSでは、WLAN端末からのデータ送信が同時に発生しないように、データの送信の許可を求めて（Request To Send）、データの送信を許可する（Clear to Send）という通信制御方式です。下図の通りのフローとなりますが、RTS信号やCTS信号のやりとりが発生するため、CSMA/CA with Ackに比べてスループットは低下することになります。このため、APによってデフォルトで使用しない設定としいる場合もあります。最近ではCSMA/CA with RTS/CTSを使用するかどうかを自動調整するAPもあります。


　　　　　![img](https://www.infraexpert.com/studygif/wireless19.gif)


CSMA/CA with RTS/CTSは、隠れ端末問題の回避だけでなくIEEE802.11bと11gの混在している無線LAN環境でも役立つ実装です。11b のWLAN端末は11g のOFDM方式を解読できないため、11g のWLAN端末がデータ転送をしていることを認識することができずデータを伝送しはじめる結果、フレームの衝突が発生し、スループットが低下する結果となってしまうのですが、CSMA/CA with RTS/CTSにより衝突を回避できます。

#### 無線LAN通信の流れ

IEEE802.11フレームには制御フレーム、管理フレーム、データフレームの大きく3種類がありますが、上図で紹介した、無線LANの通信のフローにて使用される IEEE802.11の管理フレームの詳細を見ていきましょう。IEEE802.11の管理フレームにはBeacon,　Association Request,　Association Response,　Probe Request,  Probe Response,　Disassociation,　Authentication,　Deauthentication など意外に多くの種類があります。



|      | 無線LAN通信の流れ                                            | 使用されるIEEE802.11フレーム                                 |
| ---- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| ①    | WLAN端末が利用できる周波数帯域を自動スキャンする             | APから100ミリ秒ごとに送信されるビーコンの情報を 　もとに、利用できるチャネルの情報、及びESSIDの情報 　を得ている。ただし、一定時間ビーコンが得られない場合 　プローブ要求とプローブ応答で上記の情報を得ている。 |
| ②    | WLAN端末とAPがお互いに一致するESSIDであるか確認              |                                                              |
| ※    | 複数のAPが存在する場合、WLAN端末は全チャネルをスキャンして、最も信号の強いアクセスポイントとの接続を試みる。 　通信の途中でも現在のAPよりも信号の強いAPを検知した場合、WLAN端末はより信号の強いAPとの接続を試みる。つまり、 　複数のAPを近距離で設置した場合、WLAN端末は何度も再接続したりして、快適に通信ができない場合もあるので注意！ |                                                              |
| ③    | WLAN端末とAPがお互いに認証を行う                             | お互いに認証パケットで認証を行っている。 ※1 なお 　オープンシステム認証とシェアードキー認証の2種類ある。 |
| ④    | WLAN端末とAPがお互いにアソシエーションを行う                 | アソシエーション要求と応答によりこれを行っている             |
| ⑤    | 暗号化したIEEE802.11フレームを、電波に乗せて伝送する         | WEP or TKIP or CCMP による暗号化を行い伝送される             |
| ⑥    | APでIEEE802.11フレームをEthernetフレームに変換し伝送         | ここでようやく管理フレームではなくデータフレームが伝送       |

※1　この2種類の認証はIEEE802.11における内容であり、当然ながら例えば IEEE802.11i には当てはまる内容ではありません。

WLAN端末とAPとの無線LAN接続手順は以下の2パターンあります。パッシブスキャンではAPからブロードキャストされるビーコンフレームを受信してESSIDの確認をし合いAuthenticationのフェーズに移行します。アクティブスキャンでは、APから一定時間ビーコンを受信できなかった場合にWLAN端末が接続を行いたいESSIDの情報をプローブリクエストで送信しAPからその応答が得られれば、Authenticaionのフェーズに移行します。パッシブスキャン、アクティブスキャンのどちらでも認証フェーズ以降は同じシーケンスとなります。


　　　　　![img](https://www.infraexpert.com/studygif/wireless26.gif)



どのような認証方式、暗号化方式であったとしても無線LAN接続における基本的なフローは上記の通りです。使用チャネル、変調方式、ESSIDの相互確認がとれた後、「認証 → アソシエーション → データのやりとり」という基本的なフローをまず理解して、それぞれの詳細な認証方式、暗号化方式のフローを理解しましょう。

※ WPAやWPA2のセキュリティ規格を使用する場合、アソシエーション後に暗号化を行うための鍵の生成プロセスが開始されます。

### WEP (Wired Equivalent Privacy) とは

WEPとは、無線LAN通信において使用される暗号化技術です。WEPは、RC4 アルゴリズムをベースとした共通鍵暗号を採用しています。暗号化の際には**64ビットまたは128ビット**の共通鍵が使用されます。無線LANではこの共通鍵をWEPキーと呼んでおり、送信側と受信側で正常に暗号化と復号を行うために同じWEPキーを設定する必要があります。同じWEPキーを設定していないとデータの中身が見えない（正常な通信が不可）のでWEPキーは一種のパスワードと考えることもできます。また、WEPはデータの暗号化だけではなくデータの完全性を保証する為にCRC32アルゴリズムを使用します。



| WEPの特徴                             |                                                              |
| ------------------------------------- | ------------------------------------------------------------ |
| 共通鍵暗号の使用                      | RC4 アルゴリズムをベースとしている                           |
| 一種の認証機能                        | 送信側と受信側とで同じWEPキーを設定する必要があるため        |
| 共通鍵の長さ                          | 40bit または 104bit のデータサイズ                           |
| 最終的な鍵の長さ                      | 64bit または 128bit (共通鍵のデータサイズに24ビットの IV が加えられる) |
| WEPキー(共通鍵)の文字数 - 40bit       | ASCII文字を使用する場合、5文字。16進数を使用する場合、10文字。 |
| WEPキー(共通鍵)の文字数 - 104bit      | ASCII文字を使用する場合、13文字。16進数を使用する場合、26文字。 |
| WEPの脆弱性                           | 脆弱なパケット(Weak IV)を入手できればWEPキーが解読可 (FMS攻撃） |
| ICV (Integrity Checksum Value) の使用 | CRC32 アルゴリズムを使用する。実質的に改ざん検知ができない。 |



#### WEPによるデータの暗号化 & データの完全性の保証

WEPではデータの完全性を保証するために、IEEE802.11フレームのデータ部分からハッシュ値を計算します。CRC32により求められたハッシュ値をICVと言います。このICVを、下図の通りDataとFCSの間に挿入します。WEPではデータの暗号化のために、RC4により先のICVとデータ部分を暗号文とします。あわせて、暗号化で使用される共通鍵の生成を担う24ビットのIVをIEEE802.11ヘッダとDataの間に挿入して最終形態になります。


　　　　![img](https://www.infraexpert.com/studygif/wireless27.gif)

データの暗号化のためには、「キーストリーム」なるものが必要となります。キーストリームは、管理者が設定するWEPキー(40bit or 104bit)と IV(24bit)で　構成されたものをPRNG(擬似乱数ジェネレータ)を通して生成されるものです。そして、そのキーストリームとDataとICVをそれぞれ排他的論理和(XOR)を求めることで、最終的な暗号データが生成されることになります。


　　　　　　![img](https://www.infraexpert.com/studygif/wireless28.gif)



| セキュリティ規格       | WEP ( IEEE802.11 )                                           | WPA                                                | WPA2 ( IEEE802.11i )                               |
| ---------------------- | ------------------------------------------------------------ | -------------------------------------------------- | -------------------------------------------------- |
| 規格策定の団体         | IEEE802.11                                                   | Wi-Fiアライアンス                                  | IEEE802.11i                                        |
| 規格策定の時期         | 1997年                                                       | 2002年10月                                         | 2004年6月                                          |
| 暗号化方式             | WEP                                                          | TKIP                                               | CCMP                                               |
| 暗号化アルゴリズム     | RC4                                                          | RC4                                                | AES                                                |
| 暗号鍵の長さ           | 40 or 104bit                                                 | 104bit                                             | 128bit                                             |
| 認証鍵の長さ           | -                                                            | 64bit                                              | 64bit                                              |
| IVの長さ               | 24bit                                                        | 48bit                                              | 48bit                                              |
| 整合性の検証           | CRC32                                                        | MIC                                                | CCM                                                |
| アンチ ・ リプレイ攻撃 | なし                                                         | あり                                               | あり                                               |
| 認証方式               | ① オープンシステム認証 　② シェアードキー認証 　③ オープンシステム認証 　＋ IEEE802.1x認証 | ① PSK (Pre-Shared Key) 認証 <br />② IEEE802.1x認証 | ① PSK (Pre-Shared Key) 認証 <br />② IEEE802.1x認証 |



### WPA

WEPの脆弱性が見つかった後のWEPの後継。

| 暗号化方式         | WEP (セキュリティ規格 ： WEP)                              | TKIP (セキュリティ規格 ： WPA)                               |
| ------------------ | ---------------------------------------------------------- | ------------------------------------------------------------ |
| 暗号化アルゴリズム | WEPによるRC4 (暗号の解読が容易）                           | TKIPによるRC4                                                |
| 整合性の検証       | WEPによるCRC32 (実質的にデータの改ざんを検出できない）     | TKIPによるMIC                                                |
| 認証方式           | WEPそのものにはないが IEEE802.1X認証を採用することができる | PSK (Pre-Shared Key) 認証、または IEEE802.1X認証を採用することができる |

 TKIPが優れた暗号化方式であるとはいえ、暗号化アルゴリズム自体はWEPと同様にRC4を採用しています。ただしTKIPではWEPよりも複雑な方法により暗号鍵を生成しています。暗号鍵のもとになるTemporal Keyをダイナミックに生成して、この暗号鍵と送信者のMACアドレスと IV を組み合わせてハッシングを行います。

 ![img](https://www.infraexpert.com/studygif/wireless35.gif) 
　　　 

#### WPAの接続シーケンス

 WPAでは、無線LANクライアント（ = Supplicant ) と、アクセスポイント ( = Authenticator ) との間で以下の接続処理が行われます。アルゴリズムが複雑なので①と②に焦点をあて解説します。③～⑤における接続処理は簡単にいえば、Supplicant Authenticatorとで使用される「鍵を生成」しているということです。

1. アソシエーション処理　-　WPAにおける各種情報の共有
2. PMK (Pairwise Master Key) の共有　-　WPAで使用する様々な鍵のもとになるマスター鍵の生成
3. PTK (Pairwise Transient Key) の生成　-　 ユニキャスト通信で使用される鍵情報の生成
4. GTK (Group Transient Key) の生成　-　マルチキャスト、ブロードキャスト通信で使用される鍵情報の生成
5. Temporal KeyとData MIC Keyの生成　-　暗号化用のTemporal Key、改ざん検知用のData MIC Keyの生成


①のアソシエーション処理では、無線LAN端末とアクセスポイントとでWPAの情報共有と双方の認証をします。最初にSupplicantからAuthenticatorにプローブ要求を送信します。プローブ要求を受信したAuthenticatorはプローブ応答を返します。その際にRSN IN (Robust Security Network Information Element) の情報を付加します。このRSN INにAuthenticatorがどのような暗号化や改ざん検知をサポートしているかのセキュリティ情報が入ります。この情報を受け取ることで Supplicant と Authenticator はWPAに関する情報を共有します。
 

 ② のPMKの共有は、上記のアソシエーション処理の完了後に行われます。WPAでは、色々な鍵を使用して通信するのですがPMK (Pairwise Master Key) はこれらのもとになるマスターキーです。WPAの認証方式にPSK認証を使用する場合は、パスフレーズで設定したPSK (Pre-Shared Key) がPMKとして使用されます。IEEE802.1X認証を使用する場合、802.1X認証成功後に配布されるセッション鍵がPMKとして使用されます。
※WPAでのPSK認証のことをWPAパーソナルモード、WPAでの802.1X認証のことをWPAエンタープライズモードといいます。



#### WPA-PSK認証

PSK認証は、無線LANクライアントとアクセスポイントにあらかじめ手動でPSKを設定する必要があります。ここで設定する「ネットワークキー/ネットワークセキュリティキー」は正確にはPSKではなくパスフレーズなのですが、WPAではこのパスフレーズからPSKを自動生成します。パスフレーズは8文字以上63文字以内で指定する必要があります。ちなみに総務省では、21文字以上のパスフレーズの設定を推奨としています。
※ アクセスポイントがWPA-PSKの暗号化でAESも対応している場合、アクセスポイントも無線LAN端末もAESを選択した方が良い。 

#### WPA-IEEE802.1X認証

IEEE802.1X認証では無線LANクライアントやアクセスポイントに手動で認証鍵の情報を設定したりしません。
IEEE802.1X認証では認証成功後に認証サーバ（Radiusサーバ）が自動的に生成しクライアントに配布します。IEEE802.1X認証方式に応じEAPの種類や「ネットワーク認証方法の選択」の設定を変更する必要があります。



| Windows Vista / 7 - 設定画面                            |
| ------------------------------------------------------- |
| ![img](https://www.infraexpert.com/studygif/win702.gif) |


IEEE802.1X認証方式では、上の暗号化方式の設定以外に、以下の認証方式と認証情報の設定が必要です。
※ EAPの種類で「スマートカードまたはその他の証明書」を選択した場合、認証方式にEAP-TLSの方式を選択したことになります。



### IEEE802.1x用語

IEEE802.1Xとは、有線LANや無線LANにおけるユーザ認証の規格です。当初は有線LANでクライアントPC
をネットワーク接続する際にユーザ認証を行う目的で策定された規格なのですが、無線LANの初期においては
WEPによるセキュリティしかなかったため、WEPにはないユーザ認証などの仕組みが無線LAN環境において
セキュリティ的に最適であったことから有線LANよりも無線LAN環境で先に普及しました。 

#### サプリカント Supplicant

無線LANのクライアントです。パソコンやスマホになります。

#### 認証機 Authenticator

サプリカントが接続する機器です。無線LANのアクセスポイントです。

#### 認証サーバ Authentication Server

認証機が接続する機器です。ここでユーザID/パスワードが認証されます。
実際のところはRADIUSサーバです。これをActive Directoryドメインコントローラに任せます。

#### RADIUS - Remote Authentication Dial-In User Service

認証と認可、さらに課金管理（アカウンティング）のプロトコルです。デフォルトでは、認証と認可はUDP 1812番ポート、アカウンティングはUDP 1813番ポートで通信します。

#### EAP - Extensible Authentication Protocol

様々な認証方式をサポートするPPPです。

### 認証方式

サプリカントによって使える認証方式が違います。
Windowsだと、以下のものが使えるようです。

| Type |    認証方式    |                                                              |
| :--: | :------------: | :----------------------------------------------------------- |
|  13  |    EAP-TLS     | EAP-Transport Layer Security                                 |
|  25  |      PEAP      | Protected EAP                                                |
|  26  | EAP-MS-CHAP v2 | EAP-Microsoft Challenge Handshake Authentication Protocol version 2 |

EAP-TLSが最も強固ですが、クライアント証明書を運用したりしないといけないので面倒です。
EAP-MS-CHAP v2が一番簡単だそうです。

方式自体は、全部で何十個もあります。

#### PEAP - Protected EAP

混沌としたEAP界に現れたCisco/Microsoft/RSA Security連合による認証方式です。
しかし、versionが0から2まであって、混沌を生んでいます。

PEAPの中で、さらに以下の認証方式を選ぶことができるようになっています。いよいよもってわかりません。

- TLS
- MS-CHAP v2

上の項でEAP-MS-CHAP v2が使えるようなことを書きましたが、実際は使えません。
PEAPの中でEAP-MS-CHAP v2を使います。

#### EAPoL - EAP over LAN

レイヤ2上でEAPを通すプロトコルという理解で良いのかな？
知らなくても大丈夫です。

#### WPA EnterpriseとWPA2 Enterprise

暗号化方式/暗号化アルゴリズムが違います。

|                 | 暗号化方式 | アルゴリズム |
| :-------------: | :--------: | :----------: |
| WPA Enterprise  |    TKIP    |     RC4      |
| WPA2 Enterprise |    CCMP    |     AES      |



### 実際の環境構築に必要なもの

#### WPA/WPA2 Enterpriseに対応した無線LANクライアント

PCのスペック表を眺めて、対応しているかどうか調べてください。
USB等で後付けする際は、購入時の確認をお忘れなく。

#### WPA/WPA2 Enterpriseに対応した無線LANアクセスポイント

#### RADIUSサーバ

Windows Serverであれば、ネットワークポリシーサーバ(NPS)機能を有効にすると使えるようになります。

#### 信頼されている証明書

無線LANクライアントから信頼(知っている認証局から発行)されている証明書が必要です。RADIUSサーバで使います。

買うと結構なお値段がするので、オレオレ認証局を作って運用するのもありです。

#### IEEE802.1x認証イメージ

 ![img](https://www.infraexpert.com/studygif/wireless43.5.gif) 

#### IEEE802.1x プロトコルスタック

 ![img](https://www.infraexpert.com/studygif/wireless44.gif) 

| 各層             | 説明                                                         |
| ---------------- | ------------------------------------------------------------ |
| データリンク層   | 802.1X認証を行うための物理的なネットワーク。有線LAN接続、無線LAN接続のどちらでも利用できる。 |
| EAP層            | EAPがデータリンク層とAuthentication層の仲介をしています。EAPOL (EAP over LAN) は、有線LANや 　無線LANにてEAPを使えるようにするプロトコルであり、データリンク層のメディアの違いを吸収している。 |
| Authentication層 | 802.1X/EAPでサポートする認証方式。有線LANと無線LANではEAP層が仲介するので、どの認証方式でも 利用することができる。現在のところ、TLS、MD5、TTLS、PEAP、LEAP、EAP-FASTなどがある。 |

 ![img](https://www.infraexpert.com/studygif/wireless45.gif) 

#### 認証の流れ

 ![img](https://www.infraexpert.com/studygif/wireless46.gif) 

1. 無線LANクライアント（サプリカント）は通信を開始するために、AP（認証装置）にプローブ信号
   （プローブ要求）を送信します。このタイミングで無線LANクライアントが実行したい認証方式を要求。
2. APは無線LANクライアントから指定された認証方式を通知して、EAP処理を開始します。
3. 指定された認証方式に従い無線LANクライアントと認証サーバとの間でやりとりします。この時点
   では、直接トラフィックをやりとりせずに、APが両者のトラフィックをプロトコル変換をしています。
4. 認証が成功すると認証サーバから認証が成功したことを通知。この時にポートのブロックが解除。
5. 認証サーバはアクセスポイントに対して、ユーザ用のセッション鍵のもとになる情報を送信します。
6. APは認証サーバから受信したセッション鍵の情報から暗号鍵を生成し、無線LANクライアントに配布。
7. 802.1X認証が無事に終えて、かつトラフィックを暗号化するための鍵を手に入れたので通信を開始。 



802.1X/EAP認証には色々な種類がありますが、実際によく使用されている方式はTLSとPEAPといえます。MD5はサーバ認証が行わないので、クライアントが不正なサーバにアクセスしてしまう可能性があるだけではなく、動的WEPにも対応していないのでセキュリティ的に非常に弱く導入企業を見たことがありません。LEAPは辞書攻撃の脆弱性が発覚したことがありベンダーとして提案できません。

| 認証方式 | クライアント 認証    | サーバ 認証          | 認証局 | 動的 WEP | セキュリティ | 特徴                                                         |
| -------- | -------------------- | -------------------- | ------ | -------- | ------------ | ------------------------------------------------------------ |
| MD5      | ユーザ名/ パスワード | なし                 | 不要   | 不可     | ×            | Windows PCで標準搭載 <br />チャレンジレスポンスによる認証 <br />サーバ認証なし、WEPキーは固定 |
| LEAP     | ユーザ名/ パスワード | ユーザ名/ パスワード | 不要   | 可       | △            | Cisco独自の認証方式 <br />EAP-MD5よりもセキュリティが高い <br />辞書攻撃による脆弱性が発覚 |
| TLS      | 証明書               | 証明書               | 必要   | 可       | ◎            | Windows PC で標準搭載 <br />最もセキュリティレベルの高い方式 <br />証明書発行などのスキルが要求される |
| TTLS     | ユーザ名/ パスワード | 証明書               | 必要   | 可       | ○            | 対応していないWindows製品がある <br />ユーザIDと証明書のハイブリッド認証 <br />TLSの拡張版 |
| PEAP     | ユーザ名/ パスワード | 証明書               | 必要   | 可       | ○            | Windows PCで標準搭載<br />ユーザIDと証明書のハイブリッド認証 <br />人気のある認証方式 |



## ルーティングプロトコル

### RIP

* ディスタンスベクター型
  * メトリック値（ルータの数）で最短経路を判断する。（デメリットである場合もある）
    ディスタンス（距離）とベクター（方向？）なので、距離と方向という考えもできる。
* ホップ数を使う。最大ホップ数は15。
* 30秒毎に経路情報を交換する（レギュラーアップデート）。
* UDPによるブロードキャストで実施する。 
* RIPv2では**サブネットマスク**に対応した

### OSPF

 ダイナミックルーティングプロトコルには大きく2つのタイプのルーティングプロトコルがあります。1つはディスタンスベクタ型ルーティングプロトコルです。もう１つはリンクステート型ルーティングプロトコル。リンクステート型ルーティングプロトコルには、OSPFとIS-ISがあります。日本の企業ネットワークで最も使用されているリンクステート型ルーティングプロトコルはOSPFです。ちなみに、ディスタンスベクタ型、リンクステート型以外にもCisco社独自のハイブリッド型（拡張ディスタンスベクタ型）というのもあります。

ディスタンスベクタ型プロトコルのRIPでは、最大ホップ数が15であり拡張性がない点、VLSMに対応していない点、コンバージェンス（収束）が遅い点などから大規模なネットワークには適していません。そこで、大規模なネットワーク用として以下に紹介するリンクステート型ルーティングプロトコルが開発されました。リンクステート型ルーティングプロトコルではホップ数制限がなく、拡張性もあり、収束も高速になります。

 リンクステート型ルーティングプロトコルではルーティングテーブル作成のために次のステップを踏みます。

1. Helloパケットを送信し合い、隣接ルータとネイバー関係を確立し、ネイバーテーブルを作成。

2. 全体のネットワーク構成を知るために、そのネットワーク上の全てのルータから情報（LSA）を収集。

3. その収集したLSAをトポロジテーブルに格納する。そして、その情報からトポロジマップを作成。

4. そのトポロジマップから、SPFアルゴリズムによりSPFツリーと呼ばれるネットワーク構成図を作成。

5. そのSPFツリーから最短経路を計算し、最短パスをルーティングテーブルに登録。 

   ![img](https://www.infraexpert.com/studygif/linkstate2.gif) 

 ※　下図のトポロジテーブルは、OSPFでは LSDB（ Link State Database ）と呼ばれています。 

 ![img](https://www.infraexpert.com/studygif/linkstate3.gif) 

 ディスタンスベクタ型ルーティングプロトコルでは、30秒間隔で全ての経路情報をアップデートしますがリンクステート型ルーティングプロトコルでは、30分間隔でLSAごとに同期を行うので負荷が少ないです。リンクステート型ルーティングプロトコルではトポロジに変更があった場合、トリガードアップデートで即時にLSAをネットワーク内の全てのルータにアドバタイズします。そのLSAを受信した各ルータは、そのLSAをトポロジテーブルに格納 ⇒ トポロジマップの作成 ⇒ SPFツリーの作成 ⇒ ルーティングテーブルの更新を行います。トポロジチェンジの際は変更部分だけを差分アップデートするので帯域消費が少ないです。 

 ![img](https://www.infraexpert.com/studygif/linkstate10.gif) 

| 項番 | OSPFの特徴                 | 説明                                                         |
| ---- | -------------------------- | ------------------------------------------------------------ |
| ①    | マルチベンダーのサポート   | RIP同様にIETF標準化プロトコルのため、異メーカのルータ間でもOSPF通信が可能。 |
| ②    | リンクステート型プロトコル | リンクステート型ルーティングプロトコル。                     |
| ③    | 高速なコンバージェンス     | トポロジ変更時に高速なコンバージェンスを実現。               |
| ④    | メトリックにコストを使用   | リンクの帯域幅を基に算出するコストをメトリックとして使用。   |
| ⑤    | VLSMのサポート             | 通知する経路情報にサブネットマスクを含められるクラスレスルーティングプロトコル。 |
| ⑥    | 手動経路集約のサポート     | エリア境界ルータ（ABR）やAS境界ルータ（ASBR）上で、手動で経路集約を行える。 |
| ⑦    | エリアによる階層設計       | LSAを交換する範囲を示す論理グループであるエリアの概念に基づき階層設計が可能。 |
| ⑧    | 差分アップデート           | 定期的なアップデートはせずトポロジ変更時に差分のみマルチキャストでアップデート。 |

##### エリアとは

 OSPFのエリアは「LSAを交換する範囲を示す論理グループ」のことです。つまり、「同じLSDBを持つOSPFルータの論理グループ」とも言えます。各エリア内では詳細なリンクステート情報を保持しますが、エリアの分割により異なるエリアには集約した情報だけを通知すればよく、LSAのフラッディングを限定的にできます。その結果、OSPFルータの負荷が軽くなります。このエリアの範囲は管理者が手動で定義することができます。 

| エリア分割によるメリット         | 説明                                                         |
| -------------------------------- | ------------------------------------------------------------ |
| LSDBサイズの縮小                 | 同一エリア内の全てのOSPFルータは、同じLSDBを保持するが、エリア分割によって OSPFルータは異なるエリアのLSAを保持しなくなる。結果、各ルータで保持している 　LSDBのサイズを小さくすることができるため、ルータのメモリ使用率を抑えられる。 |
| SPF計算頻度の減少                | エリア内では詳細なリンクステート情報を保持するが、エリア分割により異なるエリア には、集約した情報だけを通知すれば良い。トポロジ変更時のLSAのフラッディングは 　同一エリア内に抑えられることからSPF計算頻度も減少し、CPUの使用率を抑制できる。 |
| ルーティングテーブルのサイズ縮小 | エリアを分割することにより、異なるエリアへは複数のルート情報を経路集約して送ることができるため、ルーティングテーブルのサイズを縮小しメモリ使用率を抑えられる。 |

 OSPFは自律システムとエリアで構成されます。OSPFでいう自律システムとは、共通のプロトコルを使用して経路情報をやりとりするルータのグループのことです。OSPFのエリアは、エリア 0 (バックボーンエリア）に他のエリアが隣接する構成となります。エリア 0 を中心とした2階層の構成となります。なお、規模が小さいネットワークではエリア 0 だけを使用するシングルエリアとして構成しても問題はありませんが、ルータの負荷軽減のために大規模ネットワークの場合、複数のエリアを使用するマルチエリアの構成が推奨となります。 

##### OSPFのルーターのタイプ

 OSPFのマルチエリアの構成では以下の4種類のタイプがあります。OSPFを稼働しているルータはいずれかのタイプに当てはまりますが1台のルータが複数のタイプに該当することもあります。例えばエリア0に配置したルータの全てのインタフェースをエリア 0 に接続している場合、内部ルータ兼バックボーンルータとなります。 

 ![img](https://www.infraexpert.com/studygif/linkstate14.gif) 

 ![img](https://www.infraexpert.com/studygif/linkstate15.gif) 

 実際にOSPFを使用してネットワーク設計する場合一般的にWANをエリア0（バックボーンエリア）に各拠点をエリア1、2、3 ・・というように割り当てしていきます。そうすることで、全てのエリアは必ずエリア 0 （バックボーンエリア）と隣接します。また、そのネットワークセグメント設計においては各エリアのネットワークセグメントを/24として設計して、ABR（境界ルータ）上で /16 に経路集約して、異なるエリアにその拠点のネットワークを通知します。 

##### OSPFパケットフォーマット

 ![img](https://www.infraexpert.com/studygif/linkstate16.gif) 

| OSPFヘッダ   | 説明                                                         |
| ------------ | ------------------------------------------------------------ |
| バージョン   | 使用しているOSPFのバージョン。IPv4なら 2、IPv6なら 3 の値。  |
| タイプ       | OSPFの5つのパケットタイプ1 ～ 5。Helloパケットの場合は 1 の値。 |
| パケット長   | ヘッダを含めたOSPFパケットの長さ。                           |
| ルータ ID    | ルータを一意に識別する32ビット値。デフォルトでは有効なI/Fで最大のIPが選択される。 |
| エリア ID    | Helloパケットが送出されるインターフェースが所属しているエリアの32ビット値。 |
| チェックサム | エラーチェックのためのチェックサム計算に使用。               |
| 認証タイプ   | 認証なしなら 0 、平文認証するなら 1 、MD5認証するなら 2 の値となる。 |
| 認証         | AuType 1 または 2 の場合はパスワード情報が含まれる。2 ならKey IDも含まれる。 |



##### 5種類のパケット

OSPFでは以下の5種類のパケットを隣接ルータとやり取りして、動的にネイバー関係を確立した上で、ネイバーテーブル、LSDB、ルーティングテーブルを最新に保つことができます。

| タイプ | パケット名 | 各パケットの説明                                             |
| ------ | ---------- | ------------------------------------------------------------ |
| 1      | Hello      | Helloパケットは、ネイバーを検出するためのパケット。ネイバーを検出してネイバー関係を確立した後の 　キープアライブ（ネイバー維持）としても使用される。マルチキャスト ( 224.0.0.5 ) として送信される。 |
| 2      | DBD        | DBD（Database Description）パケットは、自身のLSDBに含まれているLSAのリスト一覧。ネイバー ルータとこのDBDを交換し合うことにより、自身に不足しているLSAが何なのかを認識することができる。 |
| 3      | LSR        | LSR（Link State Request）パケットは自身のLSDBに不足しているLSAがあった場合、ネイバールータに 　その特定のLSAを要求するために使用される。 |
| 4      | LSU        | LSU（Link State Update）パケットは、LSRによりネイバーから要求されたLSAを送信するために使用。 |
| 5      | LSAck      | LSAck（Link State Acknowledgement）は、LSUを受信したことを通知するための確認応答として送信。 |

 ![img](https://www.infraexpert.com/studygif/linkstate17.gif) 

| OSPFデータ            | 説明                                                         |
| --------------------- | ------------------------------------------------------------ |
| ネットワークマスク    | Helloパケットを送出するインターフェースのネットマスクの情報が含まれる。 |
| Helloインターバル     | OSPFルータがHelloパケットを送出する間隔。デフォルトで 10秒 または 40秒 の値。 |
| オプション            | 8つあるオプションフィールドのうち、スタブエリアを意味するフラグ値を格納。 |
| ルータ プライオリティ | DR/BDRの選択時に使用される 8 ビット値。最高値は255。0 の値はDR/BDRになれない。 |
| Deadインターバル      | ネイバールータがダウンしたとみなす間隔。常にHello間隔の4倍となる。 |
| DR                    | DRのIPアドレス。そのネットワーク上でDRが存在しない場合は 「 0.0.0.0 」 値となる。 |
| BDR                   | BDRのIPアドレス。ネットワーク上でBDRが存在しない場合は 「 0.0.0.0 」 値となる。 |
| ネイバー              | ネイバー関係が確立済みである全てのネイバールータのルータIDの一覧。 |

 OSPFルータには、識別のためにルータIDが割り当てられます。ルータIDは32ビットの値でIPアドレスと同様4オクテットで区切り10進数で表記します。ルータIDは重複しないよう割り当てる必要があります。ルータIDの決定は以下の優先順位 ① → ② → ③で決定します。上図では明示的に①を設定した事を前提としています。

1. router-id コマンドで設定した値
2. ループバックインターフェースの中で最も大きいIPアドレス
3. アクティブなインターフェースの中で最も大きいIPアドレス 



OSPFルータは2Way State状態になり[DR/BDRの選出](https://www.infraexpert.com/study/ospfz7.html)が完了すると、アジャセンシー関係（Adjacency）に至るルータ間では、LSAを交換してLSDBを同期するフローに移行します。そのフローを以下で解説します。

| Step | State          | 説明                                                         |
| ---- | -------------- | ------------------------------------------------------------ |
| ④    | Exstart State  | 起動後状態。どちらのルータからLSAに関するデータの送信を開始するかを決定するプロセス。 　ルータIDが大きいルータから送信を開始。送信開始側をマスター、もう一方をスレーブと呼ぶ。 |
| ⑤    | Exchange State | 交換状態。マスターからDBD（LSDBに格納されるLSAリスト）パケットを送信し相手からも送信。 |
| ⑥    | Loading State  | ロード状態。受信したDBDと自身のLSDBを比較し、不足分のLSAについてはLSRで情報を要求。 |
| ⑦    | Full State     | 完全状態。隣接ルータと完全にLSDBを同期できた状態。これにより同期プロセスが完了。 |

 ![img](https://www.infraexpert.com/studygif/linkstate23.gif) 





##### DRとBDR

 OSPFでは、イーサネットのようなマルチアクセスネットワークでDR (Designated Router) と呼ばれる代表ルータと、BDR (Backup Designated Router) と呼ばれるバックアップ代表ルータが選出されます。DR、BDRに選出されなかったOSPFルータはDROTHERと呼ばれます。LANごとにDRとBDRを選出して、DR、BDRとだけの間でLSAを交換するようになることから LSA を交換するネイバールータを減らせます。

 ![img](https://www.infraexpert.com/studygif/linkstate19.gif) 

 ※　どのOSPFルータもネイバー関係は確立されますが、上図の通り、LSAを交換するネイバーはDRとBDRだけになります。 

 DRとBDRの選出にはOSPFプライオリティ値が使用されます。OSPFプライオリティ値はHelloパケットに含まれており、OSPFルータがHelloパケットを交換して2Way Stateになった後にDR/BDRが選出されます。DRとBDRの選出はOSPFプライオリティ値が使用されます、その値が同じ場合にはルータIDを使用します。

1. OSPFプライオリティ値が最も**大きい**ルータがDRになる。
2. OSPFプライオリティ値が2番目に大きいルータがBDRになる。
3. OSPFプライオリティ値が同じ場合、ルータIDが**最も大きい**ルータがDR、２番目に大きいルータがBDR。

※ OSPFプライオリティ値はデフォルトで 1 です。なお、OSPFプライオリティ値が 0 のOSPFルータは必ずDROTHERになります。

下図の場合、R1とR2が最もプライオリティ値が高く同じ値ですが、R1とR2ではルータIDがR2の方が大きいのでR2がDRとなってR1がBDRとなります。DR/BDR選出後は、全てのOSPFルータはDROTHERとなります。 

DRとBDRはセグメントごとに選出されます。OSPFプライオリティ値はインターフェースごとに設定するのであるOSPFルータはセグメント1ではDRとなっても、セグメント2ではDROTHERになっている場合もあります。 

 ![img](https://www.infraexpert.com/studygif/linkstate21.gif) 

##### 障害発生時のDR、BDRの動作

 ![img](https://www.infraexpert.com/studygif/linkstate22.gif) 

| 項番 | 説明                                                         |
| ---- | ------------------------------------------------------------ |
| ①    | R1 のインターフェースでネットワーク（192.168.1.0/24）にダウンが発生したことを検知。 |
| ②    | R1 は、192.168.1.0/24 のLSAを更新したLSUを、セグメント1 のDR/BDRへマルチキャスト（224.0.0.6）で送信。 |
| ③    | LSUを受信したDR（R3）は、セグメント1 の全OSPFルータへマルチキャスト（224.0.0.5）で送信。 |
| ④    | このフラッディングされたLSAをエリア内に伝搬するために、R3 はセグメント2のDR/BDRへ（224.0.0.6）で送信。 |

④以降は同一エリアの範囲内で②～④の流れが繰り返されます。なお、②のLSUをセグメント１のBDRであるR4が受信した後、Waitタイマーをセットした上で、DR（R3）からも同じLSUが送信されてくるのを待ちます。このWaitタイマーが切れるまでにLSUを受信できない場合、DRがダウンしたと判断しBDRがDRへ昇格します。 

 OSPFの使用用語において、隣り合い接続するルータの関係のことを、近接接続、隣接接続、ネイバー接続、アジャセンシと色々な呼び方をしたり、Full State、2Wayなどがありますが実際には2種類の概念だけです。マルチアクセスネットワークでDR/BDR間とはアジャセンシーを確立し、DROTHER間ではネイバーを確立。

 ![img](https://www.infraexpert.com/studygif/linkstate24.gif) 



### BGP

* 自律システム間で利用するルーティング
* AS間のルーティングなので組織内の情報は伏せられている。組織内の情報とは、IPアドレスとサブネットマスク情報。そこで、AS番号だけでルーティングする。
* 経路が変化したときだけ、その差分を送信する。
* AS間の通信を扱うBGPでは信頼性の高さが求められている（TCP179番ポートを使う）。※OSPFはIP上で直接動作するので、TCPやUDPという概念はない。
* BGP(Border gateway protocol)の直訳は、境界ゲートウェーイでのプロトコルという意味。つまり、ASの境界において、他のASとルーティング情報を交換するプロトコル。
  * BGPスピーカ：BGPが設定されているルータ。同一AS内にはBGPで動作するルータとOSPFなどのIGPで動作するルータが混在することが一般的である。
  * IBGP（Internal BGP)：AS内のBGP。つまり同一AS番号でのBGP
  * EBGP(External BGP)：AS間のBGP。例えば異なるプロバイダ間でのBGP
    ※なぜ、IBGPとEBGPで分ける必要があるのか？
    AS間は別のISP同士と思えばいいので、管理者が別になる。ということは設定も各々がバラバラ。バラバラで通信できるような設定が必要。AS内では同一管理者が一環したポリシーで設計できるので、冗長化などの高度な設定が可能。

#### AS_PATH属性について。

ルート情報は、ASを経由するごとに、経由したAS番号を付加していきます。これにより、複数の経路情報があるときに、どちらが最短かを判断する基準の一つになります。また、自分のところにルーティング情報が帰ってきても、ループを発見できます。

ルート情報の例

1. AS1からルーティング情報を発信
   1.1.1.0/16[AS番号 1]
2. AS2を経由して転送
   1.1.1.0/16[AS番号 1] [AS番号 2]
3. AS3を経由して転送
   1.1.1.0/16[AS番号 1] [AS番号 2] [AS番号 3]

※ルート情報に自分のAS番号があれば、ループであることがわかる。
※このようにパス属性を用いた経路制御のことをパスベクタ型という。