（１）複数機器のログを時系列で確認するため

NTP×ログ解析ときたら→「複数機器＆時系列」という組み合わせが王道。複数機器同士で異なる時間軸を使ってしまうと、ログを時系列で確認できなくなってしまう。そのため、同一の時間軸を使うことでしっかりとログの前後関係が明確になり、事象を追いやすくなる。

（２）登録したFQDNやIPアドレス宛ての通信をブロックするため / 利用者認証を行うため / Webサイトへのアクセス履歴の確認のため

▼p.16

そもそも、プロキシの目的は、アウトバンド（内→外）の通信に対して「誰が、どこに、何を」といった情報を検査することである。
「誰が」を担当するのが認証、「どこに」はURLフィルタリング、レピュテーションが担当し、「何を」はSSLインスペクション、DLPなどが担当する。
要は、認証、フィルタリング、ログ収集という３つの主要な役割がある。それを本文中から見つけてあげればよい。

（３）L3SWのDHCPリースログ

FWの通信ログにもIPアドレスは記載されている。しかし、社内IPアドレスは概して動的に一時的付与であることが多い。そのため、不正通信が発覚した時刻に使われていたIPアドレスの利用者と現在の当該IPアドレス利用者ではリース時間の関係で異なる可能性がある。そのため、DHCP機能を有したL3SWのDHCPリースログを確認する必要がある。

▼PC（MACアドレス）を特定するコマンド

#DHCPバインディングテーブルの表示
show ip dhcp binding

#DHCPバインディングテーブルで192.168.1.50を含む行のみ表示
show ip dhcp binding | include 192.168.1.50

#Syslogの中でDHCPが含まれている＆192.168.1.50が含まれているログを出力する
show logging | include DHCPD.*192.168.1.50

（３）a:Syslogサーバ　b:認証サーバ

これは暗記問題。SyslogはUDP514で認証サーバ（RADIUS）は1812,1813番を使う。以下は、よく耳にするプロトコルなのでしっかり確認しておこう！

（４）c:10080　d:443

cの10080については本文中にプロキシは10080を使うと明示されている。dに関しては、SaaSへの通信なので、443を使う。

内部セグメントからK社SaaSへの直接通信なので、プロキシは経由しない。

設問２

（１）SWGサービスのルート証明書

SWGサービスのルート証明書というと短すぎてよくわからないので、細かく言うと、「SWGが（偽の証明書を発行するために）運用している『プライベート認証局（CA）』の『最上位（ルート）CA証明書』」ということ。
SWGはSSLインスペクションによってPCとWebサーバ間の通信を監視したい。そのためにはクライアントにとって、SWGがあたかも本物のWebサーバであるかのような振る舞いをする必要がある。その際に、SWGのルート証明書が必要になる。

▼SSLインスペクションの裏で起きていること

１．クライアントからSWGに転送
　クライアント内のエージェントがSWG経由の対象である通信（https://example.com）をキャッチすると、SWG宛てになるようにカプセル化を行う。元のパケットの宛先はWebサーバのまま保持。
　なおURLがhttpsの場合はTLSが使われるため、クライアントはTLSハンドシェイクのClient Helloを送信する
２．SWGに届く
　SWGに届くとカプセル化が解除され本物のパケットが出現する。その中のSNI（ServerNameIndication）を読み取りクライアントがアクセスしようとしている宛先ホスト（example.com）を特定する。
３．SWGと本物Webサーバ間でTLSハンドシェイク
　SWGはクライアントに変身する前に、SWG自身でWebサーバとTLSハンドシェイクを実施し、当該Webサーバのサーバ証明書を検証する。
４．SWGによる偽サーバ証明書の作成
　本物のサーバ証明書をもとに、SWGは内部に保持している「プライベートCAの秘密鍵」を使ってSAN（SubjectAlternativeName）にexample.comを記載した偽のサーバ証明書をその場で即座に生成・自動署名する。
▼署名の流れ
①サーバ証明書内のフィールド（ドメイン名、有効期限、発行者名、公開鍵など）をひとまとめにしたデータをハッシュ関数（SHA-256など）に入力しハッシュ値を生成する。
②ハッシュ値をSWG内のCAの秘密鍵で暗号化する。この暗号化したデータこそがデジタル署名になる。
５．SWGとクライアント間でTLSハンドシェイク
　偽のサーバ証明書をクライアントに送り、クライアントは検証する。
▼検証手順：
①ドメインの一致（サイトURLのドメインとSANフィールド内のドメインが一致しているか）
②有効期限の確認
③デジタル署名検証（署名をSWG内のプライベートCAの公開鍵で復号して値を抽出。その値と、クライアント自身でもハッシュを作成した値が一致したらOK）
④信頼チェーン検証（署名したCAが正しいかを確認していき、最終的にクライアントが保持しているルートCA証明書まで到達したらOK）
６．内部ステートテーブルへ登録
　SWGは「クライアント⇔SWG」と「SWG⇔Webサーバ」のそれぞれの送信元IP/ポート、宛先IP/ポート」などを記録し紐づけることによって、２つのトンネルを対応づけている。

７．復号・検査・再暗号化と中継
　ここまでの手順で準備がととのったので、あとは通信を仲介する。その際に、暗号化・復号化、検査を実施する。

（２）C＆Cサーバ

C＆CサーバとはCommand＆Controlの略。マルウェア感染したPCなどが命令をもらいに行くためのサーバがC＆Cサーバ。で、C＆Cサーバ自体も、どこかのPCやサーバなどがマルウェア感染してC＆Cサーバとして強制的に振舞わせているだけという可能性もある。そのためC＆Cサーバの特定ができても本当の黒幕までを特定することは非常に難しい。

設問３

（１）２，７

フォワードプロキシをリバースプロキシにするということは…不要になる通信は….
１．まずは内部→プロキシへの通信は不要になる。(7番)
２．プロキシ→外部への通信も不要になる。(2番)

p.15 セキュアWebゲートウェイとは？ｰｰｰｰｰｰｰｰｰ

セキュアWebゲートウェイ（SWG）を端的に言うと「インターネット上にあるセキュリティ機能が追加されたプロキシサーバ」である。
従来までは転送にフォーカスしていたが、SWGなら転送だけでなく「SSLインスペクション、レピュテーション、マルウェア駆除」など様々なセキュリティ機能を使える。

プロキシとSWGの違いは？—————-

プロキシは通信の代理中継がメイン。
SWGとはそのプロキシという仕組みをベースに更にパケットの内部を検査してDLP、URLフィルタリング、レピュテーション、マルウェア駆除などの内部にもフォーカスしてくれるプロキシをSWGという。
▼SWGの主な機能

p.15 SaaSの利用者認証とは？—————

Q.SaaSの利用者認証ってどうやってやるの？
A.インスタグラムなどのSNSと同じようにユーザIDとパスワードを使って認証する。

NTPコマンド————

では、NTPでよく使われるコマンドや同期情報の確認方法を見ていこう！

#時刻を同期したいNTPサーバのIPアドレスを指定＆下位のストラタムに時刻を提供できるようにもなる
RouterA(config)#ntp server IPアドレス

#NTPのマスタになる。デフォルトのストラタムは8------
RouterA(config)#ntp master ストラタム


#NTP同期情報の表示-----------------------------
Router# show ntp associations

address         ref clock       st   when  poll reach  delay  offset    disp
*10.0.0.1       192.168.1.100   2    64    64   377   5.234  -0.632    18.2
+192.168.1.101   10.0.0.1        3    32    64   177   8.123   1.234    22.1
 192.168.1.102   10.0.0.2        3    48    64   177   9.456   2.345    25.3

↑ このマークが重要

PACを配布する方法であるWPADとは?———-

Ｑ．PACファイルとはプロキシ通信の挙動を制御するファイルである。プロキシ例外リストよりも、より細かな設定（時間帯、ワイルドカードマスク、条件分岐などなど）を実現できるJavaScriptファイル。これを各PCに配置する方法がWPADである。では、どのように配置するかを見ていこう！
Ａ．WPAD（Web Proxy Auto-Discovery Protocol）とは「大元となるWebサーバにおいたPACファイルを、PCが自動でダウンロードしに行く仕組み」である。自動で大元まで到達するには様々な方法がある。ここでは２つ紹介していこう！

方法１：DNS
①クライアントは自分の所属ドメインの先頭にwpadを付加して名前解決をする
（例：wpad.自社ドメイン.com）
②名前解決で得られたIPアドレス（Webサーバ）の標準パス（/wpad.dat）へアクセスしてファイルを取得する

方法２：DHCP
①クライアントがIPアドレス取得の際に使うDHCPフローの中で、オプションとして「Option252」と呼ばれるPACファイルのURLも一緒に通知
（例：

404 Not Found

wpad.domain.com

プロキシ・FW・WAFの違いは？———-

方向・目的などに着目すると違いが明確になるので、それらに着目しながら見ていこう！

Syslogコマンド——-

Syslogのコマンドを見ていこう！

#ログを転送するSyslogサーバの指定
logging host SyslogのIPアドレス

#Syslogサーバに送信するログ
logging trap サベリティレベル

#ログに出力されるタイムスタンプを指定
service timestamps log datetime msec

#バッファに格納するログ
logging buffered バッファサイズ　サベリティレベル

p.16 プロキシとRADIUSの連携はどうやってやるの？———–

プロキシとRADIUSの連携と聞くとなんだか難しそうだけど、フローを見ると意外とシンプルであることが分かる。なので見ていこう！

