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"
  }
}

▼ゾーン転送の流れ
１．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側は暗号化処理なのか認証処理のどっちがまちがっているのか判断できない。そのため特にエラーメッセージを出すことなくドロップされる。これをされると攻撃者はヒントを得られないので攻撃を進めることが難しくなる。

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

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

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

（３）OSPFのリンクステート情報交換は、IPマルチキャスト通信で行われるから。
IPsecはユニキャストにしか対応していない。そのためマルチキャストを使うOSPFを扱うことができない。
Q.なぜIPsecでマルチキャストをすると失敗するの？
A.では、具体的な流れとともに確認しよう！主にルーティング担当とIPsec担当がいるということを念頭に置いておきましょう。
１．OSPFパケット誕生
　ルータがトンネルインタフェースでOSPFパケットを生成してマルチキャストに送信する
　宛先：224.0.0.5（リンクローカルマルチキャスト，TTLは１）
２．ルーティング担当がパケット処理
　tunnel destinationから宛先はWAN側になっているのでWANポートから出す
３．IPsec担当が処理
　WANポートから出る直前にIPsec担当がパケットを捕まえて、自身のSPDからprotected,bypath,discardを決める。
　しかし、宛先が224.0.0.5のトンネルなんて作っていないのでIPsecでは流せない。なお、IPsecでは流さずそのままWANポートから出力しても破棄されて終わる。

Q.なぜGREを使うとマルチキャストを扱えるようになるのか？
A.では、具体的な流れとともに確認しよう！主にルーティング担当とIPsec担当がいるということを念頭に置いておきましょう。
１．あらかじめGREトンネルを拠点間で作成しておく
　＊これによりパケットの中身は関係なく、一旦GREのトンネル入れて流そうというプロセスが追加される（＝この段階で１対１通信が確立する）。
２．OSPFパケット誕生
　ルータがトンネルインタフェースでOSPFパケットを生成してマルチキャストに送信する。トンネルインタフェースでOSPFを有効化しているので、マルチキャストももちろん対向のトンネルに送出される。
　宛先：224.0.0.5（リンクローカルマルチキャスト，TTLは１）
３．パケットをGREカプセル化
　GREが手順２で送信されたマルチキャストパケットはトンネルを通るのでキャッチしてGREでカプセル化
４．IPsec担当が処理
　手順３によって通常の１対１パケットとしてIPsecに届くので、いつも通り宛先をSPDで判断して、「あ、これはGREトンネルの１対１だから、このSAでこういう方式で暗号化とかすればいいのね。OK～」と処理をして流す。

Q.GREでやってることはIPsecのTunnelモードではできないの？
A.答えは「パケットがIPsecまで来た際に、SPDを検索するがそもそも224.0.0.5に関するポリシーなんて定義していないから」。

Q.正直、トンネルを作れる（１対１にできる）ならGREじゃなくてもいいんじゃないの？
A.確かに、１対１のトンネルを作れるならば、GREでなくもてIPsec自体は成立する。実際にIP in IPやL2TPをつかってもIPsecは作れる。しかし、GREでなくてはならない理由もある。
理由１：GREはなんでも流せる
GREはGenericRoutingEncapsulation（汎用ルーティングカプセル化）という名前の通り、GREはなんでもカプセル化の対象にできる。IP-in-IPは理論上、IPをカプセル化できるといえど、多くのルータではIP-in-IPを使う時にマルチキャストをブロック挙動を取ることが多い。
一方、L2TPはマルチキャストを流せる。がその処理がとても重くなってしまう。
理由２：ヘッダが軽量
GREヘッダは24バイト（[新IPヘッダ(20)][GREヘッダ(4)]）のカプセル化。一方L2TPは40~50Byte（[新IP(20)] [UDP (8)] [L2TP (6〜16)] [PPP (2〜4)] [元のパケット]）に膨れ上がる。
理由３：コネクションレス型
GREはコネクションレス。しかし、コネクションは通常のパケット同様にTCPかアプリケーション側が管理するのでわざわざGREが管理しなくても順序保証、欠損管理などの機能は別でカバーできる。一方L2TPは内部で運ぶPPP回線が順序の入れ替わりにきわめて弱いため、順序保証を確実にする必要がある。そのためコネクション型となりパケットサイズやオーバーヘッドも必然的に多くなってしまう。
👆ほかにも理由があるが、GREが選ばれるのはこういう理由があるよという解釈を持っておこう！

設問４
（１）GREでトンネリングが行われるから
GREを使うことで既に以下のような構成になっている。
GRE：[外側IP][GRE][社内IP][データ]
一方、IPsecのトンネルモード単体はこのようなパケット構成になる。
トンネルモード：[外側IP][ESP][社内IP][データ]
このように新しい外側IPを付与することで内側のパケットを暗号化対象にできる。
では、最後にトランスポートモードのパケット構成を見ていこう
トランスポートモード：[社内IP][ESP][データ]
こちらは既に設定されているIPの内側を暗号対象にしている。
では、GREとの組み合わせを見ていこう。
GRE＋トンネルモード：[外側IP][ESP][外側IP][GRE][社内IP][データ]
GRE＋トランスポートモード：[外側IP][ESP][GRE][社内IP][データ]
以上、よりトンネルモードだと外側IPが二重に付加されてしまい無駄なオーバーヘッドが発生する。一方、トランスポートモードでは二重のオーバーヘッドがないため、こちらを採用するほうが効率的と言える。

設問５

（２）L2SWaとL2SWbを異なるサブネットにする
　現状のデータセンタ構成をみると、IPsecルータ、L3SW、L2SWa、L2SWbの間でループ構成ができてしまっている。しかし、異なるサブネットに配置することで、ループを防ぐことができる。
具体的には、
今までのARP経路：「L3SW→L2SWa→IPsecルータ→L2SWb→L3SW→ループ」と「L3SW→L2SWb→IPsecルータ→L2SWa→L3SW→ループ」というようにループが発生してしまう。異なるサブネット変更後：「L3SW→L2SWa→IPsecルータで止まる」と「L3SW→L2SWb→IPsecルータで止まる」
以上、より異なるサブネットに配置することでループを防げるようになる。
＊異なるサブネット：カッコつけた表現だが、実際はVLAN分離をしているだけという解釈
＊L3SWとIPsecルータがループ構成から外れている理由は、もともとOSPF用のリンクであるため異なるVLANで構築されているから。

Q.そもそも現状の構成でなぜループが発生するのか？
A.では、ループになる原因を図９を参照しながら見ていこう！
１．データセンターのL3SWがWebサーバにパケットを届けたい
　IPアドレスは知っていてけど、MACアドレスを知らないときはARPをブロードキャストする
２．各機器にARPが届く
　L3SWからのARPは受信以外のすべてのポートから出力される。つまり、IPsecルータ、L2SWa、L2SWbにARPが届く。
３．各機器もARPを拡散する
　各機器は受信ポート以外のすべてのポートでARPを送信する。
４．ARP応答がくる
　L2SWaのARPは無事、Webサーバまで届きWebサーバから適切なARP応答がL2SWaに届く。
５．L3SWにARP応答が返る
　WebサーバからのARP応答がL2SWaまで届き、それがL3SWに届く。
これで完了！と思うかもしれないがここにpithallがある。
６．未解決のARPが回り続ける
　手順３の段階で各機器にARPが届いているので、自分宛でないARPは受信ポート以外のすべてのポートに転送される。これによってループが発生する。
　＊ループを起こさないためには木構造（終端があり１つの行先には１通りの通し方しかない構造）にする必要がある。
以上のプロセスによってループが発生してしまう。

Q.ループが発生していても正常なARP応答はL3SWに届くのに、なぜ通信はできないの？
A.ARPループによっていくつかの不具合が発生してしまうから
1つ目：ARPによって、MACアドレステーブルが頻繁に変動する
　例えば、ARP応答は巡り巡って発信者のL3SWまで届いてしまう。そうなると、ARPの送信元はL3SWのMACアドレスであるにもかかわらず、ARP送信元MACと受信ポートをL3SW自身が学習してしまう。このようなことが繰り返されることによって、MACアドレステーブルが頻繁に変動（フラッピング）してしまい、適切な出力ポートが分からず通信ができなくなってしまう。
2つ目：CPUのキャパオーバー
　これはいたってシンプルな理由。ARPの転送にはCPUを消費する。ループすればするほどパケットのサイズは際限なく増幅する。その増幅したパケットをCPUが処理しきれなくなってしまい、正常な通信も処理されなくなってしまう。
３つ目：ARP応答ができるのは本人のみ
　L3SWが正常なWebサーバのMACアドレスを持っているといえど、ARP応答を返せるのはWebサーバのみ。そのため、L3SWに届いたARP応答も通常通り、受信ポート以外から転送されるだけ。
　＊もし、L3SWでも自分が知っているからという理由でARP応答を返せたらループは消滅できる。
　
（３）本社：２　営業所：１　データセンタ：２
VRRPを動かすための独立したサブネットが、当該拠点にいくつあるかを考える。その考えをもとに、名古屋営業所は、L2SW１つだけなので、１つの仮想IPで運用可能。本社は、L2SWaとL2SWbの２つのサブネットがあるため、２つの仮想IPを準備する必要がある。データセンタに関しては、本社と同様の理由で２つの仮想IPが必要になる。
＊もし、独立したサブネットが３つあるならVRRPの仮想IPも３つ準備する必要がある。

