令和5年（2023年）ネスペ午後Ⅰ　問Ⅲ　解答解説

2026.10.07

設問２
1. （２）Subject
設問５

設問２

（２）Subject

Subjectは、証明書の「この証明書の所有者は誰か」を記述する、伝統的・基本的なフィールド。

Hjson

Subject: CN=example.com, O=Example Inc, C=US

CN(Common Name): 証明書の主体者名(かつては、ここにドメイン名を書くのが標準的なやり方でした)
O(Organization): 組織名
C(Country): 国名

一方、似た概念としてSANフィールドがある。SANは、「Subjectを”補足・拡張”するための、追加のフィールド」として、後から規格に追加されたもの。

Hjson

Subject Alternative Name:
  DNS:example.com
  DNS:www.example.com
  DNS:mail.example.com
  
・複数のドメイン名、IPアドレス、メールアドレスなど、「同じ証明書が有効とみなされる複数の対象」を列挙できるフィールド
・名前の通り、「Subjectの代替(Alternative)」という位置づけで、元々は「Subjectで表現しきれない、追加の識別情報を補う」ためのもの

設問５

（２）経路数：４　コスト：70

経路：４
　これはL3SW11から想定しうる経路を数えると４になる

コスト：70
　コストが加算されるタイミングは、当該インタフェースから送出されるタイミングである。つまり、L3SW11から送出されるときに＋50、L3SW31から送出されるときに＋20。つまり、50+20=70となる。
　途中にL3SW31とL2SW34の間に50と記されているが、それはL3SW31側のコストである。そしてコストは送出されるタイミングで加算されるが、ここでは受信として使われているだけなので加算の対象外となる。

p.2 Q.M社広域イーサネットまでの物理的構成はどうなっているの？

ここでは、本社L3SW11とM社広域イーサネットの区間（赤色の部分）の物理構成がどうなっているのかを見ていく。以下のイラストを参考にしつつやっていこう！では、出発進行！

ステップ1：本社での送信とMDFへの集約

L3スイッチとSFP+モジュール:
本社の業務端末やVDIからのパケットは、本社のL3スイッチ（L3SW11など）で処理される。
L3スイッチのポートに挿さったSFP+モジュールによって、内部の電気信号が光信号に変換される。
＊SFP/SFP＋モジュール(Small Form-factor Pluggable)：電気信号と光信号を相互に変換する機器。
MDF（主配線盤）の経由:
変換された光信号は、光ファイバーパッチケーブルを通ってビルの地下などにあるMDF室に集約され、ビル内の配線から外部への引き込み口へと繋がる
＊MDF(Main Distribution Frame):外部の光ファイバケーブルと内部の光ファイバケーブルの集約点。事業者ではなくビルの所有者側が準備する。光だけでなく電話線なども収容する
内部の光ファイバと外部のNTTファイルは太さが異なる。それを人間の手で溶かしたりして接続する。その接続したものを格納する箱がODFであり、それを収容しているのがMDF。

ステップ2：NTTアクセス網と局舎の通過（本社側）

地下管路からNTT局舎へ:
本社ビルの地下から出た光ファイバーは、道路の地下管路を通って最寄りのNTTの局舎へ到達する。
＊NTT局舎：全国数千か所に渡って設置されている。ネットワークの中継ポイント
NTT局舎でのハードウェア・スルー（中身を見ない転送）:
NTTの局舎（ODFやアクセス回線終端装置）では、パケットの中身（IPアドレスなど）は一切見ない。「この物理回線（またはアクセス回線）から入ってきた信号は、あらかじめ契約されたM社用のポートへそのまま流す」という固定的な設定（クロスコネクト）に従い、無条件でキャリアM社のネットワークへ受け渡される。
＊ODF(Optical Distribution Frame)：本社はフロアごとに複数のケーブルを持っている。その複数のケーブルを整理するための箱。ODF内の回路上をデータが通るというよりも、ただ物理的に配線をきれいに整えているだけ

ステップ3：キャリアM社網（POP）でのL2 / MPLS転送