１．クライアントがWeb通信のためにプロキシに接続
２．プロキシが認証要求（HTTP 407）
　プロキシは未認証のユーザからの接続に対しては、407 Proxy Authentication Required（IDとパスワードを出してください）というエラーを返す
３．ユーザが認証情報を入力しプロキシへ送信
　PCにポップアップが表示され当該情報を入力する
?普段の会社PCなどではプロキシを使っているはずだけど、ポップアップが表示されることがないのはなぜ？
A.ActiveDirectoryと統合Windows認証が裏で自動処理してくれているから。
　PCがログインした時点で裏で、認証済みのチケットを受け取ることができ、以降の通信において認証情報が求められたら裏でその認証チケットを利用して自動認証できるようにActiveDirectoryと統合Windows認証が動いてくれている。
４．プロキシはRADIUSサーバへ投げる
　認証情報をRADIUS(認証：UDP1812, アカウンティング：UDP1813）に包みRADIUSサーバへ渡す（Access-Request）。
　RADIUSはHTTPが理解できないので、認証サーバが理解できる標準フォーマット（RADIUS）に変換してあげることで、IDとパスワードを正しく認識・判定させている。
５．RADIUSの判定結果
　RADIUSサーバが認証し、問題がなければAccess-Accept（許可）をプロキシに返す。
６．通信の開始

ここまでが大まかな流れだよ！では、一旦完了！

統合Windows認証とは？————-

正式名称はIntegrated Windows Authentication（IWA,統合Windows認証）である。しかし、場合によっては、Windows統合認証と呼ばれたりもする。一言で言うと、「ブラウザとWindowsOSが連携してPCログイン情報をHTTP上で自動送信する仕組み（フレームワーク）」のこと。要は、ブラウザ(HTTP)とActiveDirectoryの橋渡しをしてくれる機能。
これがないと、SSO的な働きができないので、ユーザが手動でポップアップに表示された画面に自身のID,パスワードを入力していた。

p.17 SWGのグローバルIP割り当てサービスとは？—————-

Q.文章だけ読むと、「端末や社内ルータに設定するためのIP（WAN用IP）を付与する」といったISP的なサービスを想像してしまう。しかし、そうではない。では、何を何のためにしているのか？
A.端的に言うと「SWGが外と通信するときにIPアドレスを固定にする」ということである。SWG（SaaS）サービスからの送信元は、IPアドレスは動的に変化したり他社と共有されることがある。そのため、IPアドレス制限を用いているWebサービスなどにおいては、固定のものを設定したい。そのような場合に、問題文中にもあるような「固定のグローバルIPアドレスを割り当てるサービスメニュー」を使うのである。

p.17 エージェントが利用者認証する方法

Ｑ．エージェント、利用者認証をして~~どうのこうの~~とかって書いてあるけど、どうやって利用者認証するの？一般的にはどうすんの?
Ａ．SWGの認証を受ける方法として最も一般的なのが、Idp連携をエージェントが裏で実行するパターン。ではIdp連携を見ていこう

▼Idp連携フロー

p.17 フォワードプロキシからリバースプロキシへの転用——

フォワードプロキシからリバースプロキシに利用方法を変えると書いてあると、なにかそれら二つに特別なつながりがあるように見える。しかし、これは単に、使わなくなったサーバを再利用しているだけである。なにかプロキシという共通点があるから転用が可能だったというわけではない。これが使わなくなったWebサーバであったとしてもリバースプロキシへの転用は可能である。
＊補足として、共通点があることによって、既にプロキシ機能が入っているので設定変更のみで挙動を変えられるというメリットはある。しかし、だからといってほかのサーバが転用できないというわけではない。

以下の表より、30WはPoE＋であることが分かるので答えもPoE+となる。

PoEを勉強していると、TypeAやTypeBといった単語を耳にする。これは、PoEにおいてLANケーブルにどのように電力を流すかを示したもの
TypeA:1,2,3,6番のデータ転送用ピンの上に畳み込んで電力を流す方法
TypeB:1,2,3,6番のデータ転送用ピンは使わずに4,5,7,8番に電力を流す方法。
＊1Gbpsの場合は8ピンすべてデータ転送に使うが基本的な動作は同じ。TypeAなら1,2,3,6番に電力を流し、TypeBなら4,5,7,8に流す。

（２）PCが属するセグメント

DHCPサーバはgiaddrフィールドを見ることによって、「あ、このセグメントね！ってことはこのプープから払い出そう！」と判断できる。これがないとどのプールから払い出せばよいかわからなくなってしまう。では、実際の流れを見ていこう！

▼DHCPの大まかな流れ

▼DHCPリレーエージェントの流れ

１．【DISCOVER】PC → ルーター（リレーエージェント）
　PCはchaddrフィールドに自身のMACアドレスを格納し、L2ブロードキャストを送信する
２．【DISCOVER（転送）】ルーター →DHCPサーバー
　ルータは受信インタフェースのIPアドレスをgiaddrフィールドに格納する

#リレーエージェントの設定
interface Gi0/0
ip helper-address DHCPサーバのIPアドレス

３．【OFFER】DHCPサーバー →ルーター
　・DHCPサーバはgiaddrフィールドを確認して適切なプールを特定する
　・宛先をgiaddrフィールドのIPに設定してユニキャストで送信

ip dhcp pool プール名
network ネットワークアドレス　プレフィックス長orサブネットマスク
default-router デフォルトルータのIPアドレス
dns-server DNSサーバのIP
lease 日　時間　分　#無限の場合はinfinite

４．【OFFER（転送）】ルーター → スイッチ → PC
　ルータはパケット内のchaddrを宛先として、ユニキャストで転送する
５．【REQUEST】PC → DHCPサーバー
　「そのIPアドレス使いたいです！」というリクエストを、DISCOVERと同じ中継手順（giaddr と chaddr を使用）でDHCPサーバーへ送信。
６．【ACK】DHCPサーバー → PC
　・DHCPサーバーが「承認（確定）」のACKを作成し、OFFERと同じ中継手順でPCへ返送
　・PCのIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等の設定が完了！

設問２
（１）ログイン画面が表示されない事象が一部かつ不特定だから

帯域不足の場合は、「つながるPC」と「接続すらできずにタイムアウトするPC」にぱっきり分かれることがないから。「帯域不足なら影響は全体に広がる（全員が遅くなる）はず。しかし、タイムアウトになるのが『一部』にとどまっているということは、全体に波及していない『早い者勝ちの定員オーバー（NAPT上限）』が起きていると考えるのが妥当である。

タイムアウト画面とは以下のような接続が正常にできないときに表示される画面のこと。

タイムアウトには主に２種類ある。接続タイムアウトとセッションタイムアウト。

（４）PC台数：327　エントリー数：120,000

PC台数：
　まず、1台当たり200セッションを使う。そしてセッションの上限数は65,536である。つまり65,536÷200=327.68となる。つまり327台である。
エントリー数：
　問題文中の最初にU校には600台のPCがあることが分かる。そして、１台200セッション使うので200×600=120,000となる。

設問３
（３）調整：UDPの保持時間を300秒より小さくする
　　　効果：未使用のUDPフローによるNAPT変換エントリーを早期に削除できる

HTTP/3ではアプリケーション層でセッション管理をしているので、NAPTのポート番号が変わったり、テーブルから一時的に削除されても通信を再開できる。だからこそ、ルータ側の保持期間を思い切って短くしても問題ない。というより、むしろ短くしなければならない！
なぜなら、今まではTCPで行われていたWeb通信をHTTP/3によりUDPが使われるようになり、大量のUDPフローが生まれる。それらをすべて300秒保持していたらエントリが足りなくなる。そのため、短くする。

UDPを300秒から60秒などに短縮したらほかのプロトコルで影響でないの?————

UDPを使うプロトコルとしてはVoIP,Syslog,NTP,SNMPなどがある。そのうちのVoIPにはKeepAliveという機能があり、定期的にUDPパケットを発生させてタイムアウトを防ぐ仕組みがある。一方、Syslog,NTP,SNMPなどはその仕組みがない。しかし、一方向の通信（双方向が不要。送りっぱなしでOK）であるため特に問題はない。ではどうしてそもそも300秒に設定されているの？
＊SNMP trapだけ例外
A.シンプルに、NATの規格であるRFCによって2~5分以上が推奨されているから。
＊SNMP trapの場合は外からの通信がくるのでNAPTテーブルにないとブロックされてしまう。そのため、ポートを開けておくなどの特別な対応が必要になる。

p.9 Wi-Fi6とは———————–

では、Wi-Fi6を学ぶついでにWi-Fi４，５も以下の表で一緒に確認しましょう。

簡易的な速度体感—————-

正直、最大通信速度が600 Mbps、6.9 Gbps、9.6 Gbpsと言われてもイメージができない。なので、ここでは具体的な転送時間の目安（理論値）を見ていこう！

＊例えば3GB(24000Mbp)のデータをダウンロードする際に、35.3Mbpsの速度なら24000/35.3=679.88s=11.33m。つまり11分ほどかかる計算になる。

Wi-Fi 6E,7,8 ————————

Wi-Fi4~6までは教科書などでよく目にする。では、その発展版として、6E～8も一緒に見ていこう！

Wi-Fi7 MLOってなに？——————————

MLOはMultiLinkOperationの略。Wi-Fi6Eまでは2.4,5,6GHと３つあっても１つの帯域しか使えなかった。しかし、Wi-Fi７からは5GHz帯と6GHz帯の両方を同時に使えるようになった。これにより、遅延が激減し、ゲームやWeb会議がほぼ途切れなくなった。
トライバンドMLOのように2.4,5,6GHと３つすべてを同時に使うことも可能だが、2.4はノイズが多かったり、速度が遅かったりするので速さを求めるのであれば2.4は束ねない。冗長性を求めているなら束ねてもOK。

Wi-Fi7 プリアンブル・パンクチャリング———————-

プリアンブル・パンクチャリングとは一言で言うと「虫食い（パンクチャー）にして重なっている部分だけを避けて残りを有効活用する」という意味である。
今までのWi-Fi6Eまでだと、使おうとする帯域の一部でも他と重なってしまうとその部分のチャネルボンディングはあきらめる。しかし、プリアンブル・パンクチャリングを使えば、重なっている部分のを取り除き、残りの部分を有効活用できるようになる。
具体的には、160MHz(8チャネルボンディング)をする際に、端の部分で干渉していると、今までであれば、80MHz（4チャネルボンディング）に落とす必要がある。しかし、プリアンブル・パンクチャリングを使えば、重なっている部分のみを取り除き140MHz帯として利用できるようになる。
これによって、周波数帯を有効活用できるようになる。

Wi-Fi8 マルチAP協調制御（MAPC）——————–

MAPCはMultiAccessPointCoordinationの略。AP同士で話し合って、優先度や出力を決定してバッティングとデータ破損を防ぐ仕組み。その仕組みを実現するためには様々な技術が使われている。それを見ていこう！

１．動的ビームフォーミング制御（CoBF:Coordinated BeamForming）
　AP同士が「お互いの狙う方法（指向性）をリアルタイムで共有する機能。これにより、電波出力の大小に依存しない通信が可能になる。
＊指向性には八木アンテナ（一直線）、ダイポール（全範囲）、パッチ（中途半端に広い）といったような種類がある。
２．パワー制御・出力調整（CoSR:CoordinatedSpatialReuse）
　電波の強さを調整する機能。今までは100%で出力していたが、それだとほかのAPと干渉しやすくなってしまい通信の疎外になる。なので、必要な時に必要な強さだけ出力させられるようにした。

BSSカラーリングとマルチAP協調制御の違い———

BSSの解説：
Wi-Fiにはあるルールがある。それが、CSMA/CAである。これは、どこかのAPがしゃべっているときは、衝突が起こらないように自分は黙る。というルールがある。しかし、それを馬鹿みたいに従っていると、微弱な電波を拾っただけでも無駄に待機する時間が発生する。それを防ぐために、同一のBSS以外の電波（微弱な電波）を拾っても待機しないでそのまま使っちゃおうよというのがBSSである。

本題：
BSSは電波の強弱によって通信を維持できている。しかし、同一レベルの電波が来た場合、対処できなくなる。そのような電波の出力差がない場合でも通信を維持できる仕組みがマルチAP協調制御である。

なぜ６GHzを使うの？——————-

Wi-Fi６Eから急に6GHz帯が使われるようになった。これはなぜなのか？技術的な問題なのか何が変わったから急に6GHzを使えるようになったのか。また、なぜ6GHzだけなのか。帯域を増やしてメリットがあるなら7GHzや8GHzなど、ほかの帯域もどんどん増やせばいいのに。。。
要因１：周波数の特性
電波は高い周波数であればあるほど高速性が上がるが、その反面、障害物に弱くなる。そのため、家庭内で7GHz以上だと人が横切ったりするだけで切断されるので不向き。そのため、７，８GHzといった周波数帯は使われない。家庭内のスウィートスポット（現実的な着地点）が6GHzだったから。
要因２：７GHz以上は既に埋まっている
電波はいろいろな用途に使われている。そのため、既にぎゅうぎゅう詰めのところを、奇跡的に使えたのが6GHzであり、それ以外の周波数帯を簡単に追加したりといったことは困難だから。
要因３：コスト＆パフォーマンス
高い周波数を扱うアンテナや半導体チップ（RFIC）は製造難易度も高く、スマホやPCに搭載すると端末価格が高騰する。また、バッテリー消費と発熱が凄まじいことになる。

7GHz以上が使われるのってどんな時？レーダー？

7GHz以上の高周波数帯は障害物に弱い性質があり遠くまでは届かないという特性がある。では、そんな特性はどんな時に使われるのか。よく聞くのは軍事や気象レーダーなどである。しかし、いまいちイメージがつかない。ということで見ていこう！
１．レーダーは「突き抜け」ではなく、「跳ね返り」を利用する
高周波数の特性は障害物の影響を受けやすいという特徴がある。しかし、この特性こそがれーがに向いている。レーダーは「遠くの小さな物体を感知して、跳ね返りをキャッチする」という目的がある。高周波の特性はレーダーにとって大きなメリットとなる。
２．海や空には障害物がない
家庭内では壁・ドア・家具・人などの障害物だらけの環境（NLOS：NotLineOfSight：非見通し環境）で通信しなければならない。しかし、航空・軍事・気象レーダーは大空、海上などの開かれた空間（LineOfSight：視通環境）で使われるため高周波数の壁を通り抜けないという弱点が問題にならない。
３．周波数が高いほど小さなものを精密に見分けられる
7GHz以上の高周波数帯は障害物に弱い性質があり遠くまでは届かないという特性がある。では、そんな特性はどんな時に使われるのか。よく聞くのは軍事や気象レーダーなどである。しかし、いまいちイメージがつかない。ということで見ていこう！
１．レーダーは「突き抜け」ではなく、「跳ね返り」を利用する
高周波数の特性は障害物の影響を受けやすいという特徴がある。しかし、この特性こそがれーがに向いている。レーダーは「遠くの小さな物体を感知して、跳ね返りをキャッチする」という目的がある。高周波の特性はレーダーにとって大きなメリットとなる。
２．海や空には障害物がない
家庭内では壁・ドア・家具・人などの障害物だらけの環境（NLOS：NotLineOfSight：非見通し環境）で通信しなければならない。しかし、航空・軍事・気象レーダーは大空、海上などの開かれた空間（LineOfSight：視通環境）で使われるため高周波数の壁を通り抜けないという弱点が問題にならない。
３．周波数が高いほど小さなものを精密に見分けられる
電波は、「自分の波長よりも小さいもの」はすり抜けてしまい、感知できない。2.4GHzの波長（約12cm）だと雨粒（数ミリ）に当たっても、電波が大きすぎてすり抜けてしまう。そのため、気象レーダーには使えません。

５GH帯でよく耳にするW52,W53,W56とは？

５GH帯でよく耳にするW52,W53,W56とは何なのだろうか。なぜ、51や57,58といったほかの数字は使わずにこんな中途半端なのか。
そもそもこれは周波数帯（グループ名）をあらわしている。周波数（GHz）の頭の数字をそのまま取って名前が付けられてる。
W52 ＝ 5.2 GHz帯のグループ（チャンネル番号：36, 40, 44, 48）
W53 ＝ 5.3 GHz帯のグループ（チャンネル番号：52, 56, 60, 64）
W56 ＝ 5.6 GHz帯のグループ（チャンネル番号：100, 104, 108 … 144）
意図的にこのバラバラ数字を使っているわけではなく、Wi-Fi用に５GHz帯を絞り出す際にたまたま使えそうな周波数帯が52,53,56だったらから選ばれたという背景がある。飛んでいるほかの数字W51,57,58などは他の用途で既に使われている。

p.9 IEEE802.1xとは？————-

IEEE802.1xとはLANを利用するときの入り口制御を担当する仕組みがIEEE802.1xである。もし、これがないと、誰でも彼でも接続ができてしまいセキュリティ的にとてもやばい！なので、しっかりネットワークを利用するときは認証しようよね！という思想の元IEEE802.1xが生まれた。
▼具体例
有線接続の場合：
①機器がスイッチに接続
＊初期状態はポートがブロック状態であるため、問答無用で認証プロセスへ流される
②スイッチのIEEE802.1x機能が働き、認証サーバとクライアントとのやり取りを仲介する
③クライアントが認証されるとスイッチ側で「あ、このポートからの通信は流してOKなんだな」と認識しポートをオープンにする
④クライアントがデータ通信を試みると、「あ、このポートからの通信は認証済みだから流そう！」と判断し、データ通信が成立する。
⑤もし、ケーブルが抜けたりするとポートは電気信号を受け取らなくなるのでダウンと判断し、また、ポートをブロック状態に戻す。そのため、新たにつながれたら、再度①からプロセスを辿る。
無線接続の場合：
①機器が電波をキャッチしAPに無線で接続
＊この時点でユーザは、あ、「この電波はPersonalモードか！」や「Enterpriseモードか」などを把握できる。
エンタープライズモードの場合は②へ
▼Personalモードの場合

【Personalモードの流れ】

① 機器が電波（Beacon）をキャッチし「Personalモード（PSK）」だと把握する
② クライアントはあらかじめ入力されている「Wi-Fiパスワード（PSK）」を用意する
   （※AP側にも同じパスワードが設定されている）

③ APとクライアントの間で「4-Way Handshake」を実行！
   ・パスワードそのものは絶対電波に流さない！
   ・「お互いに同じパスワードを知っていること」を数学的に証明し合う。
   ・その過程で、暗号鍵「PTK」を自動計算して作り出す。

④ 成功したら、APの「PTKリスト」に登録！
⑤ データ通信が許可され、DHCPでIPアドレスを取得して通信開始！

②APはクライアントのMACアドレスをキーとしてPTKリストを確認する
PTKリストにある場合→当該キーを使い復号、認証を実施し問題がなければLANに流す
PTKリストにない場合→③へ進む
③APはクライアントにEAP-Requestを送信する
EAP-Requestはクライアントに対して「IDや証明書を出して認証してくださーい」と伝えるメッセージ。
④クライアントはEAPOLパケットをAPに渡す。
＊わざわざEAPを使う理由は、IPアドレスがまだ割り当てられていないからである。そのため、L3のパケットではなく、L2の特別な認証用フレーム（EAPOL）を使う必要がある。
*EAP：認証をするためのメッセージをどうやって記載するかの規格
*EAPOL（EAP over LAN）：EAPをLANで解釈できるようにしたフレーム

【 EAPOLフレームの構造 】
┌────────────────────────────────────────────────────────┐
| 宛先MACアドレス : APのMACアドレス                         　|
| 送信元MACアドレス: クライアントのMACアドレス              　　|
| イーサタイプ     : 0x888E (「これは802.1X認証だよ」という目印)|
├────────────────────────────────────────────────────────┤
| EAPデータ本体    : (IDや証明書などの認証データ)           　　|
└────────────────────────────────────────────────────────┘
 ※ IPヘッダー（192.168...等）は一切ついていません！

⑤APは認証サーバへ転送する
AP自体はIPアドレスを持っているので、EAPデータの本体だけを取り出してL3の形式に直したうえで、認証サーバへ転送する
⑥認証サーバとクライアントの間でTLSハンドシェイクのキャッチボール
認証サーバ⇔AP⇔クライアント間でEAPリクエストとEAPレスポンスのやり取りを繰り返していき、共通鍵（MSK）を生成する。
当該MSKは認証サーバからAPへ共有される。
⑦４way-handshakeを実施してPTKを作成
PTKからTK、KCK、KEKを生成してデータ通信の暗号化や認証を実施する。

PMKを生成する方法——————–

PMKは４ウェイハンドシェイクの材料の一つである。そのPMKがどのように作られるのかを見ていこう！
▼Personalモードの場合
①事前共有パスワード＋SSIDをPBKDF2という鍵引き延ばし関数に入れる
②PBKDF2によりHMAC-SHA1というハッシュ計算を4096回繰り返す（＝ストレッチング）
③出来上がった32バイト（256ビット）がそのままPMKになる
▼Enterpriseモードの場合
①TLSハンドシェイクで64バイトのMSKを生成する
②MSKの先頭32バイトを抽出してPMKを作る

p.9 DHCPリレーエージェント——————-

▼DHCPリレーエージェントのコマンド

interface G0/0
ip helper-address DHCPサーバのIP

Syslogサーバ——————

logging host SyslogサーバのIP　#syslogサーバの宛先を指定
logging trap syslogサベリティ　#syslogサーバに送信するログのレベルを指定
logging buffered syslogサベリティ　#ローカルのバッファに格納するレベル

なお、余談だがOSPFの認証方法はv2とv3で大きく異なる
▼OSPFv2

#インタフェースで有効化する
int g0/0
ip ospf authentication message-digest
ip ospf message-digest-key キーID md5 パスワード


#ルータコンフィギュレーション内で有効化
router ospf プロセス番号
area エリア番号 authentication message-digest #エリア全体で認証を有効化

int g0/0
ip ospf message-digest-key キーID md5 パスワード

▼OSPFv3（初期）
v3の場合はキー、パスワードは使わずにIPsecのSPIと16進数の暗号キーを指定する

#インタフェース単位で有効化する方法
interface GigabitEthernet0/0
#IPsec (SHA1 や MD5) を使って認証を設定する
 ospfv3 authentication ipsec spi 256 sha1 1234567890123456789012345678901234567890
 
 
#エリア全体で有効化する方法
router ospfv3 1
 address-family ipv6 unicast
  area 0 authentication ipsec spi 256 sha1 1234567890123456789012345678901234567890

▼OSPFv3（現在）
初期の設定方法を見ると、ハッシュ化した値を直書きしているのが分かる。これはエンジニアにとってとても面倒だし、間違える可能性も内在する。そこで、Key-Chainという方法がつかわれるようになった。

▼インタフェース単位の有効化---------------
#Key Cahinの作成
key chain キーチェイン名
 key 1
  key-string パスワード
  cryptographic-algorithm hmac-sha-256
  
int g0/0
ospfv3 authentication key-chain キーチェイン名 

▼エリア単位の有効化---------------------
#key-chainの作成
key chain キーチェイン名
 key 1
  key-string パスワード
  cryptographic-algorithm hmac-sha-256
  
#ルータコンフィグ
router ospfv3 プロセス番号
 address-family ipv6 unicast
  area エリア番号 authentication key-chain キーチェイン
 exit-address-family

（４）OSPFの経路情報が収束した状態

再起動直後にマスタールータに昇格すると、OSPFが収束していない状態で引き継ぐことになる。これはすなわち、適切なルーティング情報が手元にない状態であるにもかかわらずパケットがどんどん届いてしまうことを意味する。もちろん、ルーティング情報がないので破棄、または意図しないルートへの転送をしてしまい正常な通信ができなくなってしまう。それを防ぐために、再起動直後からある程度の時間を待機させて、経路情報が安定してからマスタを引き継ぐことで正常な通信を維持できる。

int g0/0
 vrrp グループ番号 preempt delay minimum 秒数
 
#秒数に関しては、基本的に60秒程度を設定する（大規模なら120~180秒）
#OSPF自体は30秒程度で収束するが起動直後などはCPU負荷が高くなるため余裕をもって60秒程度に設定しておこう

設問２
（２）65535といった十分大きな値に変更する
OSPFは宛先までの経路でコストが最も小さな経路が選択される。すなわち、経由させたくなければ、より大きなコストを設定すればよい。そのため、コスト値の最大値である65535を設定する

ちなみに、コスト値だけを見ると1001以上に設定すれば無事に迂回できそうに見える。しかし、ここで気にしておかなければならないのが、ルート１とルート２が全く同じ経路であるかということ。もし、ルート２がもともとルート１よりも多くのルータを経由しなければならない場合、ルート１側の１つのルータのOSPFを少し変更させただけでは迂回しなくなる。なぜならOSPFはインタフェース単体ではなく、経路までの合計のOSPFコストを計算するから。そのため、余裕をもって、65535という値に設定しておくのがベストプラクティスとなっている。

▼OSPFコストの変更方法

int g0/0
ip ospf cost 65535

（３）物理インタフェース閉塞へいそくの方が素早く切り戻せるから

切り離すという観点で言うと、電源をオフにしても、物理インタフェースをダウンにさせても切り離すことが可能。しかし、切り離し中に問題が発生した場合、電源をオフにしてしまうと、再起動までに時間がかかってしまう。その点で、物理インタフェースの閉塞であれば、以上を検知したらすぐに切り戻せるという利点がある。なので、まずは物理インタフェースで様子見をして大丈夫そうなら最終的に電源を切るという手順でやるのがベター。

p.3 そもそもなんでVLANを分けているの？———————–

構成図を確認すると、L3SWでは複数のVLANを設定している。なぜか。。見ていこう！

１．フィルタリングの適用
同一VLANではL3機器のフィルタリングを経由せずL2によるMACアドレスによる直接通信が可能。そのため、L3の詳細なフィルタリングを適用するという意味も含めてVLANを別にして、L3を跨がせるという運用方法をとっている。
２．通信量の削減
同一VLANは、同一ブロードキャストドメインを意味する。つまり、すべてを同一VLANにしてしまうと、すべての機器にARPなどのブロードキャストが届いてしまい帯域を圧迫してしまう。そのため、VLANを設定した方が帯域への負荷も軽減できるよね、という考えがある。

３．局所化
もし、１つのVLANで運用してしまうと、その１つに攻撃が成立するとすべてに広まってしまう。しかし、VLANで分けておけば、たとえ１つに攻撃が成立しても、攻撃範囲を局所化できる。これによってセキュリティ的に強度が高まる。

👆以上、よりVLANにわけると様々なメリットがある

p.4 DMVPNとは？———————–

DMVPN（DynamicMultipointVPN）は、IPsecの弱点を補った仕組み。通常IPsecでは、接続前に事前設定が必要になる。つまり、拠点が増えれば増えるほど、それに伴って事前設定が必要になる。これはとてもタフな作業。しかし、DMVPNを使えば、新たに拠点が追加されても動的に設定を完了させることができる。なお、DMVPNにはPhase１～３まで存在する。まずは、Phase１からやっていこう！

▼通常のIPsecとDMVPN Phase1の違い

▼DMVPN Phase1の流れ———————–

表層の説明だけをしていても理解が難しいと思うので、実際のコマンドと照らし合わせつつ流れを見ていこう！

０．NHRPでハブへ通知する
　実際の通信を始める前に、ルータでは起動直後にNHRPを使いハブルータへ自身の物理IPとトンネルIPを紐づけさせる。
　ちなみにこの通信もトンネルからでるので、暗号化対象となる。宛先については、nhsやmapコマンドなどを参照する。

interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1                  #親玉となるハブのトンネルIPアドレス
 ip nhrp map 10.0.0.1 203.0.113.1      #ハブのトンネルIPアドレスと物理IPアドレスの対応 
 ip nhrp map multicast 203.0.113.1     #マルチキャスト送信先をハブの物理IPアドレスに指定
 ip nhrp holdtime 7200                 #ハブに対して自分の情報を何秒保持してと伝える
 ip nhrp registration timeout 30       #RegistrationRequestを送信する秒間隔

＊正直、技術的には手順２のtunnel destination 203.0.113.1コマンドをかけば、ip nhrp map multicast 203.0.113.1はいらない可能性がある。しかし、nhrpを有効にするとマルチキャストをnhrpのテーブルから探してしまう。そのため、あえて明示的に書く必要がある。

１．GREトンネルへ流す
　・支社端末から本社へのパケット送信を試みる
　・ルータは、宛先が本社の10.2.0.88であることを確認する。
＊OSPFなどのルーティングプロトコルが動作しているならスタティック設定は不要

#支社スポークルータの設定
#スタティック設定によりGREトンネルへ流す判断をする
ip route 10.2.0.0 255.255.255.0 Tunnel0

interface Tunnel0
ip ospf network point-to-multipoint

２．GRE処理
　・パケットがGREトンネルへ届くとGRE処理を実施する
　・具体的には、トンネルの宛先/送信元のカプセル化処理
＊tunnel destinationで指定された宛先を物理的な宛先に、tunnel sourceとして指定されたアドレスを物理的な送信元としてカプセル化する

#支社スポークルータの設定
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0 #トンネルIP
 tunnel source 203.0.113.50      #支社物理IP
 tunnel destination 203.0.113.1  #ハブ物理IP
 tunnel protection ipsec profile DMVPN-PROFILE #トンネルにIPsecを紐づける

３．IPsec処理
　先ほどの最後のコマンドでtunnel protection ipsec profile DMVPN-PROFILEでトンネルがIPsecと紐づいていることが分かる。なので、そのプロファイルに従ったIPsec処理をする

#支社スポークルータの設定
crypto isakmp key secretKEY address 203.0.113.1 #ハブの物理IP

#IPsecーPhase1の設定
crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400

#IPsecーPhase2の設定
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport

#Profile作成（これをトンネルに割り当てる）
crypto ipsec profile DMVPN-PROFILE
 set transform-set TS

４．ルーティング
　tunnel destinationより物理的な宛先が203.0.113.1であることが分かるので、ルーティングテーブルに従って転送処理をする

５．ハブに届く
　ハブでもスポークと同様の設定をしておく。
＊ハブの場合は、ip nhrp map や　ip nhrp map nhsなどは不要。
①宛先を確認して本社であることが分かる。
②本社へはトンネル経由であることが分かる。
＊OSPFなどのルーティングプロトコルをトンネル内で動作させておくことで、ハブルータは、「あ、この宛先はこのトンネルインタフェースからもらったから、このトンネルをネクストホップとして流せばよい！」と判断する。結果的に、トンネルに流せばIPsecが適用される
③トンネルへ流す
④GREカプセル化
⑤IPsec処理
⑥転送

以上が、DMVPN phase1の流れである。
完了！！！

Q.DMVPN Phase1とPhase２の大枠の流れ———————–

▼Phase１におけるルーティングの大枠

#スポークAからスポークB
【事前準備（通信が発生する前）】
⓪ NHRPパケット（自己紹介）の発行
   ・ルータ起動直後「NHRPの登録要求（Registration）を送るぞ。宛先トンネルIPは 10.0.0.1（nhs）だな」
   ・ルータ「10.0.0.1 宛ての物理IPは…… ip nhrp map を見ると 203.0.113.1（ハブ）だな！」
   ・結果 ➔ ハブに向けて自身の「トンネルIP ↔ 物理IP」のペアを暗号化して通知し、登録を完了させる。


【実際のデータ送信時（スポークA ➔ スポークB）】
① ルーティング（OSPF）処理の発動
   ・ルータ「スポークB配下の PC（10.3.0.88）宛てのパケットが来たぞ」
   ・参照場所 ➔ ルーティングテーブル（OSPF）を見る！
   ・結果 ➔「ネクストホップ（次の行き先）は、スポークBのトンネルIP 10.0.0.3 だ！
             Tunnel0 インターフェースへ流せ！」

② GRE処理の発動
   ・ルータ「Tunnel0 からパケットを出すぞ。外側の宛先物理IPは何にすればいい？」
   ・参照場所 ➔ tunnel destination 203.0.113.1 を見る！
   ・結果 ➔（ネクストホップが 10.0.0.3 であっても関係なく）設定に従い、
             外側宛先IPを 203.0.113.1（ハブ）に設定してGREカプセル化！

③ IPsec処理（暗号化）の発動
   ・ルータ「203.0.113.200（ハブ）宛てのパケットが出ようとしている。暗号化（IKE交渉）が必要だな！」
   ・参照場所 ➔ crypto isakmp key ... address 203.0.113.1 を見る！
   ・結果 ➔ 203.0.113.1 用の鍵（secretKEY）を使って暗号化トンネルを確立・適用し、ハブへ向けて送信！

▼Phase２におけるルーティングの大枠

#スポークAからスポークBへの通信
① ルーティング（OSPF）処理の発動
   ・ルータ「スポークB配下の PC（10.3.0.88）宛てのパケットが来たぞ」
   ・参照場所 ➔ ルーティングテーブル（OSPF）を見る！
   ・結果 ➔「ネクストホップ（次の行き先）は、スポークBのトンネルIP 10.0.0.3 だ！
             Tunnel0 インターフェースへ流せ！」

② GRE処理の発動（★ここがフェーズ1と大違い！）
   ・ルータ「Tunnel0 からパケットを出すぞ。外側の宛先物理IPは何にすればいい？」
   ・参照場所 ➔ `tunnel destination` を探す……が無い！（mGREモードだから）
   ・ルータ「よし、【NHRP部署】に問い合わせだ！
             『ネクストホップ 10.0.0.3 に対応する物理IPを教えてくれ！』」

③ NHRP処理の発動（電話帳検索 ＆ 解決要求）
   ・【NHRP部署】「自分のキャッシュ（電話帳）に 10.0.0.3 の物理IPはあるか？」
   
   【パターンA：まだ知らない場合（1発目のパケット）】
   ・NHRP「まだ知らない！とりあえずハブ（10.0.0.1 ➔ 203.0.113.1）に一時的に送っておくぞ！」
   ・NHRP「同時に、ハブへ『10.0.0.3 の物理IPを教えて！』と Resolution Request を送信！」
   ・ハブ「10.0.0.3 の物理IPは 203.0.113.200 だよ！」と回答が届く ➔ キャッシュに保存！

   【パターンB：もう知っている場合（2発目以降のパケット）】
   ・NHRP「キャッシュにあったぞ！10.0.0.3 の物理IPは 203.0.113.200 だ！」

   ・結果 ➔ 外側宛先IPを 203.0.113.200 に設定してGREカプセル化！

④ IPsec処理（暗号化）の発動（★スポーク間ダイレクト！）
   ・ルータ「203.0.113.200（スポークB）宛てのパケットが出ようとしている。暗号化が必要だな！」
   ・参照場所 ➔ `crypto isakmp key ... address 0.0.0.0` を見る！
   ・結果 ➔ スポークB（203.0.113.200）と直接 IKE/IPsec の鍵交換を行い、
             暗号化（ESP化）して直接インターネットへ発射！

Q.NHRPの具体的な挙動———————–

NHRP（NextHopResolutionProtocol）について、なんとなく「物理IPとトンネルIPの対応を解決してくれるプロトコル」という理解まではできる人が多い。しかし、実際の挙動をイメージした場合、どうなっているのか説明できる人まではなかなかいない。なので、実際の挙動を見ていこう！NHRPには大きく分けて、登録とリクエストの２つがある。その二つの挙動についてやっていこう！
１．Registration
・Spoke 起動時：ip nhrp nhs と ip nhrp map を参照し、ハブの物理IPを特定。
・パケット：Registration Request（自身の トンネルIP ↔ 物理IP を格納）をハブへ送信。
・ハブの動作：NHRP データベースに登録し、Spoke の居場所を把握する。
２．Resolution
① Spoke A ➔ ハブ（リクエスト送信）
・Resolution Request（ターゲットのトンネルIP、自身の トンネルIP ＆ 物理IP）を送信。
② ハブ ➔ Spoke B（転送）
・ハブは中身を書き換えずにそのまま Spoke B へ転送。
③ Spoke B（相互学習 ＆ ダイレクト応答）
・Spoke B はパケット内の Spoke A の情報（物理IPなど）を NHRP キャッシュに登録（相互学習）。
・Spoke A 宛てに直接 IPsec を確立し、暗号化した状態で Resolution Reply（自身の情報）を返答！
④ Spoke A（学習完了 ＆ ダイレクト通信確立）
・Spoke B からの直接返答を受け取り、NHRP キャッシュに Spoke B の情報を登録。
・以後、Spoke A ↔ Spoke B 間でハブを介さない直接通信が開始！

▼DMVPN Phase2の流れ———————–

Phase2も基本的にPhase1と同じ流れ。しかし、わずかに相違点もある。
相違点１：スポーク側もハブと同じtunnel mode gre multipointをする
相違点２：スポーク間で動的にIPsec＋GREトンネルが自動生成される
では、そのような相違点に着目しながらPhase2を見ていこう！

０．NHRPでハブへ通知
　実際の通信が始まる前に、ルータ起動直後にNHRPを使ってハブルータへ自身の物理IPとトンネルIPアドレスを紐づけさせる（＊ここはPhase１と同じ）

interface Tunnel 0
ip address 10.0.0.2 255.255.255.0
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
ip nhrp map 10.0.0.1 203.0.113.1 

ip nhrp map multicast 203.0.113.1 
ip nhrp holdtime 7200             #ハブに対して自分の情報を何秒保持してと伝える
ip nhrp registration timeout 300　#ハブに登録しに行く秒間隔

１．ルーティングの準備
　＊Phase２ではSpokeToSpokeを実現したい。しかし、そのまま設定すると、OSPFのルーティングテーブルとNHRPのテーブル情報で不正が生まれてしまう。それを避けるための設定が必要になる。

#ルーティングプロトコル（OSPF）の有効化

router ospf 1
network トンネルIP ワイルドカード area エリアID
network 内部LANIP ワイルドカード area エリアID

#インタフェース設定
interface Tunnel 0
ip ospf priority 0  #DR/BDRにならないようにする
ip ospf network broadcast

？なぜnetworkタイプをbroadcastにするのか
phase２ではSpoke-to-Spokeの通信をさせるために、ネクストホップをスポークのままにしてハブは転送しなくてはならない。もし、point-to-multipointにしてしまうと、ハブがネクストホップを上書きしてスポーク間に広告してしまう。そのため、phase2ではbroadcastを設定する。
？なぜスポークのpriorityを0にするのか
broadcastだとDR/BDRの選出が行われる。もし、スポーク側がDR/BDRに選出されてしまい、ハブがDRotherになってしまうと、ハブは224.0.0.6を破棄してしまう。
確かにnhrpの設定でハブはマルチキャストを転送する役割がある。しかしそれよりも優先的にOSPFのDRotherという役割が上書きされるので、224.0.0.6はマルチキャストといえどDRotherの役割をまっとうして問答無用で破棄する。

２．GRE処理
トンネルを経由するパケットに関してはGRE over IPsecを適用したいので、GRE処理を追加する

interface Tunnel0
tunnel source 自身物理IP
tunnel mode gre multipoint #pahse1の時はtunnel destination ハブの物理IPだった
tunnel protection ipsec profile IPsecプロファイル

*tunnel mode gre multipointはpahse1の時はtunnel destination ハブの物理IPだった。
？tunnel mode gre multipointは物理IPが分からないけどどうやってカプセル化するの？
A.そもそも、tunnel mode gre multipointがnhrpテーブルを使うためのトリガーとなるので、これを見た瞬間に、「あ、multipointが指定されているから、実際の物理IPはnhrpで確認しよう！」となるので心配ご無用！

３．IPsec処理
ここまでで、「パケットの宛先がリモートスポークの配下であること判明→そのリモートへは自身のトンネルから流す→自身のトンネルにはGRE処理がある→tunnel mode gre multipointからnhrpで物理IPを知る→判明した物理IPでカプセル化→IPsecの処理もトンネルにはあるのでその処理をする」という流れができている。なので、ここではIPsec処理をやっていく。

#事前共有鍵の定義
crypto isakmp key パスワード address 0.0.0.0 0.0.0.0

#ISAKMP SA(Phase 1)の作成
crypto isakmp policy ポリシー番号
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
 
#IPsec SA(Phase 2)の作成
crypto ipsec transform-set トランスフォーム名 esp-aes 256 esp-sha256-hmac
 mode transport
 
#IPsecプロファイルの作成
crypto ipsec profile プロファイル名
 set transform-set トランスフォーム名

４．ルーティング
カプセル化には相手スポークの物理IPが設定されているので、SpokeToSpokeで直接届かせることができる。
完了！！！！！！

OSPFのネットワークタイプ———————–

DMVPNのphase1とphase2ではOSPFのネットワークタイプが重要になってくる。そのため、ここで一度、確認しておこう！

OSPFにおけるDR＆BDRとは？———————–

DRとBDRの選出をすることによって、セグメント内のルータがフルメッシュでネイバー関係にならなくてもよくなる。その結果、CPU負荷や帯域の使用率を下げることができる。
また、LSAの統合役がいることで、個々のルータによる差異が起きにくくループ発生を防ぎやすくなる。

▼OSPFのフロー（Down～FULL）———————–

前提：
・同一セグメントに１０台以上のルータが存在する環境
・ネットワークタイプはBroadcast
０．Down
相手からHelloパケットが１度も届いていない状態
１．Helloパケットの送信（Init）
ルータを起動すると、まずは224.0.0.5宛てのマルチキャストを送信する。
▼Helloパケットには以下の情報が含まれる

２．２WAY
同一セグメントからのHelloパケットのNeighborフィールドに自身のルータIDが記載されている場合、相互認識完了。
ここで、DRとBDRを選出する
DRとBDRが決まったので、以降の通信はマルチキャストではなくユニキャストで実行される
▼選出基準
①プライオリティ（デフォルトは１）が１番大きいルータがDRに、２番目がBDRになる
②①が同一の場合はルータIDで決める
＊ルータIDは重複が禁止なのでこの２ステップで確実に決まる
３．EXstrat
マスターとスレーブを決める。
▼選出方法
①DBDパケット（ルータID、MTU、制御フラグ、シーケンス番号が格納）を送信する
＊MTUが不一致だとshow ip ospf neighbor 時にExstartで止まる
②ルータIDを比較し、大きなほうがマスターになる。
③スレーブはシーケンス番号をマスターに合わせる
▼詳細

[ ルータ A (RID: 1.1.1.1) ]                       [ ルータ B (RID: 2.2.2.2) ]

 1) 「僕がマスターだ！(MS=1)」 ── (ユニキャスト) ──>  「僕がマスターだ！(MS=1)」
    (RID: 1.1.1.1, Seq: 100)                         (RID: 2.2.2.2, Seq: 500)
                              <── (ユニキャスト) ──

 2)  ルータ A は「相手（2.2.2.2）の方が RID が大きい！」と気づき、スレーブ（Slave）を認める。
     ルータ B は「自分（2.2.2.2）の方が RID が大きい！」と確信し、マスター（Master）になる。

 3) スレーブ（ルータ A）が折れて、相手の Seq: 500 を使って返事をする：
    「了解、君がマスターね。(MS=0)」 ───>  「よし、じゃあ僕（マスター）から目録を送るね！」
    (Seq: 500 で返信)                         (ここから Exchange ステートへ移行！)
    
    
 #制御フラグ
 M(More)ビット：１→まだ続きがあるよ。１回でLSA目次が入りきらなかったら使う
 MS(Master/Slave)ビット：１→俺がマスターだよ！
 I(Init)ビット：１→これが最初のDBDだよ！つまりExstartを意味する
 