（４）どのサーバアクセスも、VRRPのマスタルータが稼働する機器に接続されたWAN回線を経由して行われる。
名古屋営業所のIPsecルータとL3SW間のOSPFリンクが動作している場合は、お互いを冗長経路として把握することができる。しかし、そこのリンクが切れると、OSPFは動作しなくなりルーティング情報からお互いの経路情報が消えて冗長化対象として扱われなくなる。そうなると、VRRPマスタルータがつながっているWAN回線でのみ通信が行われる。客観的にみて別の回線を使ったほうがコストが低かったとしても、その情報を互いに知る由もないため、１つの回線のみを使い続けてしまう。

（５）インターネットVPN経由のコスト値が最小230であるのに対して、専用線経由のコスト値は200で最も小さい

本社からインターネットへの２つの経路の通信コストを算出すると、
・本社L3SW→(+10)→本社IPsecルータ→インターネットVPN(+220)→データセンタIPsecルータ＝230
・本社L3SW→専用線(+200)→データセンタL3SW=200
つまり専用線を通ったほうがコストが小さいため専用線が使われる。もし、IPsecルータがVRRPマスタルータでもコストは210で依然として専用線が使われる。

（6）う：広域イーサ網→本社→専用線　え：インターネットVPN→データセンタ→専用線
「う」の名古屋営業所のPCからデータセンタへは、通常はインターネットVPN接続を通るが、表３より名古屋営業所のインターネットVPNに障害が発生している。これにより広域イーサ網を使う経路になる。
「え」の名古屋営業所のPCから本社のDMサーバへは通常は広域イーサ網を使う。しかし、表３より名古屋営業所の広域イーサ網に障害が発生している。そのためインターネットVPNを使う経路になる。しかし、問題文中より営業所と本社は直接インターネットVPN接続がない。そのためデータセンタを経由する必要がある。なので、経路は、「名古屋営業所PC→インターネットVPN→データセンタ→専用線→DMサーバ」となる。
＊なおL3SWやIPsecルータなどの記載がされない理由はVRRPによって機器が動的に変動する可能性があるため明示的には記載しないなどの理由がある。

p.13 広域イーサネットサービス
広域イーサネットサービスとは、物理的に離れた機器同士をあたかも同一LAN（ブロードキャスト等が利用可能）に接続しているようなふるまいを可能にするサービス。なお、使うネットワークとしてはインターネットのような不特定多数の利用者がいる環境ではなく、事業者が独自に構築した閉域網を使う。

p.14 L3 “サーバのIPアドレスの変更が生じないようにする”とあるが、物理的移動したのにIPアドレスを維持することなんてできるの？
インターネットをまたぐ際は、カプセル化をすることで相手まで到達させる。そしてその後、カプセル化を解除すれば、物理移動に依存せずIPアドレスを維持できる。具体的な手順を以下に記す。
１．サーバをデータセンタへ移行する
２．本社とデータセンタ間でトンネルを構築する（簡素化のため支社のことはここでは考えない）
３．OSPFを稼働させ内部のIPプレフィックスをトンネルを通して相互に通知しあう
４．相手の内部情報が把握できたので、今後、その内部宛てに送るときはトンネルを経由して通信可能になる。
以上のプロセスを経由することによって、物理的な移動があってもIPアドレスを維持できる。

p.14 L7 “インターネットVPNと既設の広域イーサ網間でOSPFを稼働させれば、この要件を満たすことができると考えた”とあるがどういうこと？
「インターネットVPNと広域イーサ網間で〜」という問題文の日本語は、初見だと「2つの回線をガッチャンコしてその間で何かするの？」と誤解しやすい、ちょっと意地悪な表現。でも、実際に言いたいことは、これは「インターネットVPNというルート」と「広域イーサ網（および新設する専用線）というルート」の、それぞれの回線上で独立してOSPFを稼働させるという意味。

p.14 L7 “広域イーサ網間でのOSPF”って具体的にどういう挙動？
広域イーサ網は１つの巨大L2スイッチとして動作している。そのため、広域イーサ網を使ってOSPFを使う場合は、通常のOSPFと同じように特にカプセル化など不要でそのままパケットを広域イーサ網に流せばOK。あとは巨大L2スイッチ（広域イーサ網）がパケットをコピーして、MACアドレス情報などから適切な宛先に転送してくれる。

p.14 SA
IPsecにはパケットを暗号化、復号などのルールに関する関連単語が複数ある。その一つがSA。では、以下でそれぞれを詳しく見ていく。
SA（Security Association）
　：コネクションのこと。関係性。物理的なものではなく概念的なもの。
SPI（Security Parameter Index）
　：どのSAを使っているかの識別子。32ビットで構成。
SAD（Security Association Database）
　：SAの詳細な情報を保持するデータベース。具体的には、SPI、暗号アルゴリズム、秘密鍵など。
SPD（Security Policy Database）
　：どの通信はIPsecを通して、どの通信は通さないかなどのIPsecのルール（ポリシー）のデータベース。

p.15 表１　IKEフェーズ１で決定されるパラメータ