M社収容局（POP）への到着: キャリアM社のPOP（収容局）に届いた信号は、M社のコアネットワーク（MPLS網）に入る。
＊POP(Point of Presence)：NTT局舎と同じ考え方を踏襲した仕組み。M社広域イーサネットの出入口を各地に分散配置しているもの。
MACアドレス・ラベルによる転送:
広域イーサネットは「巨大なL2ネットワーク」として振る舞う。M社側の装置は、フレームの宛先MACアドレスや内部のMPLSラベルを確認し、「このフレームはデータセンター側（対向拠点）へ向かうべきものだ」と判断して、対向拠点宛てのパス（MPLSトンネル）に載せて高速に転送する。

ステップ4：データセンター側NTT局舎・アクセス網の通過

対向側のNTT局舎への到着:
M社網を通過したデータは、データセンター側の最寄りにあるNTT局舎へ届けられる。
局舎からデータセンターMDFへ:
本社側と同様に、NTT局舎側でも「M社が借り受けている回線から来たもの」として、物理的・論理的な経路に従ってデータセンターのビルへ送り出される。

ステップ5：データセンターでの受信とサーバーへの到達

データセンターMDFからL3スイッチへ:
データセンタービルの地下やMDF室に届いた光信号は、光配線盤（ODF）やMDFを経由し、データセンター側のL3スイッチ（L3SW31など）に到達する。
電気信号への変換とサーバーへの配信:
L3スイッチのSFP+モジュールによって光信号から電気信号へ再変換され、最終的にルーティング処理を経て目的のVDIサーバーや業務サーバーへとデータが届けられる。

Q.SSL-VPNのリバースプロキシ方式って何？

では、リバースプロキシ方式のフローとともに理解を深めていこう！

ステップ1：クライアントとSSL-VPN装置（リバースプロキシ）間のTLS確立

HTTPSアクセス開始
自宅の個人PCから、ブラウザでSSL-VPN装置の持つ公開IP（またはドメイン）宛てにアクセスする（例: https://vpn.k-company.co.jp/ vpn.k-company.co.jp(https://vpn.k-company.co.jp/)）。
TLSハンドシェイクの実行
ここでクライアントとSSL-VPN装置の間で、しっかりとTLSハンドシェイクが行われる
- サーバ証明書がクライアントに送られ、正当性が検証される。
- 共通鍵（セッションキー）の交換が行われる。
安全な暗号化トンネル（セッション）の成立
これにより、自宅PCからSSL-VPN装置までのインターネット上の区間は、強固に暗号化された状態で通信できるようになる。

ステップ2：リバースプロキシ（SSL-VPN装置）による代理処理と変換

リクエストの復号と解析
SSL-VPN装置に届いた暗号化パケットを、装置自身が持っている秘密鍵で一度復号（中身を読み取る）する。中身のHTTPリクエスト（例：「人事システムのページを見せて」）を取り出し、URLのパスやホスト名を確認する。
社内Webサーバへの転送（ここがポイント）
SSL-VPN装置は、確認した内容をもとに、今度は社内ネットワーク側にある本物のWebサーバに対して、新しくリクエストを作成・送信する。
- ※この「SSL-VPN装置～社内Webサーバ間」は社内クローズドなネットワークなので、そのままの通信（HTTP）であることが多いが、必要に応じてここも社内用TLSで暗号化する場合もある。

ステップ3：レスポンスの返却と再暗号化

社内Webサーバからの応答
社内Webサーバが処理を行い、HTMLなどのレスポンスデータをSSL-VPN装置に返す。
SSL-VPN装置での加工と再暗号化（重要）
SSL-VPN装置は、受け取ったHTML内のリンクや画像のアドレスが社内用のままになっていると、外部からアクセスできなくなるため、URLの書き換え（プロキシ変換）を行う。その後、そのデータをステップ1で確立した暗号化セッション（共通鍵）を使って再び暗号化する。
クライアントへの送信
暗号化されたレスポンスが自宅PCに届き、ブラウザが復号して画面に綺麗にWebページが表示される。

Q.SSL-VPNのポートフォワーディング方式ってなに？

例えば、自宅の個人PCから、データセンタにあるVDIサーバ（RDP：3389番ポート）にアクセスするケースを考えてみよう！

ステップ1：準備と待ち受け（リスニング）