４．Exchange
お互いのLSDB情報を同期するためのフェーズがExchange。お互いのLSAの差分の有無によって挙動が変わる。
▼Exchange詳細フロー
①マスターがDBDにLSAの概要を載せてスレーブへ送信する
②スレーブも、マスターへDBDにLSAの概要を載せて送信する
③Mビットが０になるまでお互い交互にDBDを送り合う
＊Mビット：１がまだ続きがあるよ！の意。０がLSAの目次送り切りましたよ！と伝えるフラグ
送り合っている最中も自分のLSDBと相手のDBDを見比べて差分をLSRリスト（後で要求するLSAのリスト）を作成しておく。
→Mビットが０になった時点で差分がない場合はLoadingをスキップしてFULLへ
→Mビットが０になった時点で差分がある場合はLoadingへ
５．Loading
LSRリストをもとに欲しい情報を取得してLSDBを完成させるというプロセスを担うのがLoading。基本的にはLSR→LSU→LSAckという流れで進んでいく。では、詳細を見ていこう！
▼Loading詳細フロー
①LSR(LinkStateReques)の送信
Exchangeステートで準備しておいたLSRリストをもとに、「このLSAの詳細をください」と請求するLSRパケットを送信する
②LSU(LinkStateUpdate)の送信
LSRを受信した相手は、請求されたLSAの詳細データを詰め込んだLSUパケットを返す。
（１つのLSUに複数のLSA詳細データをまとめて送れる）
③LSAck(LinkStateAcknowledgment)
LSUを受け取ったら自身のLSDBに保存する。保存が完了したら「LSUを受け取ったよ！」という確認メッセージであるLSAckパケットを返す。
④LSRリストが空になったらFULLへ移行
LSRリスト内のLSAをすべて受け取り、手元のLSRリストが完全に０件になったらFullへ移行
６．FULL
・FULLになったら、あとはタイマーに従ってHelloパケットを送信し合う。
FULLになった後に経路の追加、削除が検知されると、検知したルータがLSUをDR/BDRにマルチキャスト(224.0.0.6)送信する。それをDR/BDRがマルチキャスト(224.0.0.5)して全体に広がる。
▼経路削除
当該LSAを「シーケンスを＋１にする＆Maxageを3600」にしてLSUを送る。
＊MaxageはLSAを保持する期間。これが切れると削除されるので、3600でLSUを送ると自動的に相手側から削除される
▼経路追加
通常のLSUを送る流れでパケット送信する

以上がOSPFのフロー説明である。
完了！！！

DMVPN Phase3——————–

phase2まででSpokeToSpokeが完了した。しかし、これには弱点がある。各スポークがほかのスポーク配下の情報をすべて保持していなければならず、ルーティングテーブルが莫大になってしまい大規模環境には向いていないとされている。それを解消できるのがphase3である。

phase2はなぜ大規模に向かないのか?——————–

phase２では各スポークが、ほかのスポーク配下のルート情報をすべて保持する必要がある。そのため大規模環境には向かないとされている。でも、経路集約を使えば解決できるのでは？と疑問が浮かぶ。しかし、そこにはいくつもの壁（厳格なルール）がある。それを見ていこう！
①エリア内ルータは経路集約できないというルールがある
大抵の場合、ハブと各スポークは同一エリアのエリア０で動作している。OSPFのルールでは経路集約ができるのはABRとASBRとなっているため、スポーク側のエリア内ルータでは集約ができないという制限がある。
②スポーク側で経路集約してもそもそも効果が薄い
エリアを分割すれば、スポーク側で経路集約ができるという考えもある。しかし、そもそも拠点が1000以上である場合、少なくとも1000のルーティング情報は保持しなければならいため、スポーク側で集約してもさほど効果がないというそもそも論が生まれる。
③ハブがデフォルトルート流すとネクストホップが変わる
ハブがデフォルトルートを流せば、全スポークの経路を１行で抑えることができる。これをやるとルーティングテーブルは抑えることができるが、そもそもすべての通信がハブ経由になるのでSpokeToSpokeが破綻する。

インターネット用のデフォルトルートとDMVPN用のデフォルトルートは重複しないの？
①パターン１
インターネット宛先もDMVPNもすべてハブへ流す構成にする。届いた後に、ハブ側がDMVPNかインターネットかを判断してルーティングさせれば、重複していても問題ない。
②パターン2
社内LANの集約ルートを使う。実際の現場では、0.0.0.0ではなく10.0.0.0/8や192.168.0.0/16として社内全体をまとめた大きな集約ルートを流す。

なぜPhase3はPhase2よりもすぐれているのか？——————-

ShortCutとRedirectと呼ばれる新機能追加により、スポーク側に動的なルート生成を可能としているから。どういうことなのか、簡単に見ていこう！
①ハブが社内集約ルートを配る
＊これにより、スポークには、ほかのスポークのトンネルIPも内部LAN情報を届かなくなる
＊社内集約ルート（10.0.0.0/8や192.168.0.0/16など）を流すのではなく、インターネットもハブを経由させたいという場合はそのまま0.0.0.0のデフォルトルートを流すこともある。
②スポークAがスポークBへ
DNSなどの名前解決により、社内LANのIPアドレスが割り当てられたサーバへアクセスしたいと考える。しかし、ネクストホップが分からないので、社内サマリーを持つハブへ丸投げする
③ハブのRedirect指令！
・ハブは、トンネルから受け取ったパケットをトンネルから流すルーティングであることが判明すると送信元に対して「次からこの通信は俺を経由せず、直接行ってね（NHRP Redirect)」と指令を出す。
・パケット自体は宛先のスポークBへ転送してあげる。
④スポークAがスポークBにNHRP Resolution Request
スポークAはハブから「直接やりなさい」と命令されたら、「よし、じゃあNHRP Resolution Requestを送ろう。ターゲットIPはサーバのプライベートIPとして送ろう」とハブに送り、ハブはOSPFやNHRP情報からスポークBへ転送する。
⑤スポークBがスポークAへNHRP Resolution Reqlyを返す
パターン１：スポークBはNHRP Requestの送信元を確認し、自身のトンネルIP、物理IP、配下のサブネット情報(192.168.2.0/24 など)などを格納し、スポークAへ直接NHRP Responseを返す。
パターン２：パケットの応答を返す際にスポークBも宛先を知らないためデフォルトルートのハブに流すが、ハブからはNHRP Redirectが来るのでスポークBもNHRP Resolution Requestを送りスポークAの物理IP、トンネルIP、サブネット情報などを得る
※なお、この間に発生するサーバーからの1回目のデータ応答パケットもハブ経由で送られ、ハブからスポークB側にも Redirect が発行される。
⑥スポーク間でIPsecトンネルを確立
・手順⑤によってIPsecトンネルが確立するので、あとの通信はSpokeToSpokeでやり取りをする。
・同時にShortCut機能により、各スポークのテーブルに、動的に物理IPとトンネルIPとリモートスポーク配下のサブネットが登録される。→これにより以降はSpokeToSpokeでやり取りできる。

これで大まかな流れは完了！！！

DMVPN Phase3でハブはどうやってOSPFの設定をしているの？

phase3の勉強をしていると、ハブがサマリールートやデフォルトルートを流し、通信の１step目は必ずハブを通るようにしている。でも、OSPFの設定を間違っていると、そもそも、あるスポークの情報をそのまま別のスポークに流してしまうということもある。なので、ここではハブはどうやってphase3の経路制御をしているのかをコマンドとともに見ていこう！

解決策：Totally Stubby Area
１．ハブとスポークでエリアを分割する
２．ハブにarea 1 stub no-summaryを実施
→タイプ３～５がデフォルトルートに変換される。つまり同一エリアの情報しか渡されない。
３．スポークにarea 1 stubを設定する
→タイプ4～5を受け取らない設定
＊まぁ正直、スポーク側でもno summaryを設定しても正常に動作する。
しかし、Cisco以外のメーカーではABRでもないのにno summaryが設定されているとはじかれたりしてしまうので、KISS(Keep is Simple,Stupid：シンプルにしておけ)の原則に則って設定する。

#ハブ
router ospf 1
 router-id 1.1.1.1
 
#本社内部LAN側は Area 0
 network 172.16.0.0 0.0.255.255 area 0
 
 #DMVPN トンネル側（Tunnel0）は Area 1 に設定
 network 10.0.0.0 0.0.255.255 area 1
 
 #★ここが核心コマンド！
 #Area 1 を「Totally Stubby Area」に指定する
 area 1 stub no-summary

#スポーク
router ospf 1
 router-id 2.2.2.2
 
#DMVPN トンネル側および配下LANを Area 1 に設定
network 10.0.0.0 0.0.255.255 area 1
network 192.168.2.0 0.0.0.255 area 1
 
#★スポーク側は「no-summary」なしの「stub」のみでOK
area 1 stub

こんな感じでいったん完了！！！

p.4 OSPFでデフォルトルートを配布するには—————-

デフォルトルートの配布とはいったい何なのだろうか。。。前提としてOSPFではインタフェース単位でOSPFに参加する。しかし、デフォルトルートはどのインタフェースにも属していないため、明示的に配布する必要がある。その旨を表現しているのが、本文中の「デフォルトルートの配布」である。
▼デフォルトルートの配布方法

ip route 0.0.0.0 0.0.0.0 出力先

router ospf プロセス番号
 default-information originate

▼そのほかのプロトコルでのデフォルトルートの流し方

▼BGP
router bgp AS番号
neighbor ネイバーIP default-originate

▼BGP（スタティックで準備しておく）
ip route 0.0.0.0 0.0.0.0 Null0

router bgp AS番号
 network 0.0.0.0 mask 0.0.0.0

▼EIGRP
int G0/0
 ip summary-address eigrp AS番号 0.0.0.0 0.0.0.0
 
▼EIGRP（スタティックで準備しておく）
ip route 0.0.0.0 0.0.0.0 Null0

router eigrp AS番号
　redistribute static

こんな感じでいったん完了！！！

p.5 BGPで認証はどうやってやるの？—————–

router bgp AS番号
 neighbor ネイバーIP password パスワード
 
 
以上！これでネイバーと一致すれば認証が完了する

こんな感じで完了！！

p.5 AS-PATHプリペンドの設定方法

route map マップ名 permit シーケンス番号
 set as-path prepend 自分のAS番号 自分のAS番号
 