具体的にそれぞれのパラメータがどのタイミングでどのような意図で使われるのか見ていこう。
１．プロポーザルの交換
　暗号化方式（aes）、ハッシュ方式(sha256)、認証方式(preshare)、鍵交換方式（DHグループ(14））、ライフタイム(7200)を生の状態で相手と交換して、二者間で取り決め（ポリシー）を作る。
２．DH鍵交換
　DHを使って今後の暗号化用の鍵、ハッシュ用の鍵のもとになる鍵(SKEYID)を生成する
３．認証と改ざんチェック（ここから暗号化）
　１で決めた暗号化方式（aes）、ハッシュ方式(sha256)、認証方式(preshare)に則り、２で作成された共通鍵(SKEYID)をベースにID（IPアドレスやホスト名）と要約情報（これまでのやり取りの）を暗号化して相手に送る。
４．答え合わせとフェーズ１の完了
　３のパケットを復号して自分がハッシュ方式(sha256)によって算出した要約情報と相手の要約情報が一致することを確認する。相手のIDが正しいことも確認する
５．ライフタイムによるローテーション
　２、３で作った鍵は１でやり取りした際のライフタイムに則り破棄されローテーションする。

実例
#事前共有鍵の作成
crypto isakmp key <key> address <IPアドレス>

#フェーズ１
crypto isakmp policy <ポリシー番号>
encryption aes 192
hash sha256
authentication pre-share
group 14
lifetime 3600

p.16 表２　IKEフェーズ２で決定されるパラメータ

具体的にそれぞれのパラメータがどのタイミングでどのような意図で使われるのか見ていこう。
１．プロポーザルの交換
　セキュリティプロトコル(esp)、暗号化方式(aes-256)、ハッシュ方式（sha-256）、ライフタイム(3600)、通信モード(transport)を交換する
２．本番鍵の生成
　ナンスを交換し、その素材とフェーズ１で作成したSKEYIDをベースに、暗号化鍵、ハッシュ鍵を生成する。
　＊例外としてもし、PFSを導入する場合はフェーズ１と同様にDHで１から鍵を作り直す
３．フェーズ２の完了
　これ以降の通信はフェーズ１のトンネルは通らず、フェーズ２の鍵で実際に通信される

実例
#フェーズ２
crypto ipsec transform-set <ts名> esp-aes 256 esp-sha256-hmac
mode <tunnel または transport>

p.16 静的経路制御でも広域イーサ網との間で負荷分散を行うことができるが、運用管理を容易にするためにOSPFを稼働させたい
Q.静的制御でどうやってやるの？
A.具体的には各拠点のプレフィックスなどからネクストホップをトンネルに設定したりする。しかし拠点のプレフィックスなどが増えるたびに、全拠点でスタティック設定を追加しなければならないため運用がとても大変。
Q.負荷分散はどうやってやるの？
A.同じ宛先に対してネクストホップを広域イーサ網とトンネルの２つを設定する。スタティック設定の場合、ただ２つを準備すれば勝手に負荷分散してくれるので、ルートマップやポリシー制御は特に不要。

p.17 L2TP（Layer 2 Tunneling Protocol）
まずはパケット構成から見ていこう。
[新IP][UDP][L2TP][PPP][IPパケット]のようになっている。
この図からわかる通り、L2TPだけでなく、PPPというヘッダも付加されていることが分かる。そのため、問題文中では単にL2TPと呼ばれているが厳密にいうと、PPP over L2TPのことである。なのでここからは問題文中のL2TPをPPP over L2TPと呼ぶことにする。

Q.PPP over L2TPは認証に重きを置いている。ではなぜGREoverIPsecではL2TP,PPPのような大きな認証ヘッダが付加されないの？
A.そもそもGRE over IPsecは拠点間通信に使われる。つまり、相互のルータの正当性が保証されている状態にある。そのため相手ルータ自体の認証機能はあるものの、ユーザ個人単位の認証は必要ないためそれに伴うヘッダも付加されない。一方、L2TPはリモートワークなどで動的に相手のIPアドレスが変わる環境で使われる。要は、信頼性が担保されない場面で使われる。そのためL2TPヘッダやPPPヘッダを別で付加して利用者個人に対する認証機能を装備する必要がある。要は、「GREoverIPsecは個人認証不要。逆にL2TPは個人認証が必須だからそれに伴いパケットサイズも増大してしまう」ということ。

Q.PPPってなに？
A.PPPはレイヤ２のプロトコル。つまり単体ではL3のルータを跨げないプロトコル。また、役割としては認証とIPアドレス配布を担う。具体的にどのように認証とIPアドレス配布が行われるのか手順を確認しよう。
１．LCP（Link Control Protocol）フェーズ
　お互いで「こういう通信にしようぜ」というのをすり合わせる
２．認証フェーズ
　チャレンジレスポンス方式などを使いユーザの認証を行う
３．NCP(Network Control Protocol) / IPCPフェーズ
　IPアドレスの払い出し
以上が大まかな流れなので軽く押さえておきましょう！

Q.L2TPってなに？
A.一言でいうと、「トンネリングプロトコル」。トンネルを張ることで同一のLANにいるかのような振る舞いができる。では、イメージしやすいようにL2TPのトンネリングまでの流れを見ていこう！
１．物理IPの確認とTunnel IDの確認（Control Connection フェーズ）
　PCから会社のルータに通信をして、「俺はTunnel IDの10番を使います！」と送り、ルータもPCに「では、私はTunnel IDの20番を使います！」と送る。それに対してPCが「OK、了解！」と送る。
　＊１つ目ののメッセージをSCCRQと呼び、2つ目ををSCCRPと呼び、３つ目をSCCNと呼ぶ。
２．Session IDの確認（Session フェーズ）
　手順１では機器間で使う道に対するTunnel IDを確認した。次にやるのは実際にその道を使う人を識別するためのSession IDを交換する。PCは「俺はSession IDの200を使います！」と送り、ルータもPCに「では私は、Sessopn ID 220番を使います！」と送る。
　＊１つ目ののメッセージをICRQと呼び、2つ目ををICRPと呼び、３つ目をICCNと呼ぶ。
３．ルータ側でSession IDごとに仮想的な箱を作っておく
　ルータがSession IDごとに仮想的な箱(Virtual-Access)を作っておくことで、「あ、このSessionIDならこの箱に丸投げしよう」とタスクを分けることができる。この箱はLANと接続しており、通常通りプライベートIPアドレスでの通信が可能になる。ルータと内部LANの中間にこの箱を挟むことで、ルータが外側IPをはがした後に「え？急にプライベートIPアドレスのパケット出てきたけど。。。どういうこと？」という混乱を吸収できる。
上記手順によって、仮想的にトンネルを作り出すことができる。
なお、このようにL2TPでは通常のルータが行う単純な転送機能の範疇を越えている。そのため、既存のルータの挙動を重ね合わせて理解しようとするのではなく、L2TPにはL2TP専用の高性能なルータが必要であり、内部での処理も別次元のことをしているという前提を持っておく必要がある。

p.18 PPPoE
A.PPPoEが使われる理由を一言でいうと「宛先を明示的にするため」。PPPは１対１が前提であるため、宛先を指定せずに通信ができる。しかしイーサネットの場合は１対多を前提にしているため、PPPのように宛先を記さない場合、宛先が分からず破棄されてしまう。そこで、イーサネット上でも１対１の通信をするためにPPPをイーサネットでカプセル化して、宛先を明示させる。それによりはきされることなく通信することができる。

p.18 図６　L2TP利用時の通信例

１．①PPPoEでインターネット接続可能にする
　PCがインターネットを使えるようになるにはISPとPPPoE接続が必要になる。これによって自身のグローバルIPアドレスを取得してインターネットとの通信を可能にさせる。
ここまでのパケット構成：[Ethernet][PPP][PPP接続制御データ]
　＊直接PCがIPアドレスを取得するというよりも家庭内Wi-FiルータがISPとPPPoE接続をしてIPアドレスを取得するケースが多い。内部のPCはルータから払い出されるプライベートIPアドレスを使い、ルータがそれをNAPT変換してPPPoEに流すという構成が一般的。
　＊正直現在においてはPPPoEよりもIPoEがデフォルトになっている。なのでPPPoEやL2TPはややレガシー寄りの技術。
２．L2TPトンネルを作成する
　手順１でグローバルIPを取得できたので、そのIPを使い会社のVPN装置とトンネルを作成する。
なお、依然としてISP経由の通信なのでPPPoEでのカプセル化は継続される。
ここまでのパケット構成：[Ethernet][PPP][物理IP][TCP/UDP][L2TP]
　＊なお１回目の通信でPPP認証は終わったので、移行のPPPはセッションIDが格納される。それによりユーザを識別子、毎回毎回認証必須とならないようにする。
３．PPPセッション確立
　社内にいるかのような同一サブネットとして振舞わせるために、認証とIPアドレス払い出しをしてもらう必要がある。なお、L2TPでトンネル確立済みであるため、それがPPPの１対１通信をインターネットを跨いでも可能にしている。
ここまでのパケット構成：[Ethernet][PPP][物理IP][L2TP][VPN用PPP][社内IP][TCP/UDP]
４．PCとサーバで通信
　１～３までの手順により、社内サーバと同一サブネットとして振舞うことができるようになったので、実際に通信する。
ここまでのパケット構成：[Ethernet][PPP][物理IP][L2TP][VPN用PPP][社内IP][TCP/UDP]

p.19 ESPヘッダ、ESPトレーラ、ESP認証データ
ESPヘッダ：SPIとシーケンス番号を格納している。
　SPIはどのSAを使うかの識別子をあらわす。シーケンス番号はリプレイ攻撃に備え、同一のシーケンスは受け取らないようにすることで攻撃を防ぐ意味合いがある。
ESPトレーラ：パディングと次ヘッダーを格納
　パディングは暗号化処理等で切りのいいデータ長にするためのもの。暗号化をする際は切りのいいデータ長でないと動作しないことがある。そのため、穴埋めの調整役として使われる箇所。
　次ヘッダーは、次にどのようなパケットがあるか（IPv4なのかGREなのか..とか）を示すためのもの
ESP認証データ≒ICV（Integrity Check Value）：ESPヘッダ～ESPトレーラまでをハッシュ化した値を格納する。

p.20 GREトンネルとルーティングの挙動
GREトンネルを作成した時のルーティングの挙動を見ていこう！なぜ、対向のトンネルで同一プレフィックスを使っているのか？なぜ、宛先を対向ルータIPにせず対向トンネルIPにするのか？
様々な疑問を解消していこう！ここでは、以下の構成に当てはめながら進めていく。

#全体像
LAN 10.0.0.0/8
Tunnel 172.16.10.1/30
A拠点
WAN100.0.0.1/24
|
|
|
|
|
|
WAN 200.0.0.1/24
B拠点
Tunnel 172.16.10.2/30
LAN 192.168.0.0/16

１．A拠点LAN（10.0.0.0/8）がB拠点LAN（192.168.0.0/16）への接続を図る
２．A拠点ルータが192.168.0.0/16へのネクストホップを検索する
　スタティック設定をしている場合は、ネクストホップがB拠点のトンネル（172.16.10.2）になる

#拠点Aスタティック設定例
ip route 192.168.0.0 255.255.0.0 172.16.10.2

３．172.16.10.2へはどのインタフェースから流せばよいかを検索する。（再帰検索）
　その結果、A拠点のトンネルインタフェースからの出力であることを判明させる。
４．トンネルから経由する際にGRE処理を実施する
　GRE処理とはGREヘッダーの付加や新しい外側IPアドレスの付加を意味する。
＊もし、GREヘッダがないと受信側は外側IPを剥がした途端にプライベートIPアドレスがでてきて、混乱してしまう。そうならないように、GREで中身はIPv4ですよ！マルチキャストですよ！これはトンネルですよ！と教えてあげることで、処理をスムーズに進める役割を担う。

#拠点Aのトンネル設定
interface Tunnel0
ip address 172.16.10.1 255.255.255.252

tunnel source Gi0/0
tunnel destination 200.0.0.1

!Tips
上記コマンドにより、トンネルのIPアドレスを設定し、トンネルの物理的な送信元IPと宛先IPを指定する
トンネルの送信元をインタフェースにすることでIPアドレスの変更にも対応できる

５．インターネットへ流す
　GRE処理が終わるとインターネットを跨げる状態になるので拠点BのWAN側インターフェースまでパケットを流す
６．拠点BのWAN側インタフェースからトンネルへ
　外側IPアドレスとGREヘッダから、「これはトンネルの通信だ！」と判断し、トンネルインタフェースに流す。なお、拠点Bのルータは、送信元と宛先のペアから適切なトンネルを判断する。
　＊万が一、送信元と宛先のペア内に複数のトンネルを作りたい場合は、特別にキーを指定することで識別を可能にする。

# トンネル0と1で、GREヘッダーの中に別々の「合言葉（Key）」を埋め込む設定
(config-if)# tunnel key 100  (Tunnel 0用)
(config-if)# tunnel key 200  (Tunnel 1用)

７．トンネルインタフェースから内部LANへ
　トンネルの出口でGREヘッダを剥がす。そこでトンネル通信が終端して、あとは、通常通り内部LAN側インタフェースからパケットを送信する。
以上、これがGREトンネルの流れ。

Q. そもそもPC同士が通信する必要ある？特定のサーバをNAPTすればトンネルとかいらなくね？
A.実はPC同士でやり取りする機会はめっちゃ多い。そのためすべてをNAPTしていたらマッピングテーブルを手動で何百回も設定しなおす必要があるため、とても大変になる。また、内部のPCをNAPTできてしまうと、外部の攻撃者も内部PCにアクセスできてしまうのでセキュリティリスクがある。
では、具体的にPC同士の通信をするケースを見ていこう。
①IT管理者によるリモートデスクトップ接続：
　社員のPC不具合時などにリモデでIT管理者が直す際に、社員ごとにポートを割り当てたり、切り替えたりするのは効率的とは言えない。それよりも同一サブネットのように扱わせればプライベートIPアドレスでやり取りができるようになる。
②配信最適化（Windowsアップデート等）：
　Windowsのアップデートなどで全PCがMicrosoftのサーバにファイルを取りに行くとインターネット回線が圧迫される。しかし同一のサブネットであればPC同士で「君、ファイル持っている？」とやり取りしてもっていたら近くのPCからファイルをもらえるようになる。これによりインターネット回線によるシェーピングやポリシングなどの制限を受けることなくLANのMAXを引き出しダウンロードの高速化をすることができるようになる。
③分散コンパイル：
　3Dグラフィックなどの多くのCPU処理を必要とする場合、処理を空いているPCに分散して割り振るということができる。しかし、空いているPCは常に固定ではないのでNAPTで対応しようとすると面倒くさい。そのため「トンネル使ったほうがいいよね！」というケースがある。

p.21 OSPFのリンクステート情報の交換は、L3SWとIPsecルータのWANへのアクセス回線を接続するポートだけでなく、L3SWとIPsecルータを直接接続するポートでも行わせる。
IPsecルータとL3SW間で直接OSPFを動作させることで経路の冗長化が可能になる。冗長化することで、同一宛先に対して、複数の経路を持てるようになる。もし、一方のWAN回線が切れたら、優先度が低かった経路情報がルーティングにのってそれに従ってほかのWAN回線から通信ができるようになる。

（３）①許可する通信を追加する/②宛先NATに関する定義を追加する
①許可する通信を追加する：Webサーバが増えるということはそこに到達させるためのIPアドレスが必要になる。そしてそれをクライアントが接続要求した際に届かせる必要がある。なので、それを許可リストに入れる必要がある
＊ACLの場合、許可しないと暗黙のdenyによって拒否されてしまうので明示的に追加する必要がある。
②宛先NATに関する定義を追加する：p.4の5行目でIPアドレスの組み合わせは１対１に固定とある。なので、Webサーバが追加されたら、そのプライベートIPアドレスをグローバルIPアドレスに対応づける必要があるのでNATの定義を追加する必要がある。

設問２
（２）応答が行きの宛先IPアドレスとは異なる送信元IPアドレスから戻る
なぜ、これが問題なのか…？　→クライアント側でステートフルインスペクションを設定していると、意図した送信元からではない通信が来ることになるので、そのパケットは拒否されることになる。

設問３
（３）vlan1,vlan2
この回答はつまり、STUNサーバ１，２がL2SW1とL2SW2にそれぞれ接続することを意味している。
Q.FWよりも外にSTUNサーバを配置しちゃったら外部ユーザにも利用され放題じゃない？危険じゃない？
A.L2SWのACLやSTUNサーバ自体のホストFWで防御が可能。また、STUNサーバには内部情報が入っているわけではないので外部から利用されても特にセキュリティ上問題ない。
＊L2SWというとIPアドレスやポートが見れないイメージだがACLなどの適用は可能

設問４
（１）カ：HTTP　キ：WebSocket
カについては、問題文中にWebRTCを使う旨の記載がある。つまり、接続の開始はHTTPであると判断できる。キのWebSocketについては図6中にUpgrade:websocketとあるようにSIPでは自発的な双方向通信が求められるため、WebSocketが該当する。また、問題文中のキの後に「切り替え」という文字から、HTTPから切り替えできるのはWebSocketだ！という発想になる。

Q.HTTPが使われる理由…
A.問題文中にはブラウザを使って音声のやり取りをする旨の記載がある。スマホ用のアプリケーションであれば独自のさまざまなプロトコルが使える。しかし、ブラウザでは基本的にHTTPが主流。なので、ブラウザをつかって何かをしたいなら、まずはHTTPベースで考えましょうね！ということ。
そして今回の話にすり合わせると、WebRTCを使う旨の記述がある。WebRTCという「専用のアプリ/プラグインを必要としない仕組み」上、ブラウザのHTTPで始める必要があるというわけです。

Q.WebSocketってそもそもなに？…
A.HTTPの拡張機能。従来のリクエスト/レスポンス方式から双方向通信が可能となるように拡張された。そのためSIPなどにおいて、もし、リクエスト/レスポンス方式のままだとクライアントはサーバに対して「僕に対する着信ある？」を定期的に聞きに行く必要がある。これは端末のバッテリー、通信料、サーバ負荷などいろいろとデメリットがある。しかしWebSocketであれば、着信があればサーバ側から呼び出しが可能であるため必要な時に必要な分だけ自由に通信できるようになる。

Q.WebSocketが使われる理由…
A.HTTPはリクエスト/レスポンス方式。つまり、サーバ側から自発的にデータを送ることができない。しかしSIPにおいては、両者とも自発的に通信を開始できるようにしたい。かつ、それらの動作を、ブラウザ（HTTP）上で実行したい。この２つの条件を満たせるのがWebSocket。だからWebSocketが使われる。

Q.なんで最初からWebSocketじゃないのか…
A.WebSocektはHTTPの拡張。そのため、まずHTTPで通信を整えてからじゃないと使えない。最初からWebSocketでやるのは仕様上、不可能。

Q.なんでアプリケーション層のプロトコルをアプリケーション層のプロトコルでカプセル化しているの？…
A.SIPはアプリケーション層プロトコル。WebSocketもアプリケーション層のプロトコル。そのままSIP送っちゃだめの？という疑問がある。通常は[IP] [TCP/UDP] [SIP]のような構成で十分。しかしWebRTCだと[IP] [TCP] [WebSocket] [SIP]になっている。そこにはブラウザのルールがある。ブラウザはブラウザ自身が認めたプロトコル（HTTP、WebSocket）以外は基本的にそのまま送信しちゃいけない。なのでSIP通信は許可されたWebプログラム（JavaScript）ではないのでWebSocketに包んでいる。

Q.ブラウザが許可されていないプロトコルをHTTPやWebSocketで包むメリット…
A.通信をブラウザ管理下にすることができる。

Q.なんでRTPはWebSocketでカプセル化しないの？…
A.RTPに関してはブラウザが自分で作ったデータだからWebSocketなどで包む必要がない。Webプログラム（JavaScript）などはサーバ側によって挙動が決まってしまう。そのため安全性をもとめてHTTPやWebSocketで包む。しかしRTPの場合はブラウザ側に主導権があり、ブラウザがパケットを作成するため信頼性があるためわざわざ包まなくてもよい。
また、RTPは即時性を求めるUDPであるためHTTPやWebSocketのようなTCPだとオーバーヘッド等の点を考慮すると包むべきではない。

（２）ISP１とISP2から払い出されたIPアドレスを一つずつ割り当てる。
2つの異なるISPから払い出されたIPアドレスを割り当てないと意味ないよねと。そうしないと、もしも同一のISPから払い出されたIPアドレスを登録していたら、そのISP、1つが落ちたらIP－PBX自体が機能しなくなってしまう。なので、異なるISPから払い出されたIPアドレスを自社DNSのAレコードに登録して、そうすることによって名前解決で2つの異なるISPからのIPアドレスをクライアントに返すことができる。そうなれば1つのISPが落ちたとしても、もう一方の方のISPでのアドレス空間は生きているので、そっちでカバーが可能だよねっていうこと。

（３）vlan１,vlan2
IP-PBXはインターネットからのパケットをFWを通す前の段階で受け取りたいから。そして、マルチホーミングをするという観点で、２つのISPを利用できるようにL2SW1（vlan1）とL2SW2(vlan2)に接続する必要がある。

Q.IP-PBXをFWの内側に配置しなくてもいいの？
A.注目すべきはp.9に記載されている”IP-PBXはSessionBorderControllerとして動作し、グローバルIPアドレスとプライベートIPアドレスを変換する”という箇所。そもそもSBCは、一般的なWebサーバとは異なり、音声通信に特化したサーバである。また、セキュリティ的にもSBCには強固な音声専用FWが搭載されていることが多い。そのためFWの内側に配置しなくてもセキュリティ的には問題ない（むしろ配置すべきでない）。

Q.IP-PBXをFWの内側に配置すればよくね？
A.一見すると、FWの内側に配置すればSBCの強固なセキュリティとFWのフィルタリングによって二重のセキュリティを享受できると感じる。しかし、実際はFWの外側でなくてはならない理由がある。
理由：音声通話に使うRTPは動的にランダムなポートを使用する。基本的にFWは事前定義されたルールに従ってフィルタリングする。しかし、動的ランダムポートだと制御ができず誤ってブロックしてしまうことがあるため。そのためFWよりも外側に配置する必要がある。
図３を見ると、IP-PBXはL3SW1に直接ぶっ刺さってバイパスされているので構成的にFWを通らなくてもよいという美しい構成になっている。

Q.SBCのB2BUAのセキュリティ担保について…
A.B2BUAは外側と内側のセッションを完全に分断する。つまり、FWやルータのように外部からのパケットをそのままバイパスするわけではなく、仲介役（ここではIP-PBX）が新たにパケットを０から作りなおして内側に送りだす。そのため、外部からきた悪意のあるパケットも、仲介役が内側へのパケット構築中に「ん？これおかしいぞ」と、きづくことができ、遮断できる。
似ている概念としてはSSLインスペクション。これも外と内のセッションを完全に分断することで仲介役が主導権を握り、パケットの検査等がしやすくなるというもの。

（４）ク：IP-PBX　ケ：DNS　コ：LB
通信の手順と照らし合わせることで納得できる。
以下の手順３，４，５より問題文中の空欄の回答はク：IP-PBX　ケ：DNS　コ：LBになる。
１．クライアントがWebブラウザでAPサイトにアクセス
２．URLから名前解決をしてA社のWebサーバからプログラム（JavaScript）をダウンロードする
３．２のプログラム内に「IP-PBXはこのFQDNですよ。接続してくださいね！」という命令があるのでそれに従う。
４．３の命令に従いAPはIP-PBXのFQDNの名前解決をするためDNSクエリを発行する
５．IP-PBXの権威DNSはA社のロードバランサー（LB）になるので、最終的にそこからIP-PBXのAレコードを取得する
６．そのAレコードに従ってIP-PBXに対してHTTPでセッションを確立し、WebSocketに切り替える
　＊ブラウザを使っているので直接SIP接続ではなくHTTPを挟む必要がある。また、WebSocketに切り替えることで自発的な双方向通信ができるようになる。その結果、発信だけでなくサーバからの着信にも対応できるようになる。

設問５
（１）サ：切り戻し
切り戻し：システムの切り替えを試みたけど、正常にいかなかったから元の状態に戻すこと。

（２）FQDNの数：１　グローバルIPアドレスの数：４
マルチホーミングを実施していてもFQDNは１つで十分。そのFQDNに対するＡレコードを冗長化していればマルチホーミングを構成できる。逆に増やしてしまうとDNSサーバ管理などが複雑になってしまう。そのためFQDNは１つでよい。
グローバルアドレスについては、ISP１とISP２から割り当てられているIPアドレスをそれぞれ１つずつ割り当てることでマルチホーミングが可能。また、問題文中のp.4の3~5行目に”変換前のIPアドレスの組み合わせは１対１に固定”とある。これはもし、シングルホーム（１つのISP）で、2台のWebサーバで運用していたとしても、１つのWebサーバに１つずつのグローバルIPアドレスが必要ということになる。そして、今回のケースは２つのISPを使っているので、必然的に１つのWebサーバにはISP１のIPアドレスとISP2のIPアドレスが必要になり、それが２台の構成なので「２つのIP×２台のWebサーバ＝４」ということになる。
別ケース①：もし、３つのISPを使って、２台のWebサーバ構成なら、１つのWebサーバに３つのIPを割り当てる必要があるので「３つのIP×２台のWebサーバ＝６」。このようなIPアドレス構成になる。
別ケース②：もし、１対１のstatic方式ではなく宛先NAT方式（DNAT）ならどうなるか。。。答えは「２つのグローバルIP」で構成可能。２つのISPから払い出されたIPアドレスをLBの仮想IPとして、DNSに登録しておく。そうすれば、あとは内部で勝手にWebサーバ１、２に分散される。１つのISPが落ちても残りのISPからのアドレスでWebサーバ１，２への分散通信は継続される。

（３）IP-PBX,STUNサーバ１,STUNサーバ２
IP-PBXについては、設問４（４）にもある通り、WebSocketでSIPをやり取りする必要があるので事前にIP-PBXの名前解決が必要となる。
STUNサーバ１とSTUNサーバ２についてはSIPセッションで自分の外部用のIPアドレスを知っておく必要があるため名前解決が必要になる。

Q.STUNサーバが２つある意味は？
A.マルチホームしているため、内部ユーザは結果的に２つのIPアドレス空間を使えるようになる。そのためSIPに指定する自分のIPアドレスの候補として２つのIPアドレスを準備しておく必要がある。
もし、１つのSTUNサーバしか利用しないと１つのISPからのアドレス空間しか返せない。。その結果、１つのISPで障害が起きるとSIPセッション自体も成立させることができなくなってしまう。

（４）FW
2通りの定義ファイルとは変更前と変更後のファイルをあらわしている。つまり、変更前後の両方に存在する機器だなぁと推測を立てる。その中で、主に設定変更が必要な機器は何か。。と考えるとFWが浮かび上がる。変更前のFWはDNS機能、NAT機能等を実装していた。しかし変更後はLBに引き継いでいる。そのように変更前後で設定する内容が違うのはFWなので答えもFWになる。

（５）①社外からWebサーバへのアクセス / ②社内からWebサーバへのアクセス / ③社内からインターネットへのアクセス
①社外からWebサーバへのアクセス：社外→Webサーバへの経路途中に新規LBが追加されたので、その新規LBの動（DNS機能やNAT機能等）作、並びに変更後のFW設定（フィルタリングの改修等）が正常に設定されていることを確認する
②社内からWebサーバへのアクセス：社内→Webサーバへの通信においては、こちらもFW（フィルタリング）やLB（WebサーバへのDNS機能等）を利用するため正常に動作することを確認する
③社内からインターネットへのアクセス：こちらもFW,LBを経由するため正常な動作を確認する必要がある。
まぁそもそもA社においては上記３つの通信しか基本的に発生しない。なので、「配置変換や設定変更を実施したから特定の経路を検査しよう！」というよりも、そもそも３つしか存在しないので難しく考え過ぎずわからないかったら思い浮かぶ通信の種類を記述するというのも一つの手。

（６）ISP２を経由した外向きDNS機能を確認する
問題文中の下線(n)には”ドメイン登録事業者に~~”と記されているためDNS関係の処理であることが推測できる。さのため、マルチホーミングに必要なDNS関係の処理を頭に浮かべることで答えが導き出される。では、具体的にどうのようなDNS設定が必要かを見ていこう。
１．マルチホーミングをするためにはA社のDNSサーバ（LB）自体のIPアドレスにISP１とISP２のIPアドレスを割り当てる必要がある。
２．また、そのA社DNSサーバまでたどり着くには上位DNSサーバがA社DNSサーバのホスト名とIPアドレスを把握しておく必要がある。
３．上位DNSサーバは自動でA社が追加したISP2のIPアドレスを反映させることはできない。
４．そのため、A社側が上位DNSサーバに対して、「僕はこのFQDNの権威DNSサーバです。で、IPアドレスはこれとこれです！」と上位に登録して教えてあげる。
５．そうすると上位DNSサーバがA社のドメインに対する名前解決を受けると、「A社ドメインの権威DNSサーバはこのFQDNで（NSレコードで提示）、IPアドレスはこの２つですよ（グルーレコードで提示）」と教えてくれる
６．クライアントは２つのAレコードから接続可能なIPアドレスへ接続する。
上記手順により、もしISP１に障害が発生したとしても、ISP２のDNSで名前解決できるためサービスの継続利用、つまりマルチホーミングの旨味を享受できるようになる。
おっと、話を元に戻すと、今回確認したいことは、上記手順４と５のテスト。つまり、ISP２側のDNS設定が正しく設定されており、そのルート使ってアクセスできるかを確かめる。それを簡単に表現すると回答のように”ISP2を経由した外向きDNS機能を確認する”となる。

（７）①’、③、④
①：ブラウザ１（外部）からSTUNへはFWを経由しないため特に追加設定は不要。そのため回答から除外
①’：STUNサーバは切り替え２によって追加された機器。そしてブラウザ２（内部）から新設されたSTUNに行くにはFWを経由する必要がある。つまりFWの設定を変更する必要があるので回答に記載
②：Webサーバを使った通信。これは既存環境と同じなので特に追加設定は不要。そのため回答から除外
③：社内から外についてのUDPポートを許可する設定が必要。WebRTCではP2P通信をしたいので固定されたポートではなく、その都度ユーザ間で動的にポートが決定される。そのため、その動的なポートを許可する設定を追加する必要がある。
④：③と同様の理由。動的ポートを許可する設定を追加する必要がある。
以上より「切り替え２で許可する通信」は①’,③,④となる。

p.3 マルチホーミング
Q.マルチホーミングを有効にするための前準備…
A.外部との接続点を増やせば勝手に冗長化できるわけではない。DNS設定の変更や各サービスに複数のIPアドレスを割り当てたりしたりといろいろとやることがある。
落とし穴１：例えば、自社のDNSサーバのAレコードにhttps://example.comに対するIPアドレスを異なるISPから割り当てられたIPアドレスを登録しただけではマルチホームにならない。
しっかりと自社DNSサーバ自体にも複数のIPアドレスを割り当てなければならない。なぜなら既存契約のISPに障害があればそもそもDNSサーバに名前解決要求が届かずhttps://example.comに設定した２つのAレコードが提供できないから。
落とし穴２：また、自社DNSサーバ自体に複数のAレコードを追加するだけでもマルチホームにはならない。その自社DNSサーバの上位DNSサーバの、グルーレコードとして、既存のDNSサーバIPだけでなく新規ISPから割り当てられたIPアドレスも登録しておく必要がある。これにより、マルチホームできるようになる。

Q.DNSの流れ　https://example.comの名前解決の流れ
１．クライアントが当該サイトhttps://example.com/test.phpを開こうとする
２．まずは「.（ルート）」に、「example.com」を管理しているDNSサーバのFQDNを聞く
３．ルートが.comを管理しているDNSサーバのFQDN（NSレコード）とグルーレコード（≒Aレコード）をくれる
４．３のAレコードのIPアドレスをもとに.com権威DNSサーバに「example.com.」のを管理しているDNSサーバのFQDNを聞きに行く
５．com.権威DNSサーバがexmaple.com.の権威DNSサーバのFQDN（NSレコード）とIPアドレス（グル－レコード）を返してくれる
６．example.com.の権威DNSサーバが分かったので、そのDNSサーバにexample.com.のIPアドレス＝サービスを提供しているWebサーバのIPアドレスを教えてくださいと要求
７．example.com.権威DNSサーバがexample.com.のAレコードを教えてくれる
８．クライアントは7をもとに、Webサーバへアクセスする

p.3 表１　ip1/29　
このアドレス空間で使えるIPアドレスの個数は32-29=3 2^3=8 ネットワークアドレスとブロードキャストアドレスの２つを引くと8-2＝６　つまり6個のアドレスが使えることになる

p.4 NAT
NATには複数の種類がある。
１．SNAT(Source NAT):送信元を書き換える。主に内から外の通信に使われる。
２．DNAT(Destination NAT):宛先を書き換える。主に外から内の通信に使われる。
３．静的NAT(Static NAT):変換前IPと変換後IPを１対１の固定する。これにより外から内への通信もスムーズにさせる。
５．動的NAT(Dynamic NAT):プールされたIPアドレスから、その都度割り当てる。。そのため外から内へ始まる通信には不向き。

p.4 FWのDNSラウンドロビン機能
Webサービスのドメインに対応するIPアドレスを負荷分散対象先となるWebサーバの複数IPアドレスに対応づけた複数のAレコードを準備する。それをDNS要求のたびに順番に返していくことで負荷が分散される

p.4 負荷分散装置（以下、LBという）があり、この装置は負荷分散機能のほかにDNS機能～
LBのDNS機能：LBが死活監視をして死んでいる回線があれば、それに付随するDNSレコードを返さないようにするといった動的な制御が可能になる

p.5 STUN
自分が外部と通信しているときに、NATで変換された後の送信元IPアドレス＆送信元ポート番号を知ることができる
*不随としてステートフルインスペクション、ホールパンチング、フルコーンNTA、TURNも頻出する

*ステートフルインスペクション：自分→外への通信の戻りパケットしか受け取らない仕組み。つまり、外から始まる通信は拒否される。なお、ステートフルインスペクションには２つの手法（フルコーンNATと制限型コーンNAT）がある。

*フルコーンNAT：一言でいうと制限がガバガバなやつ。１度、内から外に出たポート番号あてに、外部から通信がきたらそれを許可する。つまり判断基準がポート番号のみ。

*シンメトリックNAT：宛先ごとに異なるポート番号を使うNAT。そのためSTUNとの相性は悪い。STUNで得たIPアドレスとポート番号は、あくまでもSTUN宛の情報。異なる宛先には異なるポート番号を使うので、ホールパンチングを実行しても実際に相手と使うポート番号は違うので、ステートフルインスペクションに引っかかってしまい通信ができなくなる。

*ホールパンチング：ステートフルインスペクションの対策として、あらかじめ相手側に通信を図りルータに内から外の通信として記憶させる。そうすれば、相手側からきた通信を許可できるようになる。
なお、最初のホールパンチングの通信は相手にブロックされても問題ない。あくまでも自分側の機器がその相手と通信したよという情報を記憶できればブロックされても問題ない。

*TURN:シンメトリックNATの場合、ホールパンチングは不発に終わる。その解決策を提供するのがTURN。仕組みとしては、あらかじめ双方の端末からTURNサーバとセッションを作っておく。TURNはそのセッションを使い双方の中継処理をする。そうすれば、相手側のポート番号が動的に変わってもTURNでそれを吸収できる。手順↓
　１．クライアントはTURNサーバにIPアドレスとポートの払い出しを求める
　２．TURNから配られたIP、ポートをSIPなどの内部情報に登録して使う
　３．２で得た情報をお互いが把握して、お互いがTURNサーバ宛てに送信する
　４．TURNがセッション情報から適切なクライアントにパケットを振り分ける。
つまり、クライアントはお互いの実際のIPアドレスは知らないし、知る必要もないということ。なので、シンメトリックでポートが不安定な環境でもTURNを挟めば安定して通信ができるようになる

p.5 STUNサーバはNATより外側に配置しないと意味ないのでは？でもA社は内側にある。どうやってグローバルIPとポート番号知るの？
A.STUNサーバにグローバルIPアドレスを割り当てる。それに対してクライアントがリクエストを送れば、STUNサーバ自体が内部にあっても、トラフィックの流れとしてはNATを越えることができる。なので、STUNサーバ自体が内側に配置されていも機能する仕組みになっている。
また、設問の図をみるとNATよりも内側に見えるが読み進めていくと、STUNサーバの接続先はL2SW1とL2SW2であることが分かる。つまり、実質NATよりも外側に配置されていることになる。

p.5 ISP2を経由してもそのDNS機能を提供できるように、ドメイン登録事業者に定義の追加を依頼する。
A社のDNSサーバとして、現状のISP１のIPアドレスと新規のISP２のIPアドレスを割り当てる。しかし、そのままだと新規のISP２のIPアドレスには届かない。なので、上位ドメイン登録事業者に、A社のDNSサーバのFQDNに対するAレコードとしてISP２のIPアドレスも登録する。そうすれば、ISP１に障害が起きてもA社のDNS名前解決機能は維持し続けるのでユーザからの通信も維持することができる。

p.6 WebRTC
ユーザのブラウザ同士が、データ通信においてサーバなどを挟まずに直接P2Pビデオ通話や音声通話をする技術。
今まではYouTubeなどのように、YouTubeサーバに動画などの情報を取りに行っていた。しかし、WebRTCであれば、最初のきっかけはWebサーバなどを使うが実際のデータ通信はユーザ同士で直接やり取りする。これにより、回線負荷やサーバ負荷を抑えることができる。

p.6 APをダウンロードしたブラウザ
「URLを開いて、プログラムのコードをブラウザのメモリ上に読み込んだ状態」のことを、いっちょまえに「APをダウンロードした」と表現しているだけ。
WebRTC以前は、専用の .exe をダウンロードしてインストールしたり、ブラウザのプラグイン（拡張機能）をインストールしなければならなかった。でも、WebRTCではURLを開けば簡単に利用できますよ！というのを強調したいがための表現。

p.7 ホールパンチ：ステートフルインスペクションの対策として、あらかじめ相手側に通信を図りルータに内から外の通信として記憶させる。そうすれば、相手側からきた通信を許可できるようになる。
なお、最初のホールパンチングの通信は相手にブロックされても問題ない。あくまでも自分側の機器がその相手と通信したよという情報を記憶できればブロックされても問題ない。

p.7② 取得したIPアドレスとブラウザ自身のIPアドレスを通信相手のAPへ通知する
Q.なんで、ブラウザ自身のIPアドレスも通知するの？グローバルIPアドレスだけで十分じゃない？
A.「通信相手が、同じ会社の同じ部屋（同じLAN内）にいるかもしれないから」。同じLANにいる場合はわざわざNATを越えたりする必要がないので、最適経路でやりたいよね！ということでプライベートIPアドレスも通知している。

p.7 ③通信相手との通信を試み、相互に通信が成功した場合に、その宛先IPアドレスの組み合わせを最適ルートとする
Q.プライベートIPアドレスは異なる会社でも重複して使うことができる。そのため、社外との通信だが同じプライベートIPアドレスをもつ社内の無関係の人と通信してしまう可能性があるのではないか？
A.SDPオブジェクトの交換時に、実は使い捨てのIDやパスワードなどを設定している。そのためプライベートIPアドレスの重複がおきてもID、パスワードなどの整合性がとれないと通信を確立することができない。そうなれば自ずとグローバルIPのほうを採用すればいいよねという流れになる。

p.8 IP-PBX
Q.IP-PBXってそもそもなに？
A.IP-PBXとは、通話を実装するための機器。そもそもPBXとは、外線と内線を収容したりする機器。それにIPの機能、つまりVoIPゲートウェイの機能が付加されたものがIP-PBX。これにより、内線同士の通話、外線と内線の通話、電話網とIP網での通話など、さまざまな種類の通話をサポートすることができる。

p.8 HTTP GET Upgrade:websocket
HTTPで行っている通信をWebSocketに切り替えたいです！という要求メッセージ。もし、相手側がそれを承諾するなら101 Switching Protocolsを返す。

p.9 B2BUA（Back-toBack User Agent）
ユーザ同士のP2P通信ではなく、間に仲介役を挟む方式。これをすることで、ユーザは相手側のユーザIPは仲介役のIPになる。そのためP２Pのような直接通信じゃなくなる。逆をいえばユーザはSTUNやTURNをつかって自分のグローバルIPを通知する必要がなくなる。なぜならB2BUAが変換してくれるから。

• 「Create a New Virtual Machine」 → Typical を選択
• インストーラー ISO を指定（Ubuntu Server）
• OS を Linux → Ubuntu 64-bit
• VM 名を設定（例：UbuntuSyslog）
• ディスクサイズを指定（例：20GB）
• ディスクを複数ファイルに分割を選択

2️⃣ Ubuntu インストール開始

• 仮想マシンの電源を入れると ISO が起動
• 「Try or Install Ubuntu Server」を選択
• キーボード設定
  • Layout：Japanese
  • Variant：Japanese（標準）
• インストールタイプ
  • Ubuntu Server（標準）を選択

3️⃣ ネットワーク設定

• ネットワークコンフィギュレーション画面は DHCP 自動取得でOK
• IP が自動で割り当てられる（例：192.168.x.x）

4️⃣ ミラー・プロキシの設定

• Ubuntu Archive Mirror → そのまま空欄で Done
• Proxy → そのまま空欄で Done
• 迷ったら「CONTINUE」を押して次へ進む

5️⃣ ディスク・ストレージ設定

• Guided Storage Configuration で Use an Entire Disk を選択
• パーティションや LVM、暗号化は不要
• サマリー画面で Done を押す

6️⃣ ユーザー作成

• Your name（フルネーム）を入力
• Server name（ホスト名）を入力
• Username（ログインユーザー名）を入力
• Password / Confirm Password を入力

7️⃣ Ubuntu Pro はスキップ

• Enable Ubuntu Pro → Skip for Now

8️⃣ SSH サーバのインストール

• Install OpenSSH server に チェックを入れる
• Import SSH keys → 何もせずスキップ

9️⃣ インストール実行

• Installing system 画面で自動インストール開始
• インストール完了後に Reboot Now で再起動

10 再起動後

• 設定したユーザー名・パスワードでログイン
• IP を確認して GNS3 の Cloud で接続すれば Syslog やウェブサーバなどのサービスを構築可能

Failed Unmounting CDROM…Please Remove the Installation Medium, Then Press Enter

1. Failed Unmounting CDROM…
   • Ubuntu インストーラーが ISO イメージをアンマウント（取り外す）ときに失敗したメッセージ
   • 仮想マシンの仮想 CD/DVD ドライブがまだ接続されている場合に出ます
   • システム自体はインストール済みで問題なし
2. Please Remove the Installation Medium, Then Press Enter
   • 「インストール用 ISO（CD/DVD）を取り外して、Enter を押してね」という意味
   • VMware 上では CD/DVD（ISO）を切断すれば OK

🔹 解決手順（VMware 側）

1. 仮想マシンのウィンドウで VM → Settings → CD/DVD (IDE) を開く
2. 「Use ISO image file」が選択されていたら、
   「Disconnected」 または 「Remove」 にチェック
3. 設定を保存して Enter を押す

これでメッセージは消え、Ubuntu が正常に起動します。

11 VMware VM を不要になったら

• Delete from Disk で削除すれば、ディスク容量も解放される
• Remove from Library だとファイルは残る

💡 ポイントまとめ

• この手順は Syslog でもウェブサーバでもほぼ同じ
• 違うのは インストールするアプリ（rsyslog / Apache / Nginx など）だけ
• 役割ごとに新規 VM を作ると学習しやすい

✳️ステップ1：VMwareとGNS3をつなぐ

VMwareのUbuntuには NICを2枚つけましょう

VMware設定手順

1. VMwareで Ubuntu VM を選択
2. 設定（Settings）
3. Network Adapter を 2枚追加（合計2つ）
4. それぞれ以下に設定：

• Network Adapter 1 → NAT
• Network Adapter 2 → Host-only

Ubuntu側で確認

Ubuntuを起動してターミナルで：

ip a

NICが2つ見えればOK！

例：

• ens33 → NAT側でIP取得
• ens38 → Host-only側（例：192.168.56.x）

※名前はPC環境で違います

✳️ステップ2：GNS3上でUbuntuを追加

クラウドを追加するパターン

1. Ubuntは１枚目をNAT（adapter8）にする
2. ip aでアドレスを確認
3. クラウドを配置→adapter8を設定する
4. ルータにadapter8と同じサブネットのIPアドレスを設定
5. ping で確認するとhostonlyで接続するよりも高速にpingが通る

GNS3に VMwareのUbuntu VM を追加します。

1. GNS3の上部メニュー
   • [Preferences] → [VMware VMs]
2. “Add”
3. Ubuntu を選択
4. 詳細設定で「ネットワークタブ」→「NIC数」→２枚を選択
   NIC数が１つだと競合しちゃう
   Error! While creating link, attachment NAT is already configured on Network Adapter 0. Please remove it, or allow VMware VM ovens PC senior to use any adapter.

その後、UbuntuをTopologyへドラッグ✔️
IOSvルータとケーブルで接続✔️

✳️ステップ3：Ubuntu ↔ ルータ の疎通確認

Ubuntu側の Host-only NIC にIP設定：

sudo ip addr add 192.168.2.100/24 dev ens38
sudo ip link set ens38 up

お互いに ping で確認：

👍 通ったら次へ！

１．クラウドをセット（ローカル）

２．VMnet８を追加

３．イーサネットをそこに接続（ルータのインタフェースはNAT側のIPに合わせる）

４．スタティックルーティングを設定する

５pingで疎通。これで、サーバとルータが通信可能！

PCとしてUbuntuを動作させる

１．NICのHostOnlyを１枚目とする

２．GNS3でVMnet1を追加

３. ルータのIPアドレスをVMnet1に合わせる

デフォルトゲートウェイ設定（永続）

１．ネットワーク設定ファイルを開く

sudo nano /etc/netplan/00-installer-config.yaml

２．設定の作成
　＊値の前の半角スペースやインテンドのズレも忘れずに！これをやらないとエラーになる

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      dhcp4: no
      addresses:
        - 192.168.111.111/24
      routes:
        - to: default
          via: 192.168.111.1
      nameservers:
        addresses: [8.8.8.8]

３．保存後：
　権限を狭める。（やらないとtoo openエラーになる。）
　netplanの適用

#権限を狭める
sudo chmod 600 /etc/netplan/00-installer-config.yaml

#netplanの適用
sudo netplan apply

デフォルトゲートウェイ設定（暫定）

sudo ip route add default via 192.168.1.1

コマンドプロンプトからSSH接続

UbuntuのCLIはコピーできないので、ローカルのcmdからSSH接続すれば、エラーログなどをコピーできる！

１．Ubuntsサーバ側でユーザを作成

sudo adduser ユーザー名

２．sudo権限の付与

sudo usermod -aG sudo ユーザー名

３．CMDからSSHログイン

ssh testuser@IPアドレス

４．ルートに移行

sudo -i

GNS3のルータにSSHで接続する

CMLライセンスだと古いルータしか使えないことがある。それだと、SSHの設定で不具合が起きてしまう。それを解消しながらルータに接続するコマンドが以下です。

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 \
    -o HostKeyAlgorithms=+ssh-rsa \
    ホスト名@IPアドレス
    
    
ssh-keygen -f '/home/sumika/.ssh/known_hosts' -R '192.168.6.254'
↑古いSSHキーを削除。同じIPに対して違う鍵を使おうとするとエラーになるのでその場合は古い鍵を削除する

SSHで接続しただけではenableモードには入れないのでルータ側であらかじめイネーブルパスワードを作成しておく

enable secret パスワード
↑これで、SSH後にenableモードに入ることができる

🛣️ 共通イメージ：「1本の道路（TCP接続）」と「トラック（HTTPリクエスト）」

• 道路（トンネル）：TCP接続
• トラック：HTTPリクエスト・レスポンス
• 荷物の色分け（赤・青・緑）：HTTP/2以降のストリームID（リクエスト識別）

🚗 HTTP/1.0：

「トラック1台ずつしかトンネルに入れない」

イメージ

┌───────────────┐
│ トンネル(TCP) │
└───────────────┘
   🚚(リクエスト1)
   ↑出たら閉じる
   🚚(リクエスト2)
   ↑出たらまた閉じる

説明

• リクエストごとにTCP接続を新規に作る。
• 1ページに画像が10個あれば、10回トンネルを掘る（＝10回TCP確立）。
• → トンネル掘る（3ウェイハンドシェイク）だけで時間がかかる。

問題点

• 接続確立コストが大きい
• 同時に1つのリクエストしか送れない

🚚 HTTP/1.1（Persistent Connection）：

「トンネルは1本のまま、トラックを何台も順番に通せるようになった」

イメージ

┌───────────────┐
│ トンネル(TCP) │
└───────────────┘
   🚚(リクエスト1)
   🚚(リクエスト2)
   🚚(リクエスト3)
   …

説明

• 一度トンネルを掘ったら（TCP接続確立したら）、閉じずに使い回す（Keep-Alive）。
• これでTCPの確立コストが削減。

でも問題発生：ヘッドオブラインブロッキング（HOLB）

• トラック（リクエスト）は1台ずつ順番にしか通れない。
• 先頭のトラックが渋滞（応答遅延）すると、後ろのトラックも動けない。
• これがHTTP/1.1のHOLB問題。

🚚(画像1:遅い)
🚚(画像2:早いけど待ち)
🚚(画像3:早いけど待ち)

🚛 HTTP/2（マルチプレクシング）：

「1本のトンネルの中で、トラックに色を付けて、混在して走らせる！」

イメージ

┌──────────────────┐
│ トンネル(TCP)   │
│ 🚚赤🚛青🚚赤🚜緑🚚青🚜緑 │ ← 順番に混ざって流れる
└──────────────────┘

説明

• トラック（HTTPリクエスト）をフレーム単位に細かく分ける。
• それぞれに「ストリームID（色）」を付ける。
• 同じトンネル内で、赤・青・緑のトラック（データ）を交互に流せる。

→ アプリ層的には「複数リクエストを同時に処理できる」ように見える！

しかし…

• トンネル（TCP）は1本。
• もしトンネル内で1つのパケットが落ちると、後続のデータが全部ストップ。
  → これがTCPレベルのHOLB。

🚚赤[欠損]🚛青🚜緑 → 青と緑は来てるけど、赤が復旧するまで渡せない

🚀 HTTP/3（QUIC：UDPベース）：

「トンネルをやめて、それぞれが自分専用のレーンを持つ」

イメージ

🚚赤 ────────────→
🚛青 ───────→
🚜緑 ─────────────→

説明

• TCPではなくUDP＋QUICを使う。
• QUICでは、ストリームごとに独立した再送制御ができる。
• 赤のトラックが事故っても、青と緑は自分のレーンで進める。

→ TCP時代のHOLB問題を完全に解消！

💡 まとめ表

🎯 重要ポイント（ネスペ試験で狙われる）

1. HTTP/1.1のHOLB問題
   • 1つのTCP接続上でリクエストを順次送るため、先頭の応答遅延が全体に影響する。
2. HTTP/2の改善
   • マルチプレクシングにより、論理的には並列化できるが、TCPの順序制御が根本的に残る。
3. HTTP/3の最終解決
   • UDPベースのQUICで、ストリームごとの独立再送を実現。真の並列処理が可能。

• HTTP/1.0：トンネルを毎回掘ってトラックを1台ずつ通す
• HTTP/1.1：トンネルは共通だが、トラックは順番待ち
• HTTP/2：トンネル内で色分けして混ぜて走らせる
• HTTP/3：トンネルをやめて、色ごとに独立した道路を持たせる

✅ TLS 1.2 における RSA方式の鍵交換の流れ

▼ 1. クライアント Hello

• クライアントはまず、サーバに「ClientHello」メッセージを送る。
• ここには以下が含まれる：
  • サポートするTLSのバージョン
  • サポートする暗号スイート（例：RSA、AESなど）
  • 乱数（クライアントランダム）
  • その他オプション情報

▲ 2. サーバ Hello

• サーバは「ServerHello」メッセージで応答する。
• サーバの選択した：
  • TLSバージョン
  • 暗号スイート
  • サーバの乱数（サーバランダム）

▲ 3. サーバ証明書の送信

• サーバは自分の公開鍵証明書（X.509証明書）をクライアントに送信。
  • 証明書の中に、サーバのRSA公開鍵が入っている。
  • 証明書は認証局（CA）によって署名されていて、クライアントはその正当性を検証する。

▼ 4. クライアントが Pre-Master Secret を生成

• クライアントは、ランダムなPre-Master Secret（48バイトのランダム値）を生成。
• そして、そのPre-Master Secretをサーバの公開鍵でRSA暗号化する。

▼ 5. クライアントキー交換

• 暗号化されたPre-Master Secretを「ClientKeyExchange」メッセージとしてサーバに送信。

▲ 6. サーバが Pre-Master Secret を復号

• サーバは自分のRSA秘密鍵で復号し、Pre-Master Secretを得る。

▼▲ 7. 共通鍵の生成

• クライアントとサーバはそれぞれ、以下の情報から同じ共通鍵（セッション鍵）を導出：
  • Pre-Master Secret
  • クライアントランダム
  • サーバランダム
• これにより、共通の暗号鍵・MAC鍵などが生成される。

この3つの値を材料として、TLS 1.2では：

マスターシークレット = PRF(Pre-Master Secret, "master secret", ClientRandom + ServerRandom)

という手順でマスターシークレットが生成されます。

さらにこのマスターシークレットから、

セッション鍵（共通鍵） = PRF(Master Secret, "key expansion", ServerRandom + ClientRandom)

のようにして、実際に通信に使う暗号鍵・MAC鍵などが生成されます。
※この際の"master secret"や"key expansion"は固定の文字列で、どの用途の鍵を作るのか区別するために使われます。

✅【PRFとは】

• Pseudo-Random Function（擬似乱数生成関数）
• TLSの仕様の中で、「こういうアルゴリズムで計算しなさい」と定義されています。
• TLS1.2では**HMAC（SHA-256などのハッシュ関数）**をベースに実装されています。

▼▲ 8. Finished メッセージで確認

• その後、クライアントとサーバは、共通鍵を使って「Finished」メッセージを交換し、お互いに正しい鍵が共有できたことを確認。

✅ 【まとめ図】

1. ClientHello (クライアント乱数 + 暗号スイート)
2. ServerHello (サーバ乱数 + 暗号スイート選択)
3. サーバ証明書 (RSA公開鍵含む)
4. Pre-Master Secret 生成
5. Pre-Master Secret を公開鍵で暗号化し送信
6. サーバが秘密鍵で復号
7. Pre-Master Secret + 両者の乱数 → 共通鍵
8. Finishedメッセージ交換 → 暗号通信開始

✅ 【ポイント】

• クライアントだけがPre-Master Secretを生成する。
• サーバは復号するだけで、自分では鍵は作らない。
• Pre-Master Secretと乱数2つから鍵素材（共通鍵）ができる。
• RSA方式はサーバ秘密鍵が漏れると過去のPre-Master Secretも解読できるためForward Secrecyが無い。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

✅【TLS 1.2 における DHE 鍵交換の流れ】

✅【前提：DHEとは】

• DHE（Ephemeral Diffie-Hellman）は、セッションごとに一時的な鍵（エフェメラル鍵）を使って共通鍵を生成する仕組み。
• Forward Secrecy（前方秘匿性）があり、もしサーバの秘密鍵が漏れても過去の通信は解読されない。

🔵 ① クライアント Hello

• クライアントはClientHelloをサーバに送信。
• そこに：
  • サポートする暗号スイート（例：TLS_DHE_RSA_WITH_AES_128_CBC_SHA など）
  • TLSのバージョン
  • クライアントのランダム値（クライアントランダム）
    などを含める。

🌑② サーバ Hello

• サーバはServerHelloを返し、
  • 選択した暗号スイート（ここではDHEを含むもの）
  • TLSバージョン
  • サーバランダム
    を送る。

🌑③ サーバ証明書の送信

• サーバは、自身の公開鍵証明書（X.509証明書）を送信。
• 証明書にはRSAの公開鍵などが入っていて、「サーバの正当性確認のため」に使われる。
• （DHEでは、このRSA鍵で署名するために使う）

🌑④ サーバのDHEパラメータ送信（ServerKeyExchange）

• サーバは以下の情報を送信：
  • p（素数）
  • g（生成元）
  • サーバのDHE公開値：g^b mod p（bはサーバの秘密値）
  • これらに対するRSA署名（サーバ証明書の秘密鍵で署名）

こうすることで、「このDHEパラメータは正当なサーバが送ったものだよ」と証明している。

🔵 ⑤ クライアントのDHEパラメータ送信

• クライアントは、ランダムな秘密値aを選び、
  • クライアントの公開値：g^a mod p
    を計算し、ClientKeyExchangeメッセージでサーバに送る。

🔵🌑 ⑥ 双方が共通鍵素材（Pre-Master Secret）を計算

• クライアント側：

(g^b mod p)^a mod p
= g^(ab) mod p

• サーバ側：

(g^a mod p)^b mod p
= g^(ab) mod p

→ クライアントとサーバが同じ値（g^(ab) mod p）を得る。これがPre-Master Secretになる。

🔵🌑 ⑦ Pre-Master Secret + ランダム値 → 共通鍵生成

• 双方はPre-Master Secretと
  • クライアントランダム
  • サーバランダム
    をPRF関数に入れて、マスターシークレットを生成。
• さらにマスターシークレットから、セッション鍵（共通鍵）が計算される。

🔵🌑 ⑧ Finished メッセージ交換

• 共通鍵を用いて、Finishedメッセージを暗号化して交換。
• お互いの鍵が一致していれば復号が成功し、ここから安全な通信が始まる。

✅【まとめ図】

1. ClientHello（クライアントランダム、対応暗号スイート）
2. ServerHello（サーバランダム、選択暗号スイート）
3. Certificate（サーバの証明書）
4. ServerKeyExchange（p, g, g^b mod p, 署名）
5. ClientKeyExchange（g^a mod p）
6. 両者で g^(ab) mod p を計算 → Pre-Master Secret
7. Pre-Master Secret + ランダム2種 → PRF → マスターシークレット
8. マスターシークレット → 共通鍵（セッション鍵）
9. Finishedメッセージ交換

• RSA方式と違い、Pre-Master Secretは両者が計算で得る。
• サーバ証明書のRSA鍵は「署名検証」のみで、暗号化には使わない。
• Forward Secrecyあり（秘密鍵が漏れてもg^bが漏れない限り安全）