専用クライアントの起動
あらかじめ個人PCにインストールしておいた専用のSSL-VPNクライアントソフトを起動し、会社（SSL-VPN装置）と認証・接続を完了させておく。
ローカルポートのバインド（待ち受け）
専用ソフトは、自分のPC内（127.0.0.1 や localhost）に特定のポート（例：3389番）を勝手に開き、「このポート宛てに通信が来たら、俺が全部キャッチして社内にトンネリングしてやるぜ」という状態で待ち構える。

ステップ2：VDIクライアントからの送信と専用ソフトによるキャッチ

VDIクライアントの動作
ユーザーがVDIの操作ソフト（クライアント）を起動し、接続先として「自分のPCのローカルポート（127.0.0.1:3389）」を指定して接続を開始する。
＊あらかじめローカルポートを作っているので、そのローカルポート宛てにパケットを送る
専用ソフトが横取り（キャッチ）
VDIソフトから送り出されたRDPのパケットは、外に出る前に、裏で待ち構えていた専用のSSL-VPNクライアントソフトにガッチリ捕らえられる。

ステップ3：TLSによるカプセル化とVPN装置への送信

暗号化トンネルでの送信
専用ソフトは、捕まえたRDPパケットを丸ごとTLS（HTTPSと同じ仕組み）でカプセル化（暗号化）し、インターネット上にあるSSL-VPN装置宛てに向けて送信。
＊ここで、ポートフォワーディング用のトンネルが形成される。
＊クライアントソフト側でSSL-VPNのドメインを登録して名前解決できるようにする。そうすることでSSL-VPNのIPアドレスを取得でき、そことTLSトンネルを構築することができる。

ステップ4：SSL-VPN装置での中継と社内サーバへの到達

SSL-VPN装置での復号と転送
インターネットを越えてSSL-VPN装置に届いた暗号化パケットを、装置が復号。中から「VDIサーバ宛てのRDPパケット」が出てくるので、SSL-VPN装置はそれをそのまま社内ネットワーク側（データセンタ）にある本物のVDIサーバへ向けて投げる。
VDIサーバとの通信成立
VDIサーバがパケットを受け取り、応答（レスポンス）を返す。帰りも全く逆のルート（VDIサーバ ⇒ SSL-VPN装置 ⇒ 暗号化 ⇒ クライアントの専用ソフト ⇒ VDIクライアント）をたどることで、自宅の画面に会社の仮想PCが映し出される。
＊戻りパケットがPCに来ると宛先ポート番号を見てOSが「あ、このポートはさっき専用ソフトが使っていたやつなのでそこに流そう」と判断する。そうすると復号して映像を映し出す

Q.SSL-VPNのL2フォワーディング方式ってなに？

では、L2フォワーディングのフローとともに理解していこう！

【ステップ1：接続と仮想NICの作成】

専用ソフトの起動と認証
- 自宅PCで専用のSSL-VPNクライアントソフトを起動し、証明書やID/PWで認証を行い、SSL-VPN装置との間でTLS（またはDTLS）による強固な暗号化トンネルを確立する。
仮想NICの生成とIPアドレスの割り当て
- クライアントソフトが自宅PCのOS内に「仮想のネットワークカード（仮想NIC）」を新しく生み出す。
- そして、その仮想NICに対して、社内ネットワーク（プライベートIP）のIPアドレス（例: 192.168.10.50）がDHCPなどの仕組みで自動的に割り当てられる。
- これにより、自宅PCのOSは「自分は今、会社のLANケーブルに直接繋がっている（同じセグメントにいる）」と錯覚する。
  ▼PCの仮想NICがDHCPを使ってIPアドレスを取得する流れ
  １．PCの仮想NICにMACアドレスを割り当てる
  　会社側で事前に設定して置いたり、仮想NICが動的に生成する場合もある
  ２．DHCP Discoveryの送信
  　宛先を255.255.255.255に設定したパケットを仮想NICから送信
  ３．DHCPリレーエージェント
  　SSL-VPN装置にはDHCPリレーエージェント機能を持たせる。giaddrフィールドにDHCP Discoveryメッセージを受け取ったインタフェースのIPアドレスを入れることでDHCPサーバに適切なプールを判断させることができる。
  ４．OFFER→REQUEST→ACK
  　上記のような流れでDHCPメッセージのやり取りを実施しIPアドレスの払い出しを完了させる

【ステップ2：通信の発生とカプセル化（行き）】