router bgp AS番号
 neighbor ネイバーIP route-map マップ名 out

こんな感じで完了！

p.5 経路フィルタリングのやり方

route map マップ名 permit シーケンス番号
 set as-path prepend 自分のAS番号 自分のAS番号
 
router bgp AS番号
 neighbor ネイバーIP route-map マップ名 out

b:非セルラー
c:セルラー
d:ISM
e:干渉
　LPWAにはセルラーと非セルラーがある。
セルラーは国から許可を得た（＝免許がある）事業者が運用するLPWAのこと。一方、非セルラーは免許がなくても運用できるLPWAのこと。ほかにもいろいろな違いがあるので見ていこう！
▼セルラーと非セルラー

以上の表より、bには非セルラーが、cにはセルラーが、dにはISM、eには干渉が入る。

f:3GPP
　3GPPは3rd Generation Partnership Project（第3世代パートナーシッププロジェクト）の略。３GPPとは携帯キャリアが使う通信規格をすべて取り仕切っている世界規模の標準化プロジェクト。
昔は、日本の携帯を海外に持って行っても使用できなかった。それは日本と他国が違う方式で通信を運用していたから。しかし、３GPPが発足したことにより世界標準の取り決めができたため、どこの国に行っても通信を維持できるようになった。
LPWAの分野で３GPPがでてきたが、LPWAの独自ワードというよりも携帯通信全般（3G,4G,5Gなどなど）の標準化を実施しているのが３GPPという解釈で進んでいこう！

設問２
g:2　h:Gメーター管理サーバ　i:SIM　j:372　k:RESTful
g:2
　まずそもそも、IKEv2の目的はESPで共通鍵を交換する際の安全な土台を作ること。具体的には、相手の正当性の確認と共通鍵の生成がミッションとしてある。そのうえで、そのやり取りを何メッセージでやれるかということを考える。
　IKEv１では６メッセージ使っていた（アグレッシブモード）。しかし、IKEv2では４メッセージで終わる。そのからくりはTLS1.2からTLS1.3への進化と非常に酷似している。では、流れを見ていこう！
▼IKEv2のメッセージ
１．IKE_SA_INIT　Request（クライアント→サーバ）
　クライアントはサーバに以下を送付する
a 暗号化方式の提案（AESやSHAとか）
b 暗号化方式に付随する公開鍵
c 暗号化方式に付随する鍵生成のための材料（ノンス）
２．IKE_SA_INIT　Response（サーバ→クライアント）
　サーバは以下の情報をクライアントに返す
d 暗号化方式の決定
e 暗号化方式に付随する公開鍵
f 暗号化方式に付随する鍵生成のための材料
＊この時点でサーバは共通鍵の生成に成功している！
３．IKE_AUTH　Request（クライアント→サーバ）
決定された方式で共通鍵を生成する。これ以降、送付するすべてのデータはこのカギによって暗号化される
　クライアントは以下の情報をサーバに返す
g 暗号化したID（IPアドレス、証明書など）
h 暗号化した認証データ（ハッシュ値など）
i 暗号化したIPsec SAの提案
＊IKEなのにIPsec SA(ESPの定義）とかをやるの？と思うが、IKEv2ではESPもまとめてやっちゃおうよ！という思想のもとわずか４メッセージの中でIKE～ESPまで実行する
４．IKE_AUTH　Response（サーバ→クライアント）
共通鍵を使ってIDを復号し相手の正当性を確かめる
　サーバは以下の情報をクライアントに返す
j 暗号化したID
k 暗号化した認証データ
l IPsec SAの決定
以上が大まかな流れ。また、ここからわかる通り２往復で処理していることが分かるので答えには２が入る。

k:RESTful
　CoAPはWebシステムにおけるAPIシステムであるRESTfulAPIアーキテクチャを採用している。RESTやRestAPIなどと呼ばれることもある。

設問３
（１）l:トランスポート　m:順不同　n:重複　o:同期　p:バックオフ

m:順不同　n:重複
　順不同の意味は「順番がそろっておらずバラバラである状態」のこと。また、ｍ、ｎには様々な用語を入れられそうだが、同じ段落中に「CoAPではメッセージIDを利用することによってこれらのエラーに対処する」旨の記述があるので、メッセージIDで解決できる事象に紐づかなくてはならない。
メッセージIDでできるのは順番制御、重複検知なので、それを素直に書けばよい。
おまけで３大パケットトラブルを見ていこう！
▼３大パケットトラブル

1. 消失（パケットが消える）       ─── Loss
2. 重複（同じパケットが2個届く）   ─── Duplication
3. 順不同（順番が入れ替わって届く） ─── Reordering

p:バックオフ
　バックオフとは、直訳すると引き下がる、遠慮するという意味。通信の世界におけるバックオフとは、「パケットが届かなかった時にすぐに再送するのではなく、待ち時間を少しずつ伸ばして遠慮しながら再送する仕組み」のこと。
で、指数バックオフとは、遠慮する感覚を指数関数的に広げていくこと。

・1回目の再送待ち： 2秒間 待って再送する
・2回目の再送待ち： 4秒間（2倍）待って再送する
・3回目の再送待ち： 8秒間（さらに2倍）待って再送する
・4回目の再送待ち： 16秒間（さらに2倍）待って再送する

Q.なぜ指数バックオフが必要なの？
　再送が起きる多くの原因はネットワークの混雑であることが多い。そのような状況の中で１秒ごとに再送していると、さらに帯域が圧迫されてしまい、どんどん状況が悪化する。そのような状況を避けるために、待ち時間を長くしていき、遠慮しながら送信すれば帯域に負荷を最小限に抑えつつ再送もできるようになるという仕組み

（２）メッセージ：viii　理由：トークン値が一致するから　

まず、前提としてCoAPのACKはリクエストと同一のメッセージIDを使ってACKを返す。そのことより、(iv)では[0xbc90]をメッセージIDとしている。これと同一のメッセージIDを持つものは(i)である。そして、(i)のトークンは0x71である。そのトークンを持っているのは、(viii)である。以上より、(viii)はトークンの値が同一だから(i)の応答であると判断できる。

（６）判断できること：(i)の送信元が偽装されていないこと　
対応：(iv)を送信せずハンドシェイクを終了する

DTLSはUDP上で動作するTLSのようなもの。通常、TLSはTCP上で動作する。TCPでは既に３ウェイハンドシェークによって相手の正当性は確認できるのでTLSにわざわざ相手の正当性確認を組み込まない。しかし、UDPでは簡単に送信元を偽装できてしまうためDTLS上で相手の正当性を保証する仕組みが必要になる。それがcookieだ。cookieは相手の送信元IPなどをベースに作成されるため、本来の送信元と違うと不正な相手であると簡単に判断できる。
つまり、cookieがあると判断できることは、「送信元が偽装されていないこと」であり、もし、偽装されたと判断すると「ハンドシェイクを中断する」という挙動になる。

設問4
(1) Gメーター管理サーバやネットワークへの負荷の集中を避けられる
数万台のIoTデバイスが同時にGメーター管理サーバへ接続すると、Gメーター管理サーバーは、一瞬で数万同時接続を処理する必要がある。どんなにIoTデバイスのパケットサイズが小さかろうが、接続処理数が多いとその分だけ接続処理のためのCPUが消費されるため大きな負荷がかかってしまう。そのため、ランダム時間によって分散させる必要がある。

(３) TCPコネクション確立とコネクション切断の処理が行われるから
ここでは、HTTPとCoAPの違いによるHTTPのデメリットを聞かれている。前提としてHTTPはTCP上で動作し、CoAPはUDP上で動作する。そのため、HTTPだとセッションが切れると再度３ウェイハンドシェイクをしたりする必要があるため、必然的にパケット数が増える。一方、CoAPはUDPであるため必要な時に必要なやり取りだけを実施すればよい。

p.15 Q.そもそもLPガスって何？
LPガス（Liquefied Petroleum Gas：液化石油ガス）とは、一般的にプロパンガスと呼ばれる。道路の下のガス管から直接供給される「都市ガス」とは違い、ボンベを使う。
郊外の一戸建てやマンションの裏手にあるグレーのボンベがLPガス。LPガスはボンベ内のガスを使うため、「いつ、どのくらい使われたか」を把握する必要がある。
一昔前まではガス会社の社員がガスメータを目視で確認していたが、現在ではIoTによってわざわざ出向かなくてもいい構成になりつつある。

p.15　LPWAとは
LPWA（LowPowerWideArea）とは「省電力（LowPower）」で「遠域・広範囲まで届く（WideArea）」という特徴を持つ無線通信技術の総称。
無線通信技術にはWi-FiやLTEなどがある。では、それらと何が違うのか、表を見て理解しよう！
▼LPWAとLTEとWi-Fiの違い

p.15 Sub-GHz帯とは？

SubｰGHz帯とは、「Sub（～より低い）」＋「GHz」とういことなので１GHz以下の周波数のことを指す。日本だと920MHzが該当する。
ちなみに、低い周波数の特徴を以下で確認しておこう！
▼高周波と低周波の違い

Q.3G,4G,5G,6Gって結局何？
3GPPで、3G,4G,5Gなどの携帯キャリア通信の標準化を実施ているという話がでた。でも実際、それらがよくわかっていない。なので、見ていこう！

Q.4Gってなに？
4Gは4Generation(第4世代）の略で、携帯キャリアにおける無線通信規格の一つ。これは3GPPによって標準化されている。
簡単に言うと、４G≒LTEという解釈で問題ない。
▼4Gの流れ

[スマホ/IoT機器]
   │ （無線電波：LTE）
   │ （ベアラ通信）
   ▼
[LTE基地局 (eNodeB)]
   │ （キャリア専用の有線網）
   │ （MME/HSS）
   │ 
   ▼
[キャリアのコアネットワーク (EPC)] ★ここでSIMの認証やパケット処理をする
   │ 
   │ （GTPトンネル）
   │ 
   ├─▶ (A) インターネットへ出る場合 ──▶ [ISP/Internet (BGP等)] ──▶ [相手のサーバ]
   │
   └─▶ (B) 今回のZ社のような閉域網 ──▶ (IPsec VPN) ──▶ [Y社データセンター]

用語解説：
MME(Mobility Management Entity)
　LTEにおけるユーザを認証する司令塔。ユーザからの認証を確認するためにHSSを呼び出したり、GTPトンネル確立の指示やベアラ通信の指示を出したりする。
HSS(Home Subscriber Server)
　MMEが認証をする際に使うデータベース。MMEは受け付け業務なので、実際のユーザ情報は保持していない。そのためHSSを使って、ユーザ情報を確認する。
ベアラ
　ベアラは仮想的な通信パイプのこと。
携帯電話の電波にはいろいろなデータが流れる。音声、動画、緊急速報。これらは緊急度合いが違う。そのため、すべてを同じ優先度で扱ってはならない。そこで、要はQoSを実現するためにベアラと呼ばれる、仮想的なパイプを準備する。用途ごとにベアラは作られる。＝それに応じてGTPも増える。

Q.5Gって何？
5Gも基本的な挙動は4Gと同じ。しかし、使っている機器や周波数帯などが少しずつ違う。ということで、それを見ていこう！

要は、使う周波数帯をより高周波にすることによって、より高速性を出したのが５G。で、異なる周波数を出すには、異なる媒体が必要なので、４Gとは別の機器・名称として扱われる。
また、高周波は障害物や長距離に弱いため、各地にミニ基地局を新たに施設することによってその弱点を補っている。

▼プラチナバンド、ミリ波、subGHz、sub6などの違い

＊プラチナバンド：携帯キャリアが保証している＆かつSubGHz帯のこと。

Q.Sigfox,LoRaWAN,LTE-M,NB-IoT
LPWAには様々な方式がある。では、以下で見ていこう
▼LPWA（省電力・広域通信）のまとめ

▼具体例
では、農家でのLoRaWAN使用例を見ていこう！
前提：
　・LoRaWANは基地局を個人で立てれる（1~3万程度)
　・農家は田畑の状況をリアルタイムで知りたい
　・家のあたりには数キロに及ぶ自分の田畑がある
　　→これを目視確認したりするのは面倒くさい
では、以上の前提をユースケースとしてやっていこう！
１．LoRaWANの基地局をたてる
　基地局は1~3万程度で立てられる。
　コンセントにつないだり自宅のLANにつなげれば簡単に起動できる
２．田畑用のLoRaWANセンサを購入/設置する
　①製品のDevEUI(製品識別子)とAppKey(パスワード)を確認する
　②①の情報を製品に紐づくアプリケーションで登録する
＊AppKeyがあることによって、センサーからのデータは既に暗号化された状態でネットワークを経由するため、正しいAppKeyを持っているユーザでなければ復号できない。
　③目的の箇所にセンサーを設置する
３．アプリケーションで状況を確認
　アプリケーションにログインし、リアルタイムで現状を把握する。
＊アクチュエータ（物理的な動作をする機器）も購入しているなら、そのリアルタイム情報からサーバがアクチュエータに適切な指示を出し、水流を調整したりといった物理的な制御もできるようになる。　
→ちなみにSigfoxは通常時は受信機能を閉じているためサーバからアクチュエータへの命令動作には向いていない。Sigfoxがデータを送信するタイミングで受信機能も解放されるがそれ以外は無理。また、１日に送信できる量は140、受信できる量は4回までという制限もある。

以上がLoRaWANの流れだった。ちなみに、Sigfox、LTE-M、NB-IoTも基本的には同様の流れで処理される。ただ、使われている個々の名称が若干異なる。

p.16　LPWA閉域接続サービスってなに？

Q.そもそも閉域網って何？普通のインターネット接続と何が違うの？
A.インターネットという公道から完全に隔離された、関係者しか入れない私道のこと。よく耳にするMPLSも閉域網技術の代表例である。
このような閉域網があることによって、『外部に公開する必要のないサーバ＆かつ正規の人からはリモートからでもアクセスさせたい』という要件において、プレフィックスをインターネットに公開することなくアクセスできるようになる。

▼一般的にインターネット接続

【一般的なスマホや光回線（インターネット接続）】
[スマホ] ──＞ [キャリア基地局] ──＞[キャリアコア網] ──(APNによって選出されたインターネットGW)──＞ 【一般のインターネット】 ──＞ YouTube等
                                                            ▲ ここで公道（インターネット）に出る！

▼閉域網の接続

【LPWA閉域接続サービス】
[Gメーター] ──＞ [キャリア基地局] ──＞ [キャリアコア網] ──(APNによって選出された専用GW)──＞ 【Z社の専用閉域網】 ──＞ Z社拠点ルータ
                                                                ▲ インターネットに1ミリも出ない！

Q.そもそもなんでZ社を経由するの？
シンプルに、Z社を中継点とする意味が分からない。LTEを使っているなら、そのままISPに行き、そのISP経由でY社まで転送してくれれば通信自体は成立するように見える。しかし、本文中にはなぜかD社を経由している。その理由を紐解いていこう！
理由1：暗号化の肩代わり
　IoTデバイス（Ｇメータ）は極力軽い処理を担当させたい。そのためIPsecのような強力な暗号化処理は外部に委託したい。そのためZ社にIPsecをやってもらうという対策が取られている。
*ただ、LTEによって、端末⇔基地局間はデフォルトで暗号化済み。ここで述べている暗号化はインターネット上の話。
理由２：そもそもIPsecは拠点間通信に向いている
　もし、Ｇメータが暗号化処理をできたとしても、１台1台とIPsecルータ２がセッションを張るとなるとものすごい負担になる。そのため、Z社側で一度集約してから１対１でIPsecルータ２とやり取りをした方がはるかに運用が楽だから。
理由３：コスト削減
　閉域網サービスを利用するには、ISPと閉域用の契約が必要になる。これは月額数百～千万の費用が掛かる。しかし、Z社のような、他社クライアントと共有利用させることによって閉域網サービス提供を生業としている業者に頼めば安く抑えられるから。
理由４：マルチキャリア対応のため
　閉域網の用途はわかったけど正直、Y社が契約しているSIMのキャリア専用の閉域網を利用すれば解決すると感じる。なぜわざわざ外部のZ社の閉域網を使うのか。それはマルチキャリア対応のため。もし、SIM提供キャリアの閉域網を使うと、ほかのキャリアのデバイスを扱ったときに、またそのキャリアと閉域網契約を結ばなくてはならなくなる。しかし、中間でZ社を挟ませればY社はZ社とのみIPsec通信をする準備をすればよいだけになるので運用やコストの面、また、マルチキャリアの面からもメリットが得られる。
＊Z社はおそらく閉域網サービス接続を生業としているため、ソフトバンク、ドコモなどの複数のキャリアと既に閉域網接続をしている。その中の一部をY社に割り当てるというながれ。

👆のことからもわかる通り、逆を言えばIoTデバイス自体がIPsecをできるようになったら閉域網は不要ということになる。というわけでもない。結局IPsecでは１対１の通信に集約させたいから、その集約点が必要になる。IoTデバイス１台１台がIPsecを張ると、ルータのセッション情報がパンクする。なぜならIoTデバイスは概して何万台もあるから。そこらのリモートワーカーがIPsecをするのとではわけが違う。リモートワーカーの場合は人数が少ないから閉域網を通らずとも直接PCがIPsec処理をして接続できる。

p.16　物理的なデータの流れの全貌
閉域網やIPsec、Z社サービス拠点、などいろいろなものが一気に記されていて頭がこんがらがる…では、それを解決していこう！

[ Gメーター ]
    │ ① 無線（LTE-M）
    ▼
[ キャリア基地局 ]
    │ ② 有線（キャリアの社内光ファイバー網）
    ▼
[ キャリアのコア網 ＆ GW（ゲートウェイ）]
    │ ★APNを見て「Y社用だな」と判別！
    │ ★MPLSラベル（専用タグ）を貼って専用ルートを通す！
    │ ③ 有線（専用線）
    ▼
[ Z社拠点（ルータ1）]  ※ここまでが「閉域網」！
    │
    │ ★ここでMPLSラベルを剥がす！
    │ ★Y社に向けてデータを「IPsec（カプセル化暗号化）」する！
    │ ④ 有線（一般的なインターネット回線）
    ▼
[ イ ン タ ー ネ ッ ト ] （公道）
    │ ⑤ 有線
    ▼
[ Y社拠点（ルータ2）]
    │ ★IPsecの暗号化カプセルを解く！
    │ ⑥ 有線（Y社の社内LAN）
    ▼
[ Gメーター管理サーバ ]  ★無事到着！

１．Gメータ→キャリア（基地局）
　GメータはLTE回線を使ってキャリアまで行く。
　　その際にキャリアはSIMで認証をする。
２．キャリア（基地局）→キャリア（MME）→キャリアのゲートウェイ
　①キャリアにつくと、まずSIM情報の認証が必要になるため、MMEに渡す。
　②MMEはHSSと呼ばれるデータベースを使い認証処理をする。
　③SIM内のAPNから適切なゲートウェイを判別する
　④処理が完了すると、無線ベアラやGTPトンネルなどを構築しネットワーク接続可能な状態になる
３．Gメータ→閉域網→Z社ルータ
　①Gメータは無線ベアラを通して基地局にいく
　②基地局がGTPトンネルを通してAPNのゲートウェイまで行く
　③ゲートウェイは適切なラベルを張りZ社ルータ（CEルータ）まで運ぶ（＝MPLS）
　④Z社ルータの手前のPEルータでラベルを外してからZ社ルータに届かせる
４．Z社ルータ→Z社IPsecルータ１
Z社ルータに届いたパケットは普通にルーティングをしてZ社IPsecルータに渡す
５．Z社IPsecルータ１→Y社IPsecルータ２
　①Z社IPsecルータ１は宛先からIPsecが必要であると判断する
　＊この時に使うのがSPD（SecurityPolicyDatabase）と呼ばれるどの通信をIPsec適用にするかのデータベース。この中にSPIがあるので、それに基づいてSAD内を検索する
　②SADからSAを取り出し、パケットヘッダーにSPIを付与する
　＊SAD（SecurityAssociationDatabase）はSAを保持しているでーばベース
　＊SPI（SecurityParameterIndex）はSAを特定するための識別子
　③適切な暗号化をしてY社ルータ２まで届かせる
６．Y社IPsecルータ２→Gメータ管理サーバ
　①パケット内のSPIを確認する
　②SPIでSADを検索し、SAを割り出し、SAに従って復号や正当性確認を実施する
　③復号された中身をSPDと比較して正当性を確認する
　④Gメータ管理サーバへ転送する

👇IPsecの詳細はこちら👇

平成28年（2016年）ネスペ午後Ⅰ　問二　解答解説

設問1 ア：AES　イ：事前共有鍵　ウ：SIMカード　エ：APN　オ：NAPT　カ：CONNECTア：AES　　WEPやWAPまではRC4ベースの暗号化を採用していた。しかしこれには脆弱性があるので、WPA2からは、より強固なAESが使わ...

ascend-beyond.com

2026.07.15

Q.IKEv1 phase1アグレッシブモード+phase2について
IKEv1のフェーズ１（isakmp sa）のアグレッシブモードの流れを見ていこう！
１．クライアント→サーバ
以下の情報を渡す
・暗号化方式の提案
・暗号化方式に付随する公開鍵,パラメータ
・ID
２．サーバ→クライアント
以下の情報を渡す
・暗号化方式の決定
・暗号化方式に付随する公開鍵,パラメータ
・ID
・認証データ
３．クライアント→サーバ
以下の情報を渡す
・認証データ
＊ここまでがフェーズ１のアグレッシブモード。ここからはついでにフェーズ２を記載していく
４．クライアント→サーバ
フェーズ1で作成された共通鍵をを使いIPsec SA（ESP）の方式を提案する
５．サーバ→クライアント
IPsec SAの方式を決定する
６．クライアント→サーバ
ESPの準備完了したよ！と通知する

Q.IKEv1 phase1メインモード+phase2について
IKEv1のフェーズ１（isakmp sa）のメインモードの流れを見ていこう！
１．クライアント→サーバ
僕がサポートしている暗号化方式はこれです！と教える
２．サーバ→クライアント
よし、じゃあ暗号化方式はこれでいこう！と決定する
３．クライアント→サーバ
では、実際の鍵生成のフェーズに入ろう！
・公開鍵
・ノンス
をサーバへ渡す
４．サーバ→クライアント
・公開鍵
・ノンス
をクライアントに返す
５．クライアント→サーバ
ID、認証データを暗号化してサーバへ渡す
＊サーバはこれを検証して正当性を確認できる
６．サーバ→クライアント
ID、認証データを暗号化してクライアントへ渡す
＊クライアントはこれを検証して正当性を確認できる
以上の６メッセージを交換後にフェーズ２へ移行する

p.17 CoAPとは
CoAPはConstraind Application Protocolの略。その名前の通り、制約下のもと動作させることができるプロトコル。特徴を以下にまとめる。
・UDPベース
　制約の多い環境では軽量さが好まれる。TCPだとセッションなどがありとても面倒くさい。また、順序制御などはアプリケーション側のメッセージを使って実施する
・RESTfulAPI
　RESTfulAPIと呼ばれる、GET,POST,PUT,DELETEなどのようにHTTPと同じように操作できるためWebエンジニアにはなじみやすい
・IoT向け
　IoTで求められるものは、貧弱な環境でも利用できること。貧弱とは、「バッテリー容量が極小」、「ネットワーク帯域が極細」、「CPU能力が低い」、「メモリ少ない」という環境のことを指している。このような環境で動作できるのがCoAP。

p.17 CoAPのメッセージIDとトークン
メッセージIDやらトークンやらが出てきていまいちよくわからない。なので、ここではメッセージIDとトークンの役割を明確にしつつ、それらの違いを紐解いていこう！
メッセージID：
　再送制御、順序保証などのTCP機能を肩代わりしてくれる機能。
トークン：
　リクエストに対するレスポンスを対応づける機能。

Q.なんでメッセージIDだけじゃダメなの？トークンいらなくね？
メッセージＩＤとトークンは管理対象が異なる。メッセージＩＤはいわばパケットの管理を行う。一方トークンはリクエストとレスポンスの対応関係を整理するもの。
もし、メッセージＩＤだけになると、受信側は「あれ？これはどのリクエストに対する回答なの？」と処理ができなくなってしまう。たとえ、「あー、順番通りにきているな。欠損ないな。」というところまで分かったとしても、どのリクエストに対応しているかまではわからない。
そういった観点で、やはりトークンは必要と言える。

Q.TCPにおける欠損の処理方法
TCPでは様々な方法を使ってパケットロスを検知している。
タイマー：
　通常は受信側はACKを返す。それによって送信側は、「あ、俺のパケット届いたな」と判断できる。しかし、欠損すると受信側からはACKが返ってこない。その際にタイマーを稼働させておけば「あ、送信からタイマーの時間経過したけどACKなしか。。ということは欠損してるかも！」ということで欠損を検知して再送をする
重複ACK：
　受信側は、順番を飛ばしたパケットが届くと「いや、○○番のパケット届いていないよ！ちょうだい！」と送信側に伝える。これを３回受け取ると送信側は「あ、欠損してるかも」と判断して再送する。
＊１，２回だと一時的な遅延や順不同によるものかもしれないため、再送が無駄になることがあり非効率。

Q.CoAPにおける欠損の処理方法
CoAPにおける欠損パケットの処理方法はタイマー方式のみ。CoAPにはCON、NONの２つのメッセージがある。CONは確認応答が必須で、NONは確認応答が不要。
CONの場合に確認応答が一定時間返ってこない場合は、欠損と判断して再送される。

p.23 HTTP1.1について
HTTPには様々なプロトコルがあるHTTP/1.0から始まり現在のHTTP/3まで続いている。では、それらの進化を理解していこう！

ARPパケットには４つの専用フィールドがある。
▼ARPパケットのフィールド

送信元MACアドレス
送信元IPアドレス
宛先MACアドレス
宛先IPアドレス

では、ARPパケットのやり取りを具体的に見ていこう！
▼ARPパケットの流れ
端末Aが端末BのMACアドレスを知りたいというユースケースで流れを見ていこう。
１．ARPリクエスト
　端末Aが以下の構成でARPパケットを作りブロードキャストする

２．ARPリプライ
ブロードキャスト受信した端末Bは宛先IPが自身のIPであることから、自分がARPリプライをユニキャストで返すと認識する。

以上の表より、a,b,cに適切な用語を割り当てることで回答を導ける。

設問２
（１）d:16　e:48　f:64

前提知識として、IPv6アドレスは以下の特徴を持つ。
▼IPv6アドレスの特徴
・16進数で表現される
・1ブロック16ビット
・128ビットで構成される
・前半64ビットをサブネットプレフィックスと呼び後半64ビットをインタフェースIDと呼ぶ

以上の前提知識を踏まえつつd,e,fを埋める。

（２）データリンク層で通信可能な範囲
よくやってしまうミスが「ブロードキャストが届く範囲」と書いてしまうこと。データリンク層で通信可能な範囲と重複しているように見えるが、IPv6にはブロードキャストは存在しない。そのため、IPv6において、そのような回答は✖にされる可能性がある。もし問題が「IPv4においてデータリンク層で通信可能な範囲」と表現されていたらブロードキャストが届く範囲としてもOK。でも今回はIPv6なので、「同一リンク内」というニュアンスが入っている解答の方がベターになる。

（３）同じデータリンク層上に同じIPv6アドレスを使用しているノードがいないことを確認するため

SLAACとは、DHCPサーバを使わずにルータと端末間で動的にIPv6アドレスを生成する。要は、DHCPサーバによる一元管理に依存しないということ。しかし自由度が上がった分、重複管理なども端末が実施する必要がある。そのプロセスがまさに(i)と(v)である。
あらかじめ自分が使う予定のアドレスをリンク内に聞いておくことで、重複を防いでいる。これはIPv4のARP Probeと原理は同じである。
自分が使う予定のアドレスを拡散して、既に使われていたら応答が返ってきて、応答が返ってこなければ使われていない（重複なし）と判断できる。

（４）GUA:2001:db8:aabb:1:8:800:200c:417a　プレフィックス:64
LLAがfe80::8:800:200c:417a
プレフィックスが2001:db8:aabb:1::/64
これはシンプルにLLAの後半64bitとプレフィックスの前半64をつなげればいいだけ。

設問４
（１）インターネットからルータA,ルータB及びFWにアクセスできないようにするため
そもそもLLAとは同一リンク内のみで有効なアドレス。つまり、リンク外からはアクセスできないアドレスとなる。つまり、況いわんややインタフェースにLLAのみの割り当てとは同一リンク外からはアクセスできなくなるため、それをうまく利用すればアクセス制限にも利用できるということ。

（２）traceroute6を利用して調べるときに各機器を識別しやすくなる
前提条件としてtraceroute6はLLAに対応し切れない。だから、GUAを設定している。そもそも、もしLLAをtraceroute6で完璧に扱えるのであれば、スタティックなLLAを割り当てればデバイスの識別も可能になるため要件を満たせる。しかし、実際はそうではない。なので、GUAをスタティックに割り当てる必要がある。
＊厳密にはtraceroute6はLLAに対する受信はできるが応答は返せないとう表現が正しい

Q.インタフェースe~fにGUAを割り当てるならa~dに割り当てないのはどういう了見？
A.e~fとa~dの決定的な違いはどこに配置されているか、である。要は、a~dはFWの外側に配置されているのである。一方e~fはFWの内側に配置されている。以上より、もしａ～ｄにGUAを割り当ててしまうとインターネットから無秩序にアクセスされてしまう可能性がある。そのためa~dにはGUAをつけないことが望ましい。

Q.tracerouteの経路途中にLLAのみデバイスがある場合はどうなるの？
tracerouteの宛先自体はGUAを持っているが、その経路途中にLLAのみのデバイスがあったらどうなるのか。２択の選択肢が浮かぶだろう。１つは途中でtracerouteが中断される。もう一つは、そのデバイスのみ表示されずtracerouteは継続する。答えは後者である。

1. 2001:db8:xxxx::1 (ISP側のルーター)     <-- GUAが見える
2. * * *                                  <-- ルーターA（GUAがないので応答不能・隠れる）
3. * * *                                  <-- ルーターB（GUAがないので応答不能・隠れる）
4. * * *                                  <-- FWの外側 d（GUAがないので応答不能・隠れる）
5. 2001:db8:yyyy:1::x (監視サーバー)      <-- パケットが届くので、GUAが再び表示される！

このような👆表示になる。

Q.これはどのネットワークのことを言っているの？

なんか、回りくどく書かれていて結局どこのネットワークを指しているのかよくわからなくなる。
まず、順番に紐解いていこう。
１．FWと各拠点のL3SWとの間→広域イーサ網
２．PCやサーバを接続しないネットワーク→広域イーサ網の説明
以上より、「いや、シンプルに広域イーサ網ってかいてくれよ！」って感じるが、要はこの文は広域イーサ網を指しているということ。

Q.そもそも、なんでa~dはGUAを割り当てる必要がないの？

そもそもGUAが必要なパターンはリンク外から宛先としてそのデバイスが指定されるとき。その点、インタフェースa~dは宛先として指定されることがないのでGUAもいらない。LLAさえあれば転送処理はできるので、わざわざGUAをつける必要もない。

Q.GUAがなかったらルータにリモートアクセス（SSH,telnet）できないのでは？
たしかにLLAのみではリンク外からのアクセスはできなくなる。しかし、実務ではいろいろな方法でその問題を解決している。それが踏み台サーバを用意すること。
▼踏み台サーバの流れ
１．当該ルータと同一リンクに踏み台サーバを準備する
２．管理用PCで踏み台サーバにSSHやtelnetでアクセス
３．当該ルータのLLAあてにSSHやtelnetでアクセス
　（同一リンク場であるためLLAでのアクセスが可能）
以上のような手順でLLAしか割り当てられていない機器に対してもリモートアクセスが可能になる方法がある。

（３）PCが送信したRSメッセージに対してRAメッセージを応答する
下線⑤からSLAACのプロセスに関する問であることが分かる。そのためSLAACにおけるルータの挙動を回答として提示する。
▼SLAACの流れ
１．PCがRSメッセージを送信
PCはどの自分のアドレスとして「どのプレフィックス？デフォルトルートは？」などの情報を求めるためのRSメッセージをマルチキャストする。
２．ルータがRAメッセージを送信
ルータはプレフィックス、デフォルトルートなどの情報をPCに教える
以上の流れより、L3SWがやることは「PCが送信したRSメッセージに対してRAメッセージを応答する」である。

（４）ア: fe80::1　イ: b　ウ: fe80::2　エ: c　オ: fe80::1　カ: d　キ: fe80::2　ク: f　ケ: fe80:::1

＊なお、ネクストホップアドレスを聞かれている場合はプレフィックスをつけない。プレフィックスをつけるのは宛先ネットワークなどのネットワークを聞かれている場合はつける。
＊GUAとLLAの２つを持っている機器で回答にLLAが選ばれるのは、OSPFv3を動作させているから。OSPFv3はLLAで経路交換するため、回答も必然的にLLAになる。
ア: fe80::1
宛先が::/0、つまりデフォルトルートなのでルータAに渡す必要がある。なので、答えは、ルータAのインタフェースaであるfe80::1である。
*fe80::1/64としないように！
イ: b
出口インタフェースはルータAと接続しているbである。
ウ: fe80::2
宛先ネットワークが2001:db8:yyyy:3::/64なので、これはL3SW1のh配下であることが分かる。で、そこに行くためにはFWを経由する必要があるので、FWのdであるfe80::2となる。
エ: c
出口インタフェースはFWと接続しているcである。
オ: fe80::1
宛先が::/0、つまりデフォルトルートなのでBに渡す必要がある。なので、答えは、ルータBのインタフェースcであるfe80::1である。
カ: d
出口インタフェースはルータBと接続しているdである。
キ: fe80::2
FWから2001:db8:yyyy:3::/64へ行くには、まず、2001:db8:yyyy:3::/64はL3SW1のhあてであることが分かる。なので、ネクストホップは、L3SW1のFWとつながっているインタフェースgのアドレス。つまり、fe80::2である。
（gはGUAとLAAの両方を持っているがOSPFv3ではLLAで経路交換するため必然的にLLAが選出される）
ク: f
出口インタフェースはL3SQ1と接続しているfである。
ケ: fe80::1
宛先が::/0、つまりデフォルトルートなのでFW側に渡したい。FWのインタフェースfのアドレスはfe80::1となる。

（５）ホップリミットが０になるまで相互に転送し合い、破棄する
項番２はQ社が割り当てられているプレフィックスへのパケットはNull0で破棄している。これがあることによってルータAとルータBのループを防ぐことができる。では、項番２がある場合とない場合のケースを見ていこう！
▼項番２がない場合
１．インターネットからISPに宛先IP2001:db8:yyyy:9999::1として届く
２．ISPがプレフィックスを確認し、Q社に割り当てた2001:db8:yyyy::/48の範囲内あることを確認
３．Q社へ転送＝ルータBに転送
４．Q社は宛先を確認するが、9999に該当するものはないと判断
　Q社のGUAを確認すると1~3までしかない。9999に該当するものはない
５．わからないルートはデフォルトルートに流す＝ルータAに流す
６．ISPは宛先IP2001:db8:yyyy:9999::1を再度受け取るが、プレフィックスはQ社なので再度ルータBに転送
７．Q社は受け取るが該当がないのでルータAに転送
８．以上のプロセスがホップリミット０になるまで繰り返される
このように、自身に割り当てられたアドレスの範囲内なんだけど実際は使っていないアドレスはループを引き起こしてしまう。

▼項番２がある場合
１．インターネットからISPに宛先IP2001:db8:yyyy:9999::1として届く
２．ISPがプレフィックスを確認し、Q社に割り当てた2001:db8:yyyy::/48の範囲内あることを確認
３．Q社へ転送＝ルータBに転送
４．Q社は宛先を確認するが、ぴったり9999に該当するものはないと判断。
５．しかし、項番２に2001:db8:yyyy::/48宛てはNull0へとあるのでそこに転送する
６．Null0は破棄を意味するので、そこでそのパケットは破棄されて終わる。
このように、Null0を作ることによって、自身が割り当てられたプレフィックス内＆かつ実際は使っていないアドレスが送られてきても、それを破棄できる。

p.3 そもそもなんでIPv6対応させる必要があるの？
デュアルスタックやなんやらでIPv6に対応させることは面倒くさそう。それなのになぜわざわざやる必要があるのか..。
理由1：IPv6が普及し続けているから。
　現在、IPv6は普及し続けている。そのうち、IPv6のみにしか対応していない環境も生まれる。そうなったときにIPv4にしか対応していないと通信が複雑化してしまい面倒くさくなる。
理由２：IPv6の方が早いから
　IPv4はPPPoEと呼ばれる処理をする。これはISPの手前にある「網終端装置」という認証用のゲートを通らなければならないというルールがある。そのためそこで大渋滞を起こしてしまう可能性がある。一方IPv6はIPoEと呼ばれる処理を実施しており、これは認証ゲートを通らず広い空間を利用できるため、遅延の可能性も抑えることができる。　
＊IPv4単体ではIPoEを使えないという日本独自のルールがある。
理由３：処理の単純化のため
　IPv4でもカプセル化技術を使えばIPoEに対応できる。しかし、毎回カプセル化処理をするとルータへの負担が増大して面倒くさい。

Q.海外にはそもそもPPPoEとIPoEという概念がないのはなぜ？
実はIPv4でIPoEが使えないのは日本独自の大人の事情があるから。そもそも海外ではイーサネットに流すのが当たり前すぎて、PPPoEやIPoEという概念がない。そのためIPv4でもイーサネットでそのままISPに流すことが可能。では、なぜこのような違いが生まれたのか見ていこう！
A.海外はISPで一本化だが、日本はISPと光回線が別々の事業者で運用されているから！
海外の多くは、テレビの同軸ケーブルなどすでに施設されているインフラを使うことによって、独自のインフラを築けた。その結果、テレビ会社がISPサービスも提供できISPサービスと回線の一本化に成功した。一方、日本は国営の日本電信電話公社（現NTT）が主導で日本全国に電柱などのインフラ設備をを施設するという超巨大プロジェクトが実施された。その結果、ほかの会社が今から「独自に日本全国にインフラ作ってやる！」となっても時間・コストともに無理ゲーとなってしまう。
そのため、日本では回線はNTTが提供し、ネットワークはISPが提供するという歪いびつで非効率な構成になってしまった。
なお日本の法律でNTT東西は直接ISP事業をしてはならないという独占禁止に関連する決まりがあるためNTT自体がISPになって通信を一本化するということもできない。
＊しかし、直接ではなくNTTグループ会社の一部がISPとなることはOK

▼覚えておきたい前提知識
・日本の場合、IPoEに対応しているのはIPv6のみ
　→これによりIPv4単体ならPPPoEは必須となる
・日本は回線提供会社とISP事業会社が分かれている
　→これによりISPはL2TP over PPPの認証が必要になる。＝L2TP over PPPを使った認証が必須
・海外は回線とISPが一本化されている
　→これにより回線でユーザを識別できるのでL2TP over PPPの認証が不要。＝IPoEが当たり前
・IPv6を使う
　→IPoEが使える→回線単位での認証が可能になる→L2TP over PPPで認証することが不要になった
＊回線でユーザを認識し、その情報をISPと共有することでISP側は認証をすることなく通信の中継ができるようになる。

Q.PPPoEとは？
PPPoEは、PPP over Ethernetの略。要はイーサネット上でPPPを実現する技術。
まず、PPPとは１対１用の認証プロトコル。
次にイーサネットとは１対多の通信規格。
＊注意点として、GRE over IPsecのように２つの独立したプロトコルをただ重ねたわけではないということ。GREヘッダがあって、その上にIPsecヘッダがあるみたいな構造とは違った構造をとるのがPPPoE。PPP over EthernetとはPPPの上にEthernetという規格を重ねたことを意味するのではなく、PPPoEという単一の専用プロトコルを意味している。つまり、PPPoEヘッダという単一のヘッダが存在しているということ。

▼PPPoEのパケット構成

一番外側（道路を走るための封筒）
  └─①【イーサネットヘッダ】（送信元/宛先 MACアドレス、EtherType: 0x8864）
      └─②【PPPoEヘッダ】（Ver, Type, Code, Session ID など 6バイト）
          └─③【PPPヘッダ】（Protocol ID, 認証データなど）
              └─④【IPヘッダ】（送信元/宛先 IPアドレス）
                  └─⑤【データ本体】（Webサイトのデータなど）

このように、PPPoEは独自のPPPoEヘッダが存在していることがわかる。また、そのPPPoEヘッダ内にあるSession IDがトンネルの役割を担い、論理機的な１対１通信を実現している。

▼IPoEとPPPoEの違い

【旧：PPPoEの道路】
  [あなたの家] ─(光回線)─> [NTT網] ─> ★【網終端装置（激狭の関所）】 ─> [ISP] ─> [ネット]
  ※夜間になると、この「網終端装置」に全員の通信が集中して大渋滞が発生していた！

【新：IPoEの道路】
  [あなたの家] ─(光回線)─> [NTT網] ────────> 🚀【大容量GW（爆広の高速道路）】 ─> [ISP] ─> [ネット]
  ※激狭の関所を完全にバイパス（迂回）して、スカスカの巨大ゲートウェイを通る！

PPPoEの最大のボトルネックは網終端装置である。一方、IPoEでは大容量ゲートウェイであるため、大量の通信を混雑なく実行できる。そのため現在ではIPoEが主流になっている。しかし、ここで１つの疑問が浮かぶ。「いや、じゃあPPPoEでも終端装置の性能あげればよかったじゃん。なんでしなかったの？」と。では、その疑問を答えていこう！

Q.PPPoEではなぜ網終端装置を改修しなかったのか
PPPoEの最大のボトルネックは網終端装置。それが原因で今ではIPoEが主流になりほぼ利用されなくなってしまった。「いや、じゃあPPPoEでも終端装置の性能あげればよかったじゃん。なんでしなかったの？」と。それには、「日本の法規・契約の壁」「技術的な限界」「コストの壁」という3つの巨大な理由があったため、最終的に「PPPoEを諦めて、IPoEという新しい仕組みを作った方が早い＆安い」という結論になったのだ。
理由１：ルールがガチガチだったから
　網終端装置(NTE)はNTTの持ち物だが増設するためのルールは総務省とNTTの間で厳格な取り決めがあった。それが「通信料ではなくセッション数（契約者数）が増えないと増設してはならない」というもの。しかし、スマホ、YouTube、ゲームの普及により１人のユーザが大量のデータ通信をするようになり、そのルールでは対応しきれないという問題が生まれるのは時間の問題となった
理由２：技術の限界
　PPPoEはユーザのセッション情報（接続状態、認証情報）をステートフルにメモリに保存しなければならない。そのため大量のユーザが接続してくると、セッション処理などで莫大なメモリ、CPUを消費してしまう。10Gbps、100Gbpsといった超巨大なデータを流しながら、何万人分の状態管理をミリ秒単位で行う機器は、技術的に作るのが超難しく、CPUやメモリに莫大な負担がかかる。
理由３：国の戦略・コスト
　枯渇しきった旧世代のIPv4(PPPoE)にこれ以上投資するよりも、IPv6へ一気に日本全体を移行させたいという政策的な狙いがあった。

Q.なぜ日本ではIPv4のIPoEができなくて海外ではできるの？
海外では当たり前のようにIPv4でIPoEが実施されている（そもそも当たり前すぎてIPoEという概念すらない）。でも、日本ではなぜかIPv6でしか実現できない。それはなぜ？
理由１：構造・法律の壁
　海外：回線とプロバイダ（ISP）が一本化されているため、クライアントのルータが起動した瞬間に自社のDHCPサーバでIPv4（またはCGNAT用プライベートIPv4）を割り当てる。
　日本：日本の法律によってNTTはプロバイダ業務（IPアドレス変換、認証など）を実施してはならない。そのため、NTTにぶら下がっている大量のプロバイダに適切に振り分ける仕組みが必要だった。
理由２：アドレス数の限界
海外ではIPv4が枯渇した後も、プロバイダ専用のプライベートIPv4あどれs（100.64.0.0/10=419万)を割り当ててCGNATしていた。
＊10.0.0.0/8などの一般プライベートIPは、各家庭のWi-Fi(LAN)と衝突するのでWAN側では使えない。
　海外：NYエリア、LAエリアのように地域ごとに網が分割されているため、各地域で約419万のプライベートIPを何度も使いまわせた
　日本：NTTのNGNには全国2,000万人以上が１つのネットワークにつながっている。そのため、419万しかないプライベートIPを使うと重複が起こり通信が壊れる。つまり、どうしても一世帯に１つのIPアドレスが必須。
＊なおポート番号の範囲をユーザごとに割り振ると、識別できそうだが2000万人すべての通信をTCP層まで見ようとするとCPUに大きな負荷がかかる。そのため基本的にはL3のIPのみの通信を前提に考えるべき