アプリケーションからの通信要求
- ユーザーが社内のファイルサーバー（例: 192.168.10.100）にアクセスしたり、任意のアプリを動かしたりすると、OSは「お、同じ会社のLAN宛てだな」と判断し、そのパケットを仮想NICに向かって投げる。
専用ソフトによるL2/L3パケットの丸ごとカプセル化
- 仮想NICに流れてきたパケット（イーサネットフレームやIPパケット）を、待ち構えていた専用ソフトが丸ごとキャッチする。
- そして、そのパケット全体をTLS（またはUDPベースのDTLS）ですっぽり包み込み（カプセル化し）、インターネット上を流れる通常のIPパケットに変えて、SSL-VPN装置宛てに送信する。
  ＊仮想NICが生成したIPパケットは、ペイロードとして暗号化される

【ステップ3：SSL-VPN装置での終端と社内網への放流】

SSL-VPN装置での復号とL2ブリッジ
- 会社の入口にあるSSL-VPN装置が暗号化パケットを受け取り、復号する。
- 復号されて出てきた中身は「社内LAN宛てのそのままのパケット（L2フレーム/L3パケット）」。
- SSL-VPN装置は、これを社内ネットワーク（実際のスイッチやルーター）へそのまま放り投げる。
  ＊SSL-VPN装置内の仮想インタフェース等を使い適切なルーティングをする
  ▼なぜ仮想インタフェースを使うのか？
  正直、外側IP,内側IP,などを駆使したセッションテーブルを使えば適切なTLSトンネルにパケットを流せる。しかしそれだとセッションテーブルを参照するという、OS本来には存在しないプロセスを挟むことになりコーディング作業を要する。これはバグの原因にもなる。
  なので、仮想インタフェースを使うことでOS本来のルーティングの機能を使って、仮想インタフェースとTLSトンネルを対応づけたほうがより効率よく使用できるという考え方である。

【ステップ4：社内サーバーとの往復（帰り）】

社内サーバーからの応答
- 本物の社内サーバー（192.168.10.100）がパケットを受け取り、処理結果を返す。宛先は「自宅PCの仮想IP（192.168.10.50）」。
SSL-VPN装置による再カプセル化と返送
- 社内から戻ってきたパケットをSSL-VPN装置がキャッチし、再びTLSで暗号化して、インターネットを逆向きに通して自宅PCの専用ソフトへ送り返す。
  ＊SSL-VPN装置に届くと宛先仮想IPから適切な仮想インタフェースへルーティングされ適切なTLSトンネルへ流される
仮想NICを経由してアプリへ到達
- 自宅PCの専用ソフトが受け取って復号し、仮想NIC経由で元のアプリケーションにデータを渡すことで、手元で社内ファイルや画面が正常に動作する。

p.4 AEADってなに？

AEAD(Authenticasted Encryption with Associated Data)とは「機密性（見られない）」と「完全性・認証（改ざんされていないこと、送信者が正しいこと）」を、1つのアルゴリズムの中で同時に計算・処理する仕組み。

Q.RDPってなに？

RDP(Remote Desktop Protocol)とは、その名の通り、リモートにあるPCのデスクトップを、手元の端末から操作できるようにするプロトコル。TCPの3389番ポート(および、パフォーマンス向上のためUDPの3389番ポートも使われます)を使って通信する。
仕組みとしては、
①まずクライアント側で行った、キーボード入力やマウスの操作情報が、サーバー側(操作される側のPC)へ送信される。
②サーバー側は、その操作を実際に処理した結果、画面上に生じた変化(どの部分がどう変わったか)を検出し、画面全体の画像を毎回丸ごと送るのではなく、”変化があった部分の差分情報”だけを、効率的な形式(グラフィックスの描画命令やビットマップの差分など)にエンコードして、クライアントに送り返す
③クライアントは、受け取った差分情報を使って、自分の画面上の該当箇所だけを更新することで、あたかもリモートのデスクトップを直接操作しているかのような体験を実現する。

▼RDPのフロー