まとめると、IPoEではユーザID/パスワードの認証ではなく、IPアドレスベースの認証をすることによって処理を軽くしている。つまり、IPoEはIPアドレスが基盤なのでそれが安定して割り当てられなかったら、そもそもIPoEは機能しないよねってこと！

p.3 広域イーサネットサービス網とは？
広域イーサネットサービスについての説明では、「超大きなL2スイッチに接続できるサービス」と表現されることが多い。要は、物理的につながっていない拠点間同士でも、あたかも同一L2スイッチに接続しているように、同一サブネットとして振舞えるということである。では、それは内部でどのような処理が行われているのだろう？それを以下で見ていこう！

▼大まかな流れ

【東京本社】
  [ 自社L2スイッチ ]
       │ (LANケーブル)
  [ ONU (回線終端装置) ]
       │
       │ ① アクセス回線（NTTが敷いた電柱の光ファイバー）
       ▼
┌──────────────────────────────────────────────┐
│  NTT東京局舎（近くの電話局）                 │
└──────────────────────────────────────────────┘
       │
       │ ② POI（NTTとソフトバンクの建物を結ぶ光ケーブル）
       ▼
┌──────────────────────────────────────────────┐
│  ソフトバンク・コアネットワーク              │
│  （全国を結ぶ巨大な仮想L2スイッチ）          │
└──────────────────────────────────────────────┘
       │
       │ ③ POI
       ▼
┌──────────────────────────────────────────────┐
│  NTT大阪局舎（大阪の電話局）                 │
└──────────────────────────────────────────────┘
       │
       │ ④ アクセス回線（NTTの光ファイバー）
       ▼
  [ ONU ] ─── [ 自社L2スイッチ ]
【大阪支店】

p.4 ルータBは、OSPFv2でデフォルトルートを配布している
これの意味は、字義通りデフォルトルートの配布である。では、なぜわざわざ明示的にしているかというと、通常のルート広告とは種類が違うからである。
OSPFにおいて経路の有効化はインタフェース単位で行う。しかしデフォルトルートはインタフェースに紐づくものではないため特別なコマンドを明示的にする必要がある。そのような背景から本文のような「ルータBは、OSPFv2でデフォルトルートを配布している」という文章になる。

#OSPFにおけるデフォルトルートの配布方法
router ospf 1
 default-information originate

また、上記コマンドはデフォルトルートを保持しているルータのみの設定でよい。配下のルータは上記コマンドを設定しなくても自動で配下へと反映する

p.4 IPv4とIPv6のデュアルスタック
IPv4とIPv6のデュアルスタックとは一つの機器がIPv6とIPv4の両方に対応できるような構成のこと。具体的には、一つの機器にIPv4とIPv6のIPアドレスを割り当てたりすることが該当する。これによって、２つのプロトコルに対応できるようになる。

p.6 SLAAC
SLAACはStatelessAddressAutoconfigurationの略。DHCPサーバを使わずにルータと端末とのやり取りだけで、動的にIPv6アドレスを作り出す仕組みのこと。

p.8 SなんでIPv6の名前解決になるとIPv4よりも大きなサイズになるの？
基本的なDNS構成はIPv4だろうとIPv6だろうと変わらないではなぜこのようなことが起きるのか。。。では、見ていこう！

原因１：アドレス長の違い
　IPv4は32bitでIPv6は128bitで構成されている。そのため、レコードに記録する根本的なデータ量が変わってくるのは必然と言える。
原因２：逆引き
　逆引きをする際に、IPv4であれば約20バイト程度で済んだが、IPv6の場合は約75バイトなので、そういった面でもデータサイズが大きくなることがある。

Q.逆引きとは
逆引きとは、IPアドレスからドメインを解決することである。では、逆引きが使われるケースを見ていこう！

▼逆引きが使われるケース
１．迷惑メール対策
①example.comからメールが届く
②送信元アドレスから逆引きをする
③逆引きで得られたドメインと送信元のドメインが一致することを確認する
④一致していたら→正当の可能性あり　不一致なら→偽装
２．ログ解析
ログとしてIPアドレスだけを残すとどこからのアクセスか判断できない。そのため、逆引きをしてドメイン名を明らかにした上でログに残すという手法もある。
このような使われ方があります。

▼逆引きの流れ
192.0.2.1を逆引きする例を一緒に見ていこう！
１．逆引き用の文字列を作る
①アドレスを逆さにする（192.0.2.1→1.2.0.192）
②逆引き専用のドメインをつける
IPv4の場合→.in-addr.arpaなので1.2.0.192.in-addr.arpa.
IPv6の場合→.ip6.arpa.
２．ルートドメインへ問い合わせ
１クライアント→ルートドメイン
「1.2.0.192.in-addr.arpa.のPTRレコードくださーい」
２．ルート→クライアント
「そのPTRレコードは知らないけど、.in-addr.arpaの管理ならIANAが持ってるよ」
返されるデータ：
　IANAサーバのNSレコード＋そのサーバのA/AAAAレコード
＊IANA：IPアドレスを配布する世界で１番上に存在する元締め。この下にJPNICやらの地域ごとのアドレス割り当て機関がある
３．IANAへ問い合わせ
１クライアント→ルートドメイン
「1.2.0.192.in-addr.arpa.のPTRレコードくださーい」
２．ルート→クライアント
「そのPTRレコードは知らないけど、192.in-addr.arpaの管理ならアジアのAPNIC/JPNICのDNSサーバが持ってるよ」
返されるデータ：
　APNIC/JPNICサーバのNSレコード＋そのサーバのA/AAAAレコード
４．JPNICへ問い合わせ
１クライアント→ルートドメイン
「1.2.0.192.in-addr.arpa.のPTRレコードくださーい」
２．ルート→クライアント
「そのPTRレコードは知らないけど、0.192.in-addr.arpaの管理なら○○プロバイダのDNSサーバが持ってるよ」
返されるデータ：
　○○プロバイダのNSレコード＋そのサーバのA/AAAAレコード
５．プロバイダ
１クライアント→ルートドメイン
「1.2.0.192.in-addr.arpa.のPTRレコードくださーい」
２．ルート→クライアント
「あ、そのIPはうちのお客さんのIPだねPTRレコードはmail.example.comだよ」
返されるデータ：
　PTRレコード
これが主なPTRレコードの流れである。

Happy Eyeballsとは
本文には一切出てきていないが、IPv6とIPv4のDNSに関するレコードの選択アルゴリズムの用語としてHappyEyballsは有名なので覚えておこう。
HappyEyeballsとは「AレコードとAAAAレコードのどっちを使うかの切り替え機能」である。基本的にDNSではIPv6が優先される。しかし、IPv6と接続できない場合はIPv4に切り替えたほうが効率がよい。そのため、その切り替え機能がHappyEyeballsというわけである。

p.8 SIPv6アドレスをキャッシュDNSサーバに割り当てなくてもいい理由

本文にも書いてある通り、IPv4ネットワークを使ってキャッシュDNSサーバにアクセスしたうえで、AレコードやAAAAレコードを取得すればよいだけなのでわざわざアドレスを割り当てる必要はない。要は、問い合わせに使うネットワークの種類と応答レコードの種類は独立なのでIPv6アドレスを割り当てる必要はないよということ。
＊しかし、これはあくまでも現状のデュアルスタックを前提にした話。もし、IPv6への完全移行をするならば、IPv6アドレスの割り当ては必須。

Q.MAP-EとDS-Liteとは
MAP-EとDS-LiteはIPv4の弱点をカバーしてIPv6でISPまで届けようとする仕組み。
IPv4はPPPoEによる仕様によってNTEと呼ばれる終端装置を通らなければならない。しかし、そこがボトルネックとなりIPv4の速度を落としている。
IPv6であればIPoEという技術が使えるため、NTEを通らない代わりに新たな大きなゲートウェイを通すため混雑を抑えられる。
そのような背景から、IPv4をIPv6で包んで回線を流せば混雑抑えられるじゃん！ということでMAP-EとDS-Liteという技術がある。

▼MAP-Eの流れ

【自宅 PC】
  │ (1) 普通のIPv4通信（例: ポート80宛て）
  ▼
【宅内ルーター（MAP-E対応）】★ここで大仕事！
  │ (2) 自分に割り当てられた「IPv4アドレス」と「指定ポート番号」へNAT変換
  │ (3) それをIPv6の封筒で包む（カプセル化）
  ▼
【NTT NGN網（IPoEの大通り）】
  │ スイスイ通過（NTEを通らない！）
  ▼
【VNE（接続事業者）】
  │ (4) IPv6の封筒を破いて脱がすだけ（カプセル解除）
  ▼
【IPv4 インターネット】

▼DS-Liteの流れ

【自宅 PC】
  │ (1) 普通のプライベートIPv4通信（例: 192.168.1.10）
  ▼
【宅内ルーター（DS-Lite対応）】★超シンプル！
  │ (2) NAT変換はせず、そのままIPv6の封筒で包む（カプセル化）
  ▼
【NTT NGN網（IPoEの大通り）】
  │ スイスイ通過（PPPoEのNTEを通らない！）
  ▼
【AFTR（VNEの大型CGN設備）】★ここで全員分を大処理！
  │ (3) IPv6の封筒を破く（カプセル解除）
  │ (4) 大型NAT設備（CGN）で、公有のグローバルIPv4へアドレス＆ポート変換！
  ▼
【IPv4 インターネット】

interface:ip access-group
interface(ipv6):ipv6 traffic-filter _name [in/out]
class-map:access-group
vty:access-class
route-map:ip address

経路集約————————–

EIGRPのコスト計算方法————————–

EIGRPのメトリック = 256 ×（ 帯域幅 + 遅延 ）
帯域幅 = 10,000,000 ÷ 経路上の最小帯域幅（Kbps）
遅延 = 経路上の遅延合計（μ秒） ÷ 10

１．目的地までの中で最小帯域幅をピックアップする
２．１の帯域幅をkbpsに変換する
３．10^7 ÷ “手順2で算出した数値” を計算する(単位はkbpsのまま)
４．目的地までの遅延の合計を算出する
５．4で算出した値 ÷ 10 を計算する
６．(3と5で算出した値を加算した値) × 256　を算出する
７．各径路の6の値を比較して適切な経路がテーブルに反映される

そのルートのAD ＜ サクセサーのFDならばフィージブルサクセサーだよねってこと。
variance 2とかをする場合は　
フィージブル条件を満たしている
＆(かつ)
フィージブルサクセサーのFD ≦ サクセサーのFD × variance　ならばルーティングに登録

サブネットマスクの計算

やり方は以下の3ステップです。「203.0.113.17 /28」を例にします。
（サブネット算出
→ 256-サブネット=きざみ幅
→IP÷きざみ幅＝ｘあまりｙ
→IP-あまり

1. マスクの末尾を256から引いて「きざみ幅」を出す
   • マスクは 255.255.255.240 です。
   • 256 – 240 = 16 （16個きざみだと分かります）
2. IPの末尾を「きざみ幅」で割って「余り」を出す
   • 今回のIPは .17 です。
   • 17 ÷ 16 = 1 あまり 1
3. 元のIPから「余り」を引く ➔ これがネットワークアドレス！
   • 17 – 1 = 16

ワイルドカードマスクの算出

ワイルドカードマスクを求めるときは、「調べたい範囲の終わりのIP」から「始まりのIP」を引き算すると、一発で答えが出ます。

今回のターゲットである「クラスBのプライベートIP」の範囲を並べて、引き算してみましょう。

• 終わりのIP： 172 . 31 . 255 . 255
• 始まりのIP： 172 . 16 . 0 . 0
• 引き算の答え： 0 . 15 . 255 . 255

第2オクテット（2番目の区切り）を見ると、「31 – 16 = 15」 になっていますよね。 これが、コマンドで 0.15.255.255 を使う一番簡単な理由です。

YANGとXMLとJSONとか

<interface>
  <name>GigabitEthernet0/0</name>
  <ip>192.168.1.1</ip>
</interface>

{
  "interface": {
    "name": "GigabitEthernet0/0",
    "ip": "192.168.1.1"
  }
}

Pythonのライブラリ

構成管理ツール

▼ゾーン転送の流れ
１．notifyやrefreshを契機に始動
notify:プライマリDNSに変更があった際に、プライマリDNSがセカンダリDNSに「俺、変更したよぉ」と通知するメッセージのこと
refresh:SOAレコード内から得られる情報で、「プライマリへの確認作業のインターバルはこの時間で！」と教えてくれる値。この時間が経過したらセカンダリはプライマリにSOAレコードの取得を試みる
２．SOAレコードの取得
１を契機にプライマリDNSにSOAレコードの取得依頼を送る。
＊この通信はUDP53が使われる。
３．シリアル番号の確認
①セカンダリDNSがSOAレコードを取得すると、レコード内のシリアル番号の値を確認する。
②既に持っているシリアル番号よりも大きい場合→ゾーン転送が必要
　既に持っているシリアル番号よりも小さい場合→ゾーン転送が不要

example.com.  IN  SOA  ns1.example.com.  hostmaster.example.com. (
                        2026071601 ; Serial (シリアル番号)
                        10800      ; Refresh (リフレッシュ間隔)
                        3600       ; Retry (リトライ間隔)
                        604800     ; Expire (有効期限)
                        86400      ; Minimum TTL (ネガティブキャッシュTTL)
                        )

４．ゾーン転送要求
　ゾーン転送が必要な場合は、「ゾーン情報をください！」とプライマリに依頼
５．ゾーン転送
　プライマリがゾーン情報をTCP53番を使いゾーン転送を実施する

（２）c:DNS1

Cのプロトコルを確認すると、DNSであることが分かる。で、送信元がDNS3なので、DNS３が実施するDNS通信はDNS1へのゾーン転送に関する通信のみ。そのためDNS1が該当する。

（３）公開ゾーン情報の更新通知
項番４はDNS1→DNS3へのDNSプロトコル通信であることが分かる。なお、本文(p.11 下から8行目)にもある通りnotifyメッセージを送信していることが分かる。つまり、セカンダリへのDNS情報更新通知であることが分かる。

（４）条件：送信元が少数の場合　　　理由：送信元は、DNSのキャッシュが生存している間、宛先を変えないから
想像してみよう。今回のケースは、本文中より外部からのメール転送はMGW2のみが担当する。つまり、送信元は１つ。そして、宛先をDNSによって名前解決するとそれがキャッシュとして保存される。つまり、MGW2は１つのMSVを使い続けることになる。ほかのMSVはずっと、手が空いている状況だが、キャッシュの時間内は使われることがない。
逆に、送信元が１００台あると、DNS名前解決した結果、すべてのMSV使われるようになる。
以上のことから、送信元が１つだとそもそも１つのMSVしか使われないので負荷分散ができない。そして、その根本的な理由はメール受信ごとに名前解決をするのではなく、キャッシュ機能によって保持されるため１度名前解決をすると、それ以降は使われるMSVが変わることがないから。
逆を言えば、キャッシュがなければ送信元が１つでも、毎回毎回、名前解決するのでラウンドロビン方式でも分散が可能になる。
しかし、処理速度や負荷などを考えると圧倒的にキャッシュを使った方がメリットが大きい。

設問２
（１）d:新MSV1　e:新MSV２
p.13の(3)にもある通り、”新MSV１の故障時にはVRRPによって転送先が切り替わる”とあるので、新MSV１では確実にVRRPが稼働していると推測できる。また、そこからその新MSV１と対をなす存在はMSV2なので、MSV2もVRRPが稼働していることが分かる。
その状況から判断して、dとeにはそれぞれ新MSV1と新MSV２が入る。

設問３
（２）送信元：メール送受信サーバの変更を実施済みの社員　または　社外
　　　宛先：未変更社員
この問題は、新MSVへ届いたメールに対してLDAPを検索しなくてはならない条件を聞いている。通常、新MSVはメールボックスが共有なのでLDAPを使う必要がない。しかし、特定の条件では使う必要が出てくる。それが古いシステムを使っているパターンだ。
もし、未変更社員同士のメールであれば、そもそも新MSVを経由しないのでこの問題の対象外となる。未変更ということは、その社員のメールクライアントには古いホスト名が記されている。それを名前解決すると自ずと旧MSVへルーティングされるので新MSVは経由しない。
これらのことから、送信元が社外または、新MSVのホスト名に変更済みの社員であるパターン。かつ、宛先はメールボックスが移行されていない社員（＝未変更社員）ということになる。

（４）申請者のメールアドレスに対応するメールサーバが、新MSVに変更される
旧メールシステムではメールボックスがMSVごとに分けられていた。適切なメールボックスに格納するためにLDAPを使い適切なMSVに転送していた。そのため、新メールシステムに移行したら、自ずとその設定を新MSVに変更する必要がある。そうしないと、古いメールボックス宛てにメールが格納されつづけてしまうから。

p.11　LDAPサーバ
一言でいうとLDAPサーバとはディレクトリサーバの意。ディレクトリサーバとは組織内のアカウントやデバイスを一元管理するためのサーバ。そしてLDAPはディレクトリサービスにアクセスするための共通ルールのこと。なので、一見するとLDAPサーバと聞くと、ユーザの代わりにLDAP機能を使ってディレクトリサーバにLDAPを使ってアクセスしてくれるサーバなのかなぁとイメージしてしまうけど、IT業界のなかで、LDAPサーバと言ったら十中八九、ディレクトリサーバを指している。

p.11　MGWの転送先をMSV1で固定しているのはなぜ？MSVは3台あるんだから、３台に分散すべきじゃないの？

A.メール転送には重い処理と軽い処理がある。
軽い処理：
　届いたメールを右から左へ転送するだけ。
重い処理：
　届いたメールをメールボックスすに配置したり、クライアントからの要求によってメールをダウンロードしたりする作業はとても重い。なぜならこれらはハードディスクへアクセス（ディスクI/O）が発生するから。
このようにMSV1に固定されても、MSV1が実施する処理は他のMSVへの転送処理であるため軽い処理で終わる。もちろんMSV1自身に届いたメールは重い処理をするが、それ以外に関しては転送処理が主なので、MSV1の固定でも問題はない。

p.11　MGW2はどうやって転送処理をするの？
A.イメージしてみよう。D社社員へのメールは外部DNS3で名前解決されてMGW2に届く。その後、MGW2はどう処理するの？メールアドレスのドメインで名前解決してもMGW2自身のIPしかわからずループしちゃうんじゃないの？このような疑問が浮かぶだろう。しかし、実際はループせずしっかりと送信できる構成ができている。では、流れを見ていこう！
▼MGW2が内部MSVへ転送するまでの流れ
１．MGW2に外部メールが届く
２．MGW２内のルールを参照
ルール①：外部からＤ社宛てへのメールがきたら、特定のホストへ転送するルールを決めておく。
ルール②：①のホストを名前解決するときにDNSサーバのIPアドレスを登録しておく
ルール③：名前解決をして、適切なホスト（MSV）へ転送する
３．MSVへ届く

p.11　障害が起きたらMGWをどうやって切り替えるの？

A.優先度を使うことによって動的な切り替えが可能になる。
外部からの名前解決の名前解決では２つのレコードを返すようにする。その際に、MGW２をMGW1よりも優先度を高く設定する。これによって、通常時はMGW2が使われるが、障害が起きた際はMGW2に通信できないので、送信側は優先度の低いMGW1を試す。要は送信側のリトライによって動的な切り替えが可能になっているということである。
＊ちなみにMXレコードにおける優先度は、値が小さければ小さいほど優先される。

p.13　メールサーバでVRRPは動作できるの？
p.13では新MSV1と２でVRRPを稼働させる旨の記述がある。ここで疑問が一つ。VRRPってルータなどのファーストホップの冗長化の技術じゃないの？メールサーバでも動かせえるの？答えは、実はメールサーバでも稼働できるんです！Linuxサーバーなどでは 「Keepalived」 という超有名なオープンソースのソフト（デーモン）があり、これを使うことでサーバー自体にVRRPを喋らせる（仮想IPを共有させる）ことが実務でも超一般的に行われている。
では、具体的な流れを見ていこう！

▼メールサーバで実施するVRRPのフロー
１．準備
①新MSV１と２でVRRP設定をする
　各MSVは２つのグループに所属し、それぞれに適切なプライオリティを割り当てる
②DNS設定
　DNS2にメールサーバのホスト名に対応するAレコードを２つ登録する
　＊この際に登録するＩＰアドレスは仮想ＩＰアドレス
２．データ転送
①クライアントのメールソフトにメールサーバのホスト名を登録しておく
②①の名前解決をDNS2に要求する
③仮想ＩＰアドレスが返される。
④ＤＮＳには２つのレコードがあるため、ユーザごとに順番に５０％の確率で別々の仮想ＩＰアドレスのＡレコードが返される。結果的に負荷分散ができる。
３．障害発生時
①マスタのキープアライブが途切れる
②タイムアウトの時間だけ待ったうえで、スタンバイ側が仮想IP/MACを引き継ぐ
③GARPを送信し、配下のスイッチのMACアドレステーブルを更新させる
④当該仮想IP宛ての通信は適切に適切にルーティングされる
４．障害回復
①プリエンプト機能が有効な場合、プライオリティが最も高い機器がマスタに戻る

▼CONNECTメソッドによるHTTPS通信の流れ
１．ブラウザ（クライアント）→プロキシへ
①ブラウザはアクセスしたいサイトのURLを確認する
②もしURLがhttps://google.comのようにHTTPSと書かれていれば「HTTPS通信だ！」と認識する
③プロキシ設定を確認して、「直接ではなくプロキシを通さないとだめなのか」と認識する
④「よし、じゃあプロキシに接続しよう」と内部で以下の設定が発行される

▼CONNECTメソッド
CONNECT google.com:443 HTTP/1.1
Host: google.com:443

２．プロキシ→サーバ
①プロキシはCONNECTメソッドに指定されたドメインを名前解決する
② ①で得たIPアドレスなどをもとに当該サーバとTCPコネクションを張る
③TCPのマッピングテーブルを作成する。

上のようなテーブルを作成することで、ユーザとサーバ間のアプリケーション層が暗号化されて宛先の判断に迷っても、適切にバイパス機能を提供できるようになる。
３．プロキシ→ブラウザ（クライアント）
プロキシからブラウザへ「200 Connection Established」というTCPセッション作成できた旨の報告を入れる。
＊このフェーズを参考書などでは、「トンネルの準備ができた」と表現されることがある。これだと、この時点で暗号化通信がプロキシとサーバ間で成立したニュアンスを感じるが実施はただTCPセッションができただけ。
４．ブラウザ⇔サーバ
ブラウザとサーバ間でTLSハンドシェイクを実施する。
TLSハンドシェイクが完了すると暗号化通信が実施される
👇TLSハンドシェイクのわかりやすい流れについては以下👇を見てみよう！

TLSハンドシェイク早見表

✅ TLS 1.2 における RSA方式の鍵交換の流れ▼ 1. クライアント Helloクライアントはまず、サーバに「ClientHello」メッセージを送る。ここには以下が含まれる：サポートするTLSのバー...

ascend-beyond.com

2025.07.22

Q.一般的なHTTPのメソッドはどうなってるの？
A.CONNECTメソッドだけだと、全体を把握しにくいので、GETメソッドをみて、どういう風なのかをサラッと確認しよう！

▼CONNECTメソッド
CONNECT google.com:443 HTTP/1.1
Host: google.com:443

▼GETメソッド（プロキシあり）
＊プロキシ経由の場合は絶対パスの指定が必須
GET http://example.com/index.html HTTP/1.1
Host: example.com

▼GETメソッド（プロキシなし）
＊プロキシを経由しない場合はファイルのパスだけでよい
GET /index.html HTTP/1.1
Host: example.com

設問２
（１）定期的に送信するビーコン信号を停止する。
結論から言うと、これは修正が必要な回答。正しくは「ビーコン信号にSSIDを含めない」となる。もし、ビーコン信号自体を止めてしまうと、そもそものクライアント接続がとても非効率なものになる。では、御託を並べても仕方がないので実際のフローを見ていこう！
▼ステルスモードにおける端末がAPに接続するフロー
１．APのビーコン信号
　APはSSIDを載せずにビーコン信号を出す。
　これにより、ユーザは「SSIDはわからないけど、このチャネルにこのような性能をもつAPがいるんだ！」と認識する
２．プローブ要求
　クライアントは１で受け取ったSSIDが分からないAPに対して、自身が接続したいSSID名を付与して接続要求を送る。
３．接続
　クライアントが指定したSSIDとAPのSSIDが一致すれば接続ができる。
以上。ここからわかるように、もし、APがビーコン信号すら発っさなければどのチャネルにAPがいるかという情報自体を得ることができなくなる。そうなると、クライアントは、各チャネル１つ１つに対してプローブ要求を送らなければならず、無駄なリソースを消費してしまう。そのため、APはたとえステルスモードであっても、ビーコン信号は発っし続けなければならない。

（２）SSIDやMACアドレスは暗号化できず、傍受されるから
回答の通り、WPAやWPA2などを使ってもSSIDやMACアドレスまでは暗号化できない。それに、無線の場合は電波が届く範囲内にいれば誰でも傍受ができるので、有線よりも簡単にMACアドレスやSSIDが取得できてしまう。

Q.MACアドレスやSSIDが漏れたらどんなリスクがあるの？
A.情報が洩れるとなりすましのリスクが格段に上がる。APのなりすましである「Evil Twin攻撃」やクライアントのなりすましなどが発生する。詳細をいかに記そう。
・Evil Twin攻撃：
　攻撃者が正規のSSIDを取得し、不正APを立てる。そのアクセスポイントに正規のAPと同じSSIDをつけることによって、クライアントが偽APに接続して中間者攻撃などをされてしまう。
・なりすまし：
　MACアドレスが漏洩すると、攻撃者が正規のMACアドレスと偽って接続できてしまう。そのためMACアドレスフィルタリングをしていても、MACアドレスは正常なので攻撃者からの接続を許してしまう。

Q.MACアドレスやSSIDの漏洩を防ぐ方法はあるの？
A.防ぐ方法はない。なぜなら、MACアドレスやSSIDを暗号化してしまうと、そもそもの接続自体が正規ユーザであっても不可能になってしまうから。

Q.どうやって対策するの？
A.WPAやWPA2などの暗号化機能や、証明書を利用して正当性を保証する。正直、SSIDやMACアドレスを隠ぺいすることは難しい。なので、そこにフォーカスするのではなく、正当なユーザしか知らない別の情報をあらかじめ用意しておき、その情報をつかって認証することでなりすましを防ごう！という考えにシフトさせる。そうすることで、たとえSSIDやMACアドレスが知られたとしても、それら以外の別の情報が洩れなければ正当性を保証できるようになる。

（３）E
タブレット端末はVPNを通してE社のLANと同一サブネットのようなふるまいをする。つまり、区間（E）と同一サブネットになるわけだから、もちろん重複もNGということになる。

では、ここからは上の構成図の詳細を見ていこう！プライベートIPアドレスの割り当てであったり、LTE回線があったり、VPNサーバへのアクセス、など様々なものがこの構成図に集約されている。それらの流れを整理しつつ紐解いていこう！

▼LTEとVPNのセッション確立の流れ
１．モバイルWi-Fiルータ（以後、MRとする）を起動
２．基地局→MME→ゲートウェイへ
　MRが起動すると、自身のSIMカード情報を載せてLTE回線を経由して基地局へ運ぶ。その後、基地局は認証機関であるMMEに情報を渡す。MMEが内容を確認してAPNから適切なゲートウェイを見つけ、コアネットワークを経由して運ぶ。
３．通信路の確立（MRのインターネットアクセスの準備が整う）
　MMEからのパケットが届くと、それらの情報をもとに基地局とゲートウェイ間にGTPトンネルを確立する。また、基地局とMR間には無線ベアラと呼ばれる方式で通信する。
＊この時に、ゲートウェイは適切なプライベートIPアドレスをMRに割り当てる。
４．タブレット端末からVPNサーバへ
①タブレット内のVPNアプリを起動する。宛先IPはVPNサーバ宛てになる。
②それがMRに届き、LTEから割り当てられたプライベートIPにNAT変換されてLTEゲートウェイまで届く。
③LTEゲートウェイがNAPT変換して、宛先IPまでパケット転送する。
５．VPNの作成
本文のp.9を見るとL2TP over IPsec方式を採用しているので、まずはIPsecの手順から進める。
６．IPsecVPNの確立
①ISKMP SAの確立
1.クライアント→サーバ
　「僕はこのような暗号化方法、認証方法をサポートしているよぉ」と報告
2.サーバ→クライアント
　「じゃあ、この方法で進めよう」と応答する
3.DiffieHellmanで共通鍵の生成
　この共通鍵をSKEYIDと呼ぶ
4.認証
　証明書を、2で決定した暗号化/認証方法に則り、3で作成されたSKEYIDを使って暗号化する。暗号化対象は、認証情報と今までのやり取りの要約情報が対象。
②IPsec SAの確立
1.クライアント→サーバ
　「僕はこのような暗号化方法、認証方法をサポートしているよぉ」と報告
2.サーバ→クライアント
　「じゃあ、この方法で進めよう」と応答する
3.鍵生成
　PFS（前方秘匿性）がONの場合：DiffieHellmanで共通鍵生成
　PFSがOFFの場合：SKEYIDとノンスを使って鍵生成
４データ通信開始
　2で決定した暗号化/認証方法に則り、3で作成された鍵を使って暗号化する。
７．L2TPのトンネルの確立
①.お互いのメモリ上にトンネルマッピングを作る
　クライアントが「俺は10番のトンネルIDでいきます！」と宣言し、サーバ側は「よし、じゃあ僕は20番のトンネルIDを使うよ」と宣言する。
　これにより、お互いのメモリ上に、トンネルIDの10番と20番をマッピングさせる。これにより論理的なトンネルを作成する。
②.セッションIDの交換
　クライアントが「俺はセッションIDを100番にします」と宣言し、サーバ側は「よし、じゃあ僕はセッションIDを200番でいくよ」と宣言する。
　これにより、トンネルの中に通信レーンが確立される。
③.仮想的な箱（Virtual-Access インターフェース）の準備
　セッションごとに適切な処理をするために仮想的な箱（Virtual-Access インターフェース）を準備する。vritual-accessとかっこつけた名前だが、要は「vlanインタフェースのような静的に作られる仮想インタフェースではなく、動的に生成される仮想インタフェースのこと」。これによって、ユーザごとに仮想インタフェースを割り当てられるので、ユーザごとにACLを割り当てたりすることができる。
８．PPPセッションの確立
　PPPのステップは「準備→認証→IPアドレス割り当て」の３つのステップからなる。
①LCP（Link Control Protocol）確立
　「認証どうする？圧縮方式どうする？」というような通信のルールを決めるフェーズの実施。
②認証
　PAPやCHAPといった仕組みをつかってID/Passwordが正しいことを確認する
③IPCP（IP Control Protocol）
　IPアドレスの割り当てを行う。その当該IPアドレスはL2TPで作成されたVirtual-Accessインタフェースに付与される。また、クライアントにも当該IPは渡される
このIPCPが終わるとやっと、通信ができるようになる。ここまでが大まかな通信開始までの流れ。では、この後行われる実際のデータ転送プロセスを見ていこう！

▼LTEとVPNのデータ通信の流れ
１．タブレット→モバイルWi-Fiルータへ
　まずは、タブレット内でデータを生成し、L2TPとIPsecのヘッダをつける。
内側IP構成：[送信元：PPPで割り当てられたIPアドレス / 宛先：社内のLAN宛て]
外側IP構成：[送信元：MRから割り当てられたIPアドレス / 宛先：VPNサーバ宛て]
２．MR→LTEゲートウェイ
外側IP構成：[送信元：MRがLTEから割り当てられたIPアドレスに変換/ 宛先：VPNサーバ宛て]
３．LTEゲートウェイ→VPNサーバ
外側IP構成：[送信元：LTEがNAPT変換/ 宛先：VPNサーバ宛て]
NAPT変換によってグローバルIPアドレスに変換され、インターネットを跨ぐことができる。そして、VPNサーバに到達する。
４．VPNサーバ→Virtual Access
①外側パケットを解除する
②L2TPヘッダがでてくる
　L2TPヘッダからTunnel ID、セッションIDを確認して、内部のマッピング情報から適切なVirtula Accessへ振り分ける。
　この際にL2TPヘッダは剥がされる。
③Virtual Access
　Virutal Accessへ行くと、PPPヘッダがあるので、それを剥がして内部へパケットを流す
５．内部LAN
　無事、内部LANに届いたら処理をして、今までの逆の処理をしてユーザまで返す。

▼IPsecについてはこちらでも解説している

平成28年（2016年）ネスペ午後Ⅱ　問二　解答解説

設問１（１）イ：セレクタセキュリティポリシを選択するキーはセレクタと呼ばれる。Q.SPIとセレクタって何が違うの？A.SPIはどのSAを使うかの32ビットの識別子。つまりSADの中から適切なSAを見つけるための識別子。一方、セレクタはどの...

ascend-beyond.com

2026.07.06

設問３
（１）VPN接続の利用者IDを停止する
本文より、現状の認証は利用者IDとワンタイムパスワードであることが推測できる。また、利用者IDは基本的に推測が容易なIDとなっている。例えば、社員番号やメールアドレスなど。これらは端末が盗まれてPCにログオンできれば簡単に割り出されてしまう。また、VPNの多くはIDを保存するという機能があるので、IDを盗む必要すらないというパターンも多い。そのため、「不正アクセスがありました！」と検知されるよりも前に、何かを紛失してしまった場合は速やかに利用停止をする必要がある。

（２）プロキシサーバと内部DNSサーバへの通信
p.7のポツ５つ目より、プロキシサーバを使う旨の記述があるので、まずはプロキシサーバの通信を許可する必要がある。また、VPN接続が完了した後に、実際にプロキシサーバを使うためにはプロキシサーバの名前解決をする必要がある。そのため内部DNSへの通信も許可する必要がある。

Q.どこで通信の可否を判断しているの？

現状の構成は上記のようになっている。で、結論から言うと、FWで接続可否を判断している。具体的な流れを以下に記す。
１．タブレット→VPN
まずは、VPN接続完了している端末からアクセスが届く。
２．VPN→SW1→FW
VPNサーバは外部からの通信なので、FWに通す。そのため、SW1を経由してFWに届ける。
３．FW
通信ルールから内部DNS or プロキシサーバ宛て以外の通信はブロックする。もし、それら２つならSW2に流す。

設問４
（１）機能名：プロキシ認証　設定内容：営業員ごとに利用者IDを登録する
プロキシ認証：
プロキシを使う際に認証を実施させる機能。具体的には、ユーザからの情報をもとに認証基盤（ActiveDirectoryなど）に正当性を確認し、OKなら許可しNGなら拒否する。プロキシサーバ自体がIDとパスワードを管理するというのは小規模なら可能だが、大規模の場合は認証基盤を使うのが一般的。

Q.プロキシ認証において、普段の会社のPCとかで毎回認証のポップアップが出ないのはなぜ？
A.統合Windows認証（IWA:Integrated Windows Authentication）を使う。これによりPCにログインした時点でSSOを利用できるようになるため、プロキシを利用するたびにポップアップが表示されなくて済む。
なお、統合Windows認証の根幹となる技術はケルベロスによって支えられている。

Q.ケルベロス認証とは
A.一度のログインで色んなサービスを使えるようにする技術（SSO）のこと。では、フローを見ながら理解していこう！
１．PC→AS（AuthenticationServer）
PCはASへ「ログインしたいです！」と伝える。
２．AS（AuthenticationServer）
ASはKDC（KeyDistributtionCenter）内にある窓口の一つで、認証を担当する。
暗号化データ（TGT（Ticket Granting Ticket）と共通鍵（＝Client-TGSセッション鍵）をクライアントに返す。その際に使われる暗号化鍵はクライアントのパスワードから作られた鍵。
３．AS→PC
PCは暗号化データを自身のパスワードをベースにした鍵で復号する。これによりTGTと共通鍵（＝Client-TGSセッション鍵）を手に入れる。
４．PC→TGS（Ticket Granting Service）
PCは「このサービス（例えばファイルサーバなど）を使いたいのでチケットをください！」とTGSへ伝える。
　TGTとオーセンティケーター（タイムスタンプ入りの証明書）をTGSに渡す。また、その際に公開領域（リクエスト内の暗号化されていない部分）にアクセスしたいサービスを指定する。
＊オーセンティケーターはASからもらった共通鍵で暗号化した状態で送付する。
５．TGS（Ticket Granting Service）→PC
①公開領域を確認する
　公開領域内にアクセスしたい場所が記されているので、それを確認する
②TGTをKDCだけがもつ鍵で復号する。
　その中にユーザとの共通鍵（＝Client-TGSセッション鍵）とユーザIDが入っている。それによって、「あ、このユーザIDは認証済みなんだ！」と認識できる。
③オーセンティケーターをClient-TGSセッション鍵で復号する。
　その中にあるユーザIDやタイムスタンプを確認してTGTとの整合性を確認する
③ST（ServiceTicket）と共通鍵（＝Client-Serverセッション鍵）を配布する
Client-Serverセッション鍵はClient-TGSセッション鍵で暗号化されて渡す。
STはKDCとサービスサーバとの共通鍵（ServiceKey）で暗号化されている
６．TGS→PC
①PCは共通鍵を取り出す
共通鍵（Client-Serverセッション鍵）はClient-TGSセッション鍵で暗号化されているので、自身のClient-TGSセッション鍵で復号する
PCはサービスサーバーに対して、オーセンティケーターとSTを渡す
７．PC→サービスサーバ
①サービスサーバは、STを復号し中にあるユーザIDや共通鍵（Client-Serverセッション鍵）を取り出す。
＊STを復号するときはServiceKeyを使う
②オーセンティケーターをClient-Serverセッション鍵で復号し、STとの整合性を確認する
以上の手順が滞りなく実施されるとユーザのアクセスが許可されサービスの利用が開始される
８．2回目以降のアクセス
手順３にてPCには既にClient-TGSセッションキーがあるので、それを使ってオーセンティケーターを作成する。
移行の流れは同じ。
＊Client-TGSセッションキーの有効期限が切れると再度、ASに認証を要求する必要がある。

（２）①接続先ホスト名　②接続先ポート番号
Request-URIを簡単にいうと、HTTPリクエストの１行目のこと。
例：CONNECTメソッドなら「CONNECT google.com:443 HTTP/1.1」が該当し、GETメソッドなら「GET /index.html HTTP/1.1」が該当する。要はどこにアクセスしたいかを表現する場所のことである。
で、ここからわかる情報は、「メソッド、宛先ホスト、ポート番号、HTTPプロトコル」である。なので、回答は接続先ホスト名と接続先ポート番号という風になる。

▼CONNECTメソッド
CONNECT google.com:443 HTTP/1.1
Host: google.com:443

▼GETメソッド（プロキシあり）
＊プロキシ経由の場合は絶対パスの指定が必須
GET http://example.com/index.html HTTP/1.1
Host: example.com

▼GETメソッド（プロキシなし）
＊プロキシを経由しない場合はファイルのパスだけでよい
GET /index.html HTTP/1.1
Host: example.com