操作を送る（手元 ➔ リモート）：
- あなたが「マウスを動かした」「キーボードで文字を打った」という操作情報が、RDPのパケットのペイロードに乗せてリモートPCに飛ぶ。
画面を送る（リモート ➔ 手元）：
- リモートPC側で「画面のここをこういう色に書き換えて」「このウインドウを表示して」という描画データや圧縮された画像データが作られ、RDPのパケットのペイロードに乗せて手元に飛ぶ。
ヘッダーの仕事：
- そのパケットが「画面描画用」なのか「音声用」なのか「ファイル転送用」なのかをヘッダーの管理コードで仕分けし、手元のアプリが正しく画像としてデコード（復元）して画面に映し出す。

Q.RSA鍵交換方式とDH公開鍵方式がダメな理由は？

TLSハンドシェイクにおいて「RSA鍵交換方式」と「DH公開鍵方式を静的に用いる方式」は前方秘匿性が確保されないとよく耳にする。これはいったい何なのか。。。
実はこれら２つの方式は長期的に秘密鍵と公開鍵が変化しない。そのため、１回でも秘密鍵が漏洩すると簡単にプレマスターシークレットを生成される。結果として、共通鍵もばれてしまい過去の通信がすべて復号されてしまう。

TLS 1.2 と TLS 1.3 の鍵交換方式の比較表

方式のグループ	主な方式名	TLS 1.2での扱い	TLS 1.3での扱い	前方秘匿性	廃止・使えなくなった理由など
静的・RSA方式（TLS 1.3で廃止）	RSA鍵交換方式	利用可能	利用不可（廃止）	なし	サーバーの秘密鍵が漏洩すると、過去のプレマスターシークレットが直接復号され、全通信が破られるため。
	静的Diffie-Hellman（Static DH / Static ECDH）	利用可能	利用不可（廃止）	なし	固定のDH秘密鍵が漏洩すると、過去の公開鍵と組み合わせて当時のプレマスターシークレットが再計算されてしまうため。
一時的・安全な方式（TLS 1.3で主流・必須）	DHE / ECDHE （一時的DH方式）	利用可能（TLS 1.2の一部設定）	利用可能（※表中の「カ」に入るのは DHE です）	あり	通信ごとに鍵を完全に使い捨てるため、仮に将来サーバーの長期秘密鍵が漏れても過去の通信は絶対に解読されない。
	PSK （事前共有鍵方式）	利用可能	利用可能	方式による	あらかじめ共有された鍵を使って効率的にハンドシェイクを行う方式。

Q.ユーザテーブルとNATテーブルって何？

Q.ユーザテーブルは何をしているの？
A.利用者IDと仮想PCのIPアドレスを対応づけているテーブル。これによって、クライアントから受け取ったパケットをどの仮想PCに流すべきかが判断できるようになる。

Q.NATテーブルは何をしているの？
A.SSL-VPN装置は、トンネルを抜けて届いたパケットを受け取ると、ユーザーテーブルで「このユーザーは何番の仮想PCに繋ぐべきか」を確認し、NATテーブル（DNAT）を使って宛先IPアドレスを「そのユーザー専用の仮想PCのIPアドレス」に書き換えて社内ネットワークへ送り出す。

上の添付のように、NATテーブルにエントリが作成されるのは、通信が開始する前に事前にユーザテーブルから取得しているのである。要はエントリには「クライアントIP(DHCPから払い出されたIP)⇔仮想PCのIP」の対応が作成される。

Q.クライアントIP、プライベートIP、グローバルIPと３重構造になってしまうのでは？

よくある疑問として「自宅PCのプライベートIP」「VPN装置から割り当てられたクライアントIP」「インターネット用のグローバルIP」の三重構造になってパケットが流れているのではないか？
A.結論から言うと３重にはなっておらず２重である。
１．VDIクライアントは127.0.0.1:3389という、ごく普通のローカルアドレスに対して、通常のTCP接続を試みる
２．SSL-VPNクライアントにパケットが届く
（ここで言ったん終端する。なので、パケットの内部を変換するというよりもSSL-VPNがここから再度パケットを生成する）
３．SSL-VPNクライアントは、”受け取った、中身のデータ(アプリケーション層のデータ)”だけを取り出し、”全く新しい、別のTCPコネクション”を、”クライアントIP”という、別のアドレスを使って、”一から、新規に、作り直す
４．PCは当該パケットをただのペイロードと同じようにいつも通り、グローバルIPを付与してSSL-VPN装置に届ける