p.7　内部DNSサーバの必要性
　以下の構成において、内部DNSサーバはなぜ必要か。それを見ていこう！

答えはシンプルで、VPN接続後のタブレット端末が販売管理サーバと通信したい際に使われる。URLはわかっても実際のIPアドレスが分からないと通信できないので、それを解消するために内部DNSサーバを利用する。

p.7 LTE回線
LTE（LongTermEvolution）は3GPP（Third Generation Partnership Project）という世界中の通信会社やメーカーが集まる組織が作った、数万ページに及ぶ「規格（ルールブック）」のこと。そして、その規格に則った回線をLTE回線と呼ぶ。以下に特徴をまとめる。
・SIMカードを使った認証：
　多くの場合、LTE回線では認証を必要とする。なぜなら誰彼構わず通信を提供していたらビジネスにならない。また、移動通信（ハンドオーバー）やトラフィック制御、課金管理などを提供するには利用者を識別する必要があるため認証を実施する。
・オールIPによる通信：
　音声通話もデータ通信もすべてIPで通信する。一昔前は音声通話は電話用の回路へ送出され、データ通信はデータ通信用の回路へ送出されていた。このように用途によって回路が分かれていたが、LTEはすべてIPで包んで通信させる方式を採用した。
・APN（Access Point Name）による接続先の選択：
　SIMカードの契約情報に基づき、インターネット網や特定の企業向け閉域網など、適切なネットワーク（ゲートウェイ）へ通信を振り分ける。
もし、これがないとモバイルのコアネットワークから外のほかのネットワーク（インターネット、会社VPNなど）へ通信できなくなる。
このような特徴をLTEは持つ。

Q.LTE回線におけるインターネットアクセスのフローは？
A.LTE回線が具体的にどのようなものかイメージするためにはフロー理解が役立つ。なので、見ていこう！
１．端末：
　送信データに宛先IPを付与
２．無線アクセス：
　LTE/5Gの電波に乗せて、基地局（base station）へ運ぶ
３．コアネットワーク：
　基地局経由でコアネットワークに到着
４．ゲートウェイ（APN）：
　端末のAPN設定に基づき、適切なゲートウェイへ振り分け。ここで、NAPT変換やGTPトンネル（モバイル回線）の終端の役割を担う。
　＊APNはどのゲートウェイを使うかを示す名前（識別子）
５．NAPT変換：
　ゲートウェイで端末のプライベートIPアドレスをキャリアのグローバルIPアドレスに変換
　＊ここで言うプライベートIPアドレスは、端末が「LTEで通信したい！」とキャリアに伝えてからキャリアのゲートウェイが端末に割り振るIPアドレスのことを指す。
６．インターネット接続：
　NAPT変換されたパケットはキャリア網のバックボーンネットワークを経由して、インターネット（AS）との境界ルータへ渡される。で、ここから先はBGPを使い複数のASを経由して宛先までホップする

Q.GTP（GPRS Tunneling Protocol）トンネルの作成フロー
では、GTPトンネルの作成フローを見ていこう！
１．クライアントが接続要求
　SIM情報を載せて基地局へ投げる。
＊この時点ではまだ、IPアドレスの払い出しやGTPトンネルは張られていない
２．基地局へ届く
　基地局へ届くと管理装置であるMMEに処理を投げる
３．MME（Mobility Management Entity）
　MMEと呼ばれる管理装置は、SIM情報のAPNなどからゲートウェイを特定し、当該ゲートウェイに「ユーザにプライベートIPアドレスを払い出せ！基地局とGTPトンネルを張れ」と処理を投げる。
また、基地局に対しては、「ユーザと無線ベアラ開通させろ！」と処理を投げる。
４．ゲートウェイ
　GTPトンネルの開通：
　　・基地局からゲートウェイの間にGTPトンネルを開通させる。
　　・TEID（Tunnel Endpoint Identifier）という識別子をトンネルに付与することで「誰のパケット」かを明示する
　IPアドレスの払い出し：
　　・ユーザにプライベートIPアドレスの払い出しをする
５．ゲートウェイ→MMEへ
　GTPトンネルやIP払い出しの準備ができたらその情報をMMEに送る。
６．MME→基地局
　無線ベアラの接続指示を与える。
　５の情報を基地局に伝える。
７．基地局→ユーザ
　無線ベアラを確立する。
以上が大まかな流れだよ。ユーザ⇔基地局　と　基地局⇔ゲートウェイ　のように２つの接続種類を使うことでユーザが移動して基地局が変わったとしても基地局⇔ゲートウェイで使われているトンネル情報を移動先に張り替えるだけで維持できるので、ハンドオーバーをスムーズに実現できるようになる。

p.8 WEP,WPA,WPA2
WEP,WPA,WPA2は無線LANのセキュリティ規格。では、それぞれ順番にみていこう！

Q.WEP（WiredEquivalentPrivacy）:
WEPは、データと謎の鍵（キーストリーム）を合体させて暗号化する方法であるストリーム暗号方式を採用している。
＊キーストリームを作るための材料がWEPキー（パスワード、共有鍵）とIV

＃暗号化
データ XOR キーストリーム = 暗号文

＃復号化
暗号文 XOR キーストリーム = データ


#キーストリーム
キーストリーム = RC4（WEPキー,IV）

▼暗号化手順
１．WEPキー（パスワード）とIVをまぜる
＊IVはパケットごとに変化する
２．２で混ぜた値をRC4という暗号アルゴリズムに入れてデータと同じ長さのキーストリームを生成する
３．キーストリームとデータをXORして暗号文を生成
４．３でできたデータとIV（平文）をセットして空中に飛ばす

▼弱点
弱点１：IVが短すぎる
　WEPではIVが24ビットしかないので、2^24は1677万しかパターンがない。これは現在の高速Wi-Fi通信において、あっという間に重複してしまう数値。結果として同じキーストリーム（IV＋パスワード）を使いまわすことになり、XORの法則で解析されてしまう。
このような式（暗号文A XOR　暗号文B = データB XOR データA）になれば、もしデータBかAが推測できるならばもう一方のデータ必然的に導出されてしまう。

###########################
#
# もし、キーストリームが重複すると
#
##########################
XORのルール
①順番はどうでもいい
②同じ値同士のXORは０になる

１．重複した２つのデータを準備
暗号文A　= データA XOR キーストリーム
暗号文B　= データB XOR キーストリーム

２．ルール①より式を変換
キーストリーム = 暗号文A XOR　データA
キーストリーム = 暗号文B XOR　データB

３．等価関係
暗号文A XOR　データA = 暗号文B XOR　データB

４．ルール①より暗号文Bを左辺へ、データAを右辺へ移動させる
暗号文A XOR　暗号文B =  データB XOR データA

弱点２：RC4の脆弱性
RC4が使われるタイミングはキーストリームを生成するとき。キーストリーム = RC4（WEPキー,IV）。しかし、RC4には元のパスワードの統計的情報が生成したキーストリームの先頭付近に漏れ出てしまう特性がある。これを統計処理されると元のパスワードが導出されてしまう。

以上の理由からWEPの使用は現在では非推奨とされている。

Q.WPA（Wi-Fi Protected Access）：
WEPという脆弱性の塊を、ハードウェアの変更をすることなく補強し延命するための規格。

▼改善点
改善点１：IVの拡大
　WEPは24ビット（約1677万）だったがWPAでは48ビット（約281兆）に拡大された。これは重複して使われることがほぼない。

改善点２：パラメータの増加
　WEPはキーストリームのパラメータが「WEPキー＋IV」の２つだけだった。しかしWPAでは、「WEPキー＋IV＋送信元MACアドレス＋パケット番号」の４つのパラメータを使っている。
＊WPAにおけるWEPキーは４way handshakeによって生成されたTKである。

キーストリーム = RC4（WEPキー＋IV＋送信元MACアドレス＋パケット番号）

改善点３：４ウェイハンドシェイクの導入
使用するパラメータは
・Aノンス（APのノンス）
・Cノンス（クライアントのノンス）
・AMAC（APのMACアドレス）
・ＣMAC（クライアントのMACアドレス）
・PMK（事前共有鍵）

▼４way hand-shakeの流れ
１．①AP→クライアントにAノンスを送る
２．クライアントがPTKの生成
　クライアントは「PMK＋Aノンス＋Cノンス＋AMAC＋CMAC」を導出関数に入れてPTKを生成する。
＊導出関数はPRF (Pseudo-Random Function：擬似乱数関数) または KDF (Key Derivation Function：鍵導出関数)と呼ばれる。RC4やAESとは全く別で、「入力した情報をめちゃくちゃに混ぜて規則性のないランダムな値を生成する」ための数学的な仕組み
３．PTKから鍵を取り出す
PTKにはKCK、KEK、TKと呼ばれる鍵が内在されている。
KCK：MICを生成するための鍵
KEK：GTKを暗号化するための鍵
TK：通常のデータを暗号化するための鍵
４．②クライアント→APにCノンスとMICを送る
　クライアントは自身のノンスと先ほど生成したPTKのKCKから生成したMICを送る。
＊MIC（MessageIntegrityCheck）
５．APが正当性の確認
　APを受け取ったCノンスなどの情報を使いPTKを生成する。また、そのPTKのKCKからMICを生成し、そのMICがクライアントから送られてきたMICと一致したら正当性も保証される。
６．③AP→クライアントにGTKの配布
　GTKと呼ばれるグループ鍵をAPが生成する。それをKEKで暗号化（RC4を使う）してクライアントに配る。また、この際もMICを生成して正当性の確認ができるようにする。
７．④クライアント→APにACKの送信
　クライアントが受け取ったMICの正当性を確認したり、GTKをRC4で復号できたらACK（確認応答）をAPに返して４way handshakeの完了となる。
以上、４way handshakeの手順である。
ちなみに実際のデータを送るときは「TK＋送信元MACアドレス＋IV＋パケット番号＋実データ」の５つを使い暗号化する

Q.WPA2（Wi-Fi Protected Access 2）：
WPAではRC4ベースの暗号化方式を使っていた。それだと脆弱性があるので、AESベースのCCMP暗号化方式を採用したのがWPA2である。
また、整合性チェック（MIC）の方式も変わった。WPAでは、暗号化したデータの後ろにMICを張り付けていた。一方WPA2では、MICも暗号化対象とすることで、改ざんされたら必ず気づけるようになった。これを専門用語でAEAD(Authenticated Encryption with Associated Data：認証付き暗号)と呼ぶ。

Q.AEAD(Authenticated Encryption with Associated Data：認証付き暗号)
WPAの時代は、暗号化パケットの後ろにMICをつけていた。いわば、暗号化と認証が別々のプロセスとして扱われていた。そのため、どこかが間違っていると、AP側は「あ、このパットは暗号化部分がミスってるよ！」や「いや、認証部分がミスってるよ」などと具体的なエラーを返すことができた。これを利用して攻撃者はうまく改ざんできる方法を調整していた。（このような仕組みはパディングオラクル攻撃と呼ばれている）
しかし、WPA2では、認証と暗号化を同じプロセス内で実施するAEAD方式を採用した。これにより、どこかが間違っていたとしても、AP側は暗号化処理なのか認証処理のどっちがまちがっているのか判断できない。そのため特にエラーメッセージを出すことなくドロップされる。これをされると攻撃者はヒントを得られないので攻撃を進めることが難しくなる。

設問２
（１）不正メールの踏み台にされてしまうリスク
もし、A社とは関係のないドメインをほかのメールサーバへ転送してしまうと踏み台にされてしまうリスクがある。踏み台にされると、A社MSV３が不正なメールを送っていると判断されブラックリストに記載される。そうなると、A社内社員からの正当なメールも拒否されてしまい、まともに業務ができなくなる。そのため、外部（B社も含む）からのメールは転送してはいけない設定にする。

（２）ルータ４

図１と表１から推測する。もしルータ５にOP25Bを設定してしまうと、B社からMSV2宛ての通信も拒否されてしまう。それだとＢ社がメールサービスを一切利用できなくなる。なので、ルータ４に設定する。こうすれば、動的IPアドレス＆かつポートが25番の通信をインターネットに出す前にブロックできる。なお、B社が外部宛てにメールを送る際は送信元がMSV2になる。そのため、それは動的IPアドレスではないのでブロックされることなくインターネットへ出ることができる。

Q.サブミッションポートを使う場合はルータ５にOP25Bの設定をしてもいいのでは？
A.「もし、全ユーザがサブミッションポート（587番）を使うのであれば、ルータ５にOP25Bの設定をすれば、無駄なトラフィックを入り口で早々に拒否できる。そっちの方が効率的じゃん」という考えを思いつくでしょう。もし、全員がサブミッションポートを使えるならばいいが実際はそうもいかない。顧客の中には古い機能にしか対応できないシステム構成もある。つまりサブミッションポートに対応できない顧客もいる。なので、ルータ５でOP25Bを作るのではなく、顧客からの25番は甘んじて受け入れるけど、外部に出すときはしっかりフィルタリングさせてもらうよ！という構成が必要になる。そのため今回の構成ではルータ４にOP25Bを適用している。

（５）110番　587番
110番はPOP3をあらわし、587番はサブミッションポートをあらわしている。外部であるB社がMSV3にアクセスする必要があるので、メールを受信するPOP3とB社社員からのメール投稿を受け付けるためのSMTP-AUTHが必要になる。
なお、メールに関しては外部からMSV3に届く転送メールのSMTPの許可も必要だが、これは既に設定されていることなので、25番（SMTP）は回答から外すことができる。

p.3 L6 OP25B(Outbound Port 25 Blocking)
ISP管理下にある動的IPアドレスがISPのメールサーバを経由せず、インターネット上にある外部のメールサーバに直接向かう通信を禁止する仕組み。
具体的にはISPがインターネットとつながるルータにOP25Bのフィルタリングルールを追加する。これは、動的IPアドレス＆かつ宛先ポート25番（SMTP）ならブロックするというルール。これをすることで、外部への直接接続を遮断できる。

Q.メール転送の流れは？
A.動的IPアドレス、メールサーバ、OP25Bなどいろいろな単語がでてきて結局どういう経路でどのようにメールが転送されるのか分かりにくくなってきている。そのため一度以下で明示的に理解しておこう！
＊例として問題文中の構成を使う。
▼前提
　・各ISPはOP25B実施
　・B社は動的IPアドレス
　・A社は独自メールサーバを運用（a-sha.co.jpドメイン）
　・B社はQ社メールサーバを使う（q.sha.co.jpドメイン）
　・メールサーバをMSVと略す。

１．B社社員PCからa-sha.co.jp宛てにメールを送りたい
２．Q社MSVへ送信
　B社のメールソフトクライアントではQ社MSVが登録されているので、Q社MSVにポート587番を使い送信する。
３．Q社MSVはa-sha.co.jpの名前解決
　宛先ドメインの名前解決は、ユーザではなくMSVが実施する。で、当該ドメインを管理するサーバのホスト名をMXレコードで取得し、再度、当該ホスト名のIPアドレスを名前解決する（Aレコード）。もしくはグルーレコードがあればその時点でIPアドレスの取得が完了する。
４．インターネットを跨ぎA社MSVへ到着
　手順３でIPアドレスを取得できたので、そこまでパケットを届ける。また、Q社でOP25B設定があっても、メールの送信元IPはQ社MSVのIPアドレスであるためブロック対象から外れるので正常にインターネットへ出ることができる。
＊この通信において、P社ISP内にあるP社MSV（MSV1）を経由することはない。
５．A社の返信
　A社がB社からのメールに返信する際は、送信元ドメインを確認する。この場合はq.sha.co.jpドメインが送信元なので、A社MSVが名前解決処理をするときはそのドメインで名前解決する。
＊A社からB社へのメール送信時も、P社ISP内にあるP社MSV（MSV1）を経由することはない。

p.4 L8 “B社がA社ドメインのメールでサポート業務を実施するために、A社のメールサーバであるMSV3を利用する方式を検討したい”
なぜB社にA社のMSV３を使わせる必要があるの？一見、B社が契約しているMSV2で直接サポート業務をした方が効率的に見える。しかしそれをやってしまうと幾つかの問題が生まれる。
理由１：顧客が不安になる
　A社の製品を買ったのにも関わらず、サポートがA社のドメインでない場合、顧客はドメインが違うということでなりすましを疑ってしまう可能性がある。このようにドメインが違うと無駄な誤解を生んでしまう。
理由２：メールがはじかれる
　B社側がメール送信する際に、送信元をA社に変えた場合、顧客は安心できる。しかし、セキュリティ的に拒否されることがある。なぜならSPFなどで検査した場合、A社ドメインを使っているにも関わらず、実際の送信元のメールサーバはMSV3ではなくMSV2なので不整合が生まれ拒否されてしまう。

Q.では、実際にどうやってメール委託業務をしているの？
A.A社MSVを経由しなきゃいけなかったり、ドメインを直しただけでは無理だったり、色々な問題が問題があう。では、解決策はあるのか？答えは….ある！。では、実際の流れを見ていこう！
１．顧客がA社に問い合わせをする
　宛先はA社ドメインで、それを受け取るのはMSV３（A社メールサーバ）。
２．B社がMSV3からメールを取得する
　B社がMSV３にPOP3でアクセスして、自分のPCにメールをダウンロードする。
＊なおPOP3は認証機能があるため、B社以外からはメールが取得できないようになっている。
３．B社が返信メールを作成
　B社社員が自身のPCで返信メールを作成する。
＊この時の送信元はA社のドメインを使う。
４．B社社員がメール送信
　A社のMSV3宛てにメールを送信する。この時、SMTP（ポート25番）だとQ社側のOP25Bでブロックされるので、SMTP-AUTH（ポート587番）を使う。
５．MSV3で認証後、転送する
　A社MSV3にSMTP-AUTHでアクセスすると、認証プロセスへ進む。その認証が成功するとメールが転送される。
これによって、ドメインはA社のものを使える＆かつなりすましとしてブロックされないようになる。

p.5 SPF(SenderPolicyFramework)
　SPFは送信元のメールサーバの正当性を確認する仕組み。では、流れを見ていこう！
１．SMTPセッションの開始
　メールを送る前に送信側のメールサーバ（MSV100）と受信側のメールサーバ（MSV200）はSMTPセッションを開始する準備を整える
＊MSV100はTCP25番接続をする→MSV200は220 Readyを返す
２．受信側の情報取得
　送信側はEHLOコマンドを受信側に送り相手の情報（ホスト名、サポートしている拡張機能等）を取得する。これにより認証（SMTP-AUTH）、暗号化（STARTTLS）、ファイルサイズ（SIZE）の拡張機能のネゴシエーションができる。
＊コマンドはEHLOを使う。EHLOを使うのは送信側だけでよい。受信側はそのEHLOに答えるだけ。
３．相手の正当性確認（SPF）
　MSV100がMAIL FROMコマンドとして送信者のメールアドレスを記載してMSV200に渡す。
MSV200は当該ドメインのTXTレコードを取得し、その中に記載されているIPアドレス範囲とMSV100のIPアドレスを比較し、整合性が取れるかを確認する。
４．メール送信
　SPFの認証まで終わったら、次に宛先を送り（RCPT TO）、次に本文を送る（DATA）という手順でメールを送信する。

設問２
（１）リキー（ReKey）
ReKeyとはSAの再確立のこと。ローテーションと表現されることもあるが、ローテーションは鍵の再確立全般をあらわしている。IPsecにおける再確立ときかれたらReKeyと答えるのが安牌。

（２）IPsec通信で送受信されるメッセージが、通信中に改ざんされていないこと
フェーズ２の認証方式によって認証できる対象は、メッセージの改ざん検知など。
では、どのような仕組みで改ざん検知ができるのか、認証にフォーカスしたフェーズ2の流れを見ていこう！
１．送信者は、データパケットと認証鍵を合わせたものをHMACでハッシュ化する。ハッシュ値を付加してパケットを送信。
　＊認証鍵とは”フェーズ１で作成されてSKEYID”＋”ナンス”+”SPI”をPRFという関数に入れて導出される。この値はとても長いので、最初の256bitは暗号化鍵用、次の256bitは認証用という風にチョキチョキしてそれぞれの鍵を作っていく。
２．受信者は受け取ったパケットを送信者と同じ手順でハッシュ化する。導出されたハッシュ値が一致したら、改ざんされていないことが証明される。
以上の手順より、認証方式によって認証できる対象はメッセージであり、認証内容は改ざんされていないこと。という回答になる。

Q.ちなみに上記の認証プロセスでは本人の正当性も認証できるのになぜ回答は改ざん検知だけなの？
A.上記、認証プロセスでは本人の正当性も保証される。なぜなら、ハッシュ値を算出する際に、SKEYIDも要素の一つとなっているから。同一のSKEYIDを保持できていることは、フェーズ１で正しく鍵交換できている証明になるので本人の正当性の証明になる。
しかし、今回の問題の肝はフェーズ２の認証について。なので、本人の正当性はフェーズ１で既に証明されているものなので、わざわざフェーズ２の機能として記す必要もないという考え方から、回答にはメッセージの改ざん検知のみが記載されている。