PPTP - 勉強会の成果
- 2013/11/13
- 19:31
前回の記事で 「ネットワークの勉強会に参加した」 という一文を書きました。
勉強会のそもそもの始まりは、客先に設置したサーバを 遠隔操作 する方法を模索してい僕に 「PPTP」 という存在を教えて下さった IT 企業の社長さんがおりましたが、なんとそのお方が 「げんちゃんの将来の教育ためにネットワーク勉強会を開いたげる！」 と気にかけて下さったことでした。
この勉強会では、「ヤマハルータを使った PPTP サーバの構築」 を学習しました。この成果は今の業務でも大変役立っており、なによりも僕自身の知識と経験を磨かせて頂きました。
この場を借りて、社長さんと講師のネットワークエンジニアさんにお礼を申し上げます。
さて、せっかく学んだ知識と経験です。今回学んだ PPTP の知識をより一層深くするため、いつものように概念や仕組みを以下にメモしていこうと思います。
PPTP とは？
PPTP (Point to Point Tunneling Protocol) とは、名前の通り 「PPP パケットをトンネリング」 するプロトコルです。
PPTP は Microsoft 社の 「MS-Chap」 という認証プロトコルや、その他の暗号化技術を利用することで、暗号化された VPN を組むことができます。昨今のインターネット VPN では、IPsec による暗号化通信がデファクトスタンダード化していますが、手軽に VPN を組める PPTP もまだまだ健在の VPN 実現プロトコルのようです。
↑図1：PPTP のイメージ図
※今回は PPTP に重点を置いたメモですので、PPP と PPPoE を混合させて記載することがあります。これらの違いや詳細は別の機会にメモいたしますので、今回は同じような意味合いだと受け止めて下さい。
VPN ってなに？
PPTP のメモの前に、簡単に VPN についてメモします。
VPN とは Virtual Private Network の略でして、こちらも名前の通り 「仮想的なプライベートネットワーク」 と表すことができます。プライベートネットワークと言えば LAN のことを意味します。
基本的に LAN は建物内で構築され、またプライベートな通信はインターネットを出ることができないことから、LAN はガラパゴスな存在として扱われます。しかし中には離れた拠点間で LAN をつなぎ合わせたいときもあります。こういったときに、インターネット回線や専用線を介して、物理的に距離が離れた LAN 同士を繋ぎ合わせる技術、すなわち VPN が用いられます。
↑図2：VPN は物理的に離れた LAN 同士を仮想的に繋げる
また VPN は大きく分けて 3種類 に分けられます。以下、それぞれの VPN の特徴を簡単にメモしていきます。
1．IP-VPN
2．インターネット VPN
3．エントリー VPN
1．IP-VPN
IP-VPN は、通信事業者が持つ専用線を使った閉域 IP 網の VPN です。インターネット回線とは全く違う、別のキャリア独自の回線で VPN を構築することから、セキュリティがとても頑丈であり、かつ 「帯域保証型」 の回線を用いることで、通信速度が安定した VPN が構築できます。しかし IP-VPN は専用線を使うこともあり、費用がとにかく高くのが特徴です。
↑図3：IP-VPN
2．インターネット VPN
インターネット VPN は、インターネット回線を経由して構築する VPN です。このブログの閲覧や Youtube の動画再生などは、言うまでもなくインターネット回線を使って実現していますが、まさにこのインターネット回線を使って VPN を構築します。専用線とは違ってただのインターネット回線を使うことから、費用が安く・かつ手軽に VPN を組めるのが特徴です。しかし閉域網の IP-VPN とは違ってインターネット網はオープンですから、インターネット VPN は IP-VPN に比べると 「速度・セキュリティ」 は段違いに劣ってしまいます。ちなみに今回の PPTP は、このインターネットで VPN を構築するためのプロトコルです。
↑図4：インターネット VPN
3．エントリー VPN
エントリー VPN は、IP-VPN とインターネット VPN を間に位置する VPN です。エントリー VPN は、IP-VPN のように通信事業者が所有する閉域網を使いますが、アクセス回線はインターネット VPN と同じ ADSL や FTTH などの 「ベストエフォート型」 です。こちらは速度はあまり期待できませんが、閉域網を使っていますので、低価格で安全な VPN を構築することができます。
僕自身、インターネット VPN には馴染みがありませんが、このエントリー VPN である 「フレッツ・VPN・ワイド」 での VPN は何度か構築したことがあります。このサービスは NTT が持つ 「NGN (Next Generation Network)」 回線内で VPN を構築するものです。
↑図5：エントリー VPN（VPN ワイド）
余談ですが、この記事をメモしている今現在の僕は、NTT 東日本の 「フレッツ v6 オプション」 という IPv6 アドレスを使った NGN 網内の IPv6 VPN の構築を研究しております。東日本の NGN は、現在主流の IPv4 通信は 200Mbps の帯域幅を持ちますが、IPv6 通信は 1Gbps の帯域幅を利用できます。この IPv6 アドレスで VPN を組めれば、かなり高速な VPN が実現できると予想しています。
↑図6：v6 オプションを使った VPN
……けれども一向に IPv6 の NGN VPN に成功せず、日々 IPv6 の悪夢にうなされている日々が続いていたりします。。OTL
PPTP セッション
さて、そろそろ本題の PPTP についてメモしていこうと思います。
前述もしましたが、PPTP は Microsoft 社の暗号化・認証技術を使って PPP を拡張させたトンネリングプロトコルです。ここでは PPTP が繋がる (セッションが確立する） 仕組みを順を追ってメモします。
インターネットが繋がった状態で PPTP セッションが確立するには、以下の 3フェーズ が必要です。
1．TCP コネクションの確立
2．PPTP コネクションの確立
3．PPTP セッションの確立
1．TCP コネクションの確立
これは PPTP に限ったことではなく、TCP の通信であれば全てに当てはまります。とても基本的なゆえにとても重要なのでメモします。
TCP 通信は 「コネクションの確立」 が必ず必要です。別名を 「ハンドシェイク (3-Way Handshake)」 とも呼びます。この仕組みはいたって単純で、TCP では通信を行うクライアントとサーバ同士が 「これから通信を始めますよ」 という意識合わせを必ず行います。
クライアント 「これから通信を始めますよ」 （1回目）
サーバ 『オッケーっ！こっちも通信してもいい？』 （2回目）
クライアント 「もちろんｗ」 （3回目） ← 3way-handshake
↑図7：3回やり取りするから 3Way Handshake
繰り返しますが、TCP 通信は上記のようなハンドシェイクが必ず行われます。PPTP も同じです。PPTP クライアントが PPTP サーバへ接続を開始すると、クライアントとサーバ間でハンドシェイクが行われ、TCP セッションが確立します。このハンドシェイクを終えて、PPTP は初めてコネクション確立処理を始められます。
↑図8：ハンドシェイクは SYN/ACK に1フラグが立つ
上記の図は 「Wireshark」 という通信パケットの中身を読むツールから、TCP コネクションのパケットを取り出したものです。 SYN パケットには 「SYN : Set」 に 1 フラグが立っています。SYN の承諾には ACK を返しますので、ACK パケットには 「Acknowledgement : Set」 に 1 フラグが立っていることがわかります。
2．PPTP コネクションの確立
ハンドシェイクを終えて TCP コネクションが確立したら、次は PPTP コネクションを始めます。PPTP は 「1723ポート」 を使いますので、TCP コネクションが確立した PPTP サーバの 1723 ポートに対し、PPTP クライアントは PPTP コネクションの要求メッセージを送ります。
TCP コネクションは 「SYN/ACK」 パケットを送受信しますが、PPTP コネクション の場合は 「Start-Control-Connection-Request」 と 「Start-Control-Connection-Reply」 を送受信します。Request と Reply から分かるように、Request が PPTP クライアントのメッセージで、Reply は PPTP サーバのメッセージです。この第2フェーズを終えると、最終フェーズの PPTP トンネリングを張る処理に入ります。
↑図9：PPTP コネクションも SYN/ACK と基本同じ
3．PPTP セッションの確立
PPTP コネクションが確立後、PPTP トンネリングを張るために PPTP クライアントは 「Outgoing-Call-Request」 パケットを PPTP サーバへ送ります。PPTP サーバは今までと同じ要領で、通信を承諾するパケット、すなわち 「Outgoing-Call-Reply」 パケットを PPTP クライアントへ返します。そして最後に PPTP クライアントは 「Set-Link-Info」 パケットを送信します。これにより PPTP トンネリングが正常に構成されるのです。
↑図10：PPTP セッション（トンネリング）の確立
また、Outgoing-Call パケットを交換するとき 「Call ID」 という ID を交換します。
Call ID はトンネリングに用いる 「GRE」 プロトコルのフィールドに入る数値ですが、PPTP トンネリング内ではこの Call ID で PPP パケットを判別します。Wireshark を使って Outgoing-Call パケットの中身を覗いてみると、確かに Outgoing-Call パケットで Call ID の情報が存在しました。
・ちょっと混乱
PPTP クライアントの Call ID には、通常の通信で使われるエフェメラルポートだったのですが、PPTP サーバの Call ID には 1723 ではなく同じくエフェメラルポート （たぶん…） の数値が書かれていました。最初は 「え、なんで 1723 じゃないの？」 と思いましたが、ポート 1723 は PPTP の制御に使われるポート であることを忘れておりました。PPTP のセッションが確立したあとは GRE プロトコルの通信に移りますので、1723 の役割はもう終えているのです。ただ GRE パケットは 「ポート番号の概念がない」 ため、Call ID をポート番号代わりとして DTE の判別をしているのでしょうかね。。
ちょっとここが気になるので、また別途 GRE の記事を書く機会があれば上記のことを追ってみたいと思います。とりあえず本記事では 「GRE プロトコルはトンネリング内で使われるプロトコル」 と思ってくださいまし。(^ω^)
↑図11：Call ID
さて、次に PPTP セッションの切断についてメモしていきます。
切断も接続と同じく 「切断してよろしいですか？」 『おうよ！また来いよｗ』 といったメッセージを交換します。切断も以下の 3フェーズ から行われますが、これは接続の手順を反対にさかのぼっているのが以下から分かると思います。
1．PPTP セッションの切断
2．PPTP コネクションの切断
3．TCP コネクションの切断
1．PPTP セッションの切断
PPTP トンネリングを終了させたい場合は、PPTP クライアントが 「Call-Clear-Request」 パケットを PPTP サーバに対して送ります。すると切断を承諾した PPTP サーバは、「Call-Disconnect-Notify」 パケットを送り返します。ちなみにこの通信では 「セッション切断」 のやり取りをしていますので、GRE プロトコルではなく TCP 1723 ポートへの通信となります。
2．PPTP コネクションの切断
Call-Disconnect-Notify パケットを受け取り、セッションが切断されたことを確認した PPTP クライアントは、次に 「Stop-Control-Connection-Request」 パケットを送信します。このレスポンスパケットは 「Stop-Control-Connection-Reply」 です。こうして PPTP 通信が終了していきます。
↑図12：PPTP の終了
そして最後に忘れてはならないのが TCP コネクションの切断です。
TCP コネクションの切断も、基本的にはハンドシェイクと同じです。ただ、少しだけ違う点があります。TCP コネクションの接続は、接続情報を 「3回」 にわたって交換するのに対し、TCP コネクションの切断は 「4回」 にわたって切断情報を交換します。
サーバ 『通信を切断しちゃってもいいっすか？』 （1回目）
クライアント 「はい、切断して問題ありません」 （2回目）
クライアント 「ではこちらかも終了いたしますが？」 （3回目）
サーバ 『おっけーっす。切断しちゃってくださいｗ」 （4回目）
また、コネクション接続には SYN パケットを使いますが、コネクション切断には 「FIN」 パケットを使います。FIN パケットは 「Fin : Set」 に 1 フラグが立っており、FIN を受け取った機器は ACK を返して切断を受け入れます。
↑図13：切断は4回のやり取りが行われる
以上が PPTP トンネリングが確立する一連の流れです。
以下に PPTP トンネリングの確立から切断までのパケットを解析した Wireshark の画像を載せます。画像右側の Info にて、送受信しているパケットの簡易情報が表示されていますので、パケットを深く解析しなくとも、大体のパケット内容を把握できるようになっています。
↑図14：PPTP トンネリングのパケット内容
PPTP フレームの構造
次は PPTP フレームのアーキテクチャについてメモしていきます。
ざっくりと書いてしまいますと、PPTP トンネル内では PPP パケットを IP データグラムでカプセル化 したものを送受信しますので、IP パケットと PPP パケットが覗き見・改ざん対策として 暗号化 されます。次にトンネリング通信には欠かせない GRE 、インターネット通信を制御する IP が PPP パケットに付加されます。こちらは通信に必要な経路情報などが記載されていますので、PPP パケットとは違って暗号化されません。
↑図15：PPTP 通信のカプセル化
パケットのカプセル化は PPTP に限ったことではなく、コンピュータネットワークの世界でしたら必ず発生する仕組みです。インターネットを閲覧するときに使われる HTTP なども、このカプセル化されたパケットが使われています。以下の図は、PPTP で使われる IP データグラムのカプセル化一覧です。
↑図16：PPTP カプセル化
少し話はそれますが、カプセル化……というかネットワークの勉強を始めると、避けて通れない概念があります。それは 「OSI 参照モデル」 という概念です。ネットワークのデータ通信を分けた階層ごとに分けた考え方で、とても重要です。
僕はこの概念をまだ理解しきれていないので、コンピュータネットワークで扱うデータを全て パケット と呼んでしまいますが、厳密には階層によって 「フレーム（データリンク層）」 や 「セグメント（トランスポート層）」 といったように呼び方が変わります。いつか7階層モデルについての記事も書きたいと思っていますので、その日が来るまではフレームのことをパケットと呼んでいても呆れたりしないでくださいまし。。(´・ω・`)
PPTP の認証
IPsec と比較して PPTP はセキュリティに弱いと言われていますが、そもそも PPTP はどのようなセキュリティ対策をとっているのでしょうか。そこの部分を調べてみましたので、以下にメモしていきます。
PPTP では、大きく分けて 2つのセキュリティ対策を施します。それは 「認証方法の暗号化」 と 「PPP パケットの暗号化」 です。まず PPTP クライアントがトンネリングを張るための要求メッセージを投げますが、PPTP サーバからしたら相手が許可されたユーザであるかを確認する必要があります。その確認が 「認証」 にあたります。
次に、認証が通ると PPTP トンネリングが張られますが、トンネリングとはいえども実態はインターネット上のルータやスイッチングハブを物理的に経由していますので、第三者にパケットを覗き見される恐れがあります。そこで PPP パケットに 「暗号化」 をかけておけば、運悪くパケットを覗き見されたとしても、それは暗号化されたパケットですので解析・解読することができなくなるのです。
↑図17：PPTP のセキュリティ対策
本項では、その中でも 「認証」 についてメモしていきます。
PPTP では、主に以下の 2種類 の認証方法が使われています。
・PAP (Password Authentication Protocol)
・CHAP (Challenge Handshake Authentication Protocol)
「PAP」 は読んで字のごとく、パスワードを用いる認証プロトコルです。クライアントは認証に必要な ID とパスワードをサーバへ送信し、サーバはそれが正しい情報だと判断すれば認証が成立します。ちなみにこのパスワードは暗号化されていない平文 （ひらぶん） ですが、どうやら電話回線の PPP 認証で使われるようで、今のインターネットのように改ざんされる心配はなさそうです。
↑図19：PAP 認証
一方 「CHAP」 は、Challenge Handshake Authentication Protocol が正式な名称ですが、Challenge という 乱数 を使って ID とパスワードを暗号化した情報を Handshake して認証する方式です。Handshake は TCP コネクションの確立でもメモしたように、クライアントとサーバがデータ送受信の前にコネクションを確立する方式です。この認証では 「チャレンジ・レスポンス認証」 と呼ばれる認証方式を用います。
まずクライアントは 「認証していいですか??」 というメッセージをサーバへ投げます。するとサーバは、何らかのアルゴリズムで 乱数 を生成し、『この乱数で ID とパスワードを暗号化して下さい』 というメッセージと乱数をクライアントへ送り返します。サーバから乱数を受け取ったクライアントは、認証に必要な ID とパスワードをこの乱数で暗号化し、「ID とパスワードを暗号化しました」 というメッセージを再びサーバへ暗号化データと共に送ります。この暗号化データのことを 「Response（レスポンス）」 と呼び、サーバも ID とパスワード情報を元にレスポンスを生成します。クライアントから受け取ったレスポンスが、サーバのレスポンスと合致すると 『認証に成功しました』 というメッセージがクライアントに返り、はじめて認証が成功する仕組みになっています。
↑図19：チャレンジレスポンス認証
この CHAP をもう少し機能拡張したものに 「MS-CHAPv2」 があります。これは Microsoft 社が開発した CHAP ベースの認証プロトコルです。今現在 PPTP で使われる認証プロトコルといえば、この MS-CHAPv2 が一般的です。
しかし 2012年夏に MS-CHAPv2 を クラック するツールが作られてしまったそうです。僕も含めて、企業ではまだまだ PPTP を使っている方々が多いですが、こういった問題が起きてしまった以上、PPTP での VPN 構築の未来はそう長くないのかもしれませんね。。
最後に
以上で PPTP に関してのメモを終わりにします。
GRE や OSI 参照モデル、また L2TP や IPsec などなど、まだまだ理解し切れていないところが多く、課題が残ってしまった今回の PPTP のメモですが、PPTP に関してはだいぶイメージがついてきたと思っています。
僕はインフラまわりのお仕事を任されておりますので、「ネットワーク機器の設定」 に関しては、色々と経験を積み重ねてきたつもりでした。しかし一方で今回の PPTP の記事のように、「ネットワークの仕組みの勉強」 を積み重ねたことは、実は全くありませんでした。
今の僕のように、ネットワークの知識をあまり持ち合わせていなくとも、ネットワーク機器の設定方法などを WEB やコマンド集から 調べる ことができれば、ネットワーク管理者は成り立ちます。これはネットワークだけでなく、プログラマーやサーバ管理者なども同じだと思っています。表面の操作だけを知っていればあとは 体が覚えてくれます ので、中身がブラックボックスでも業務を進めることができます。
ただ今回の記事を書いていくにつれ、徐々に自分の知識の無さに気づかされました。そしてこの道で食っていくつもりでいる以上、インフラまわりのプロを目指していく以上、こういった知識は必ず必要であること にも気づきました。
前回の記事にも書きましたが……日々精進です。。
勉強会のそもそもの始まりは、客先に設置したサーバを 遠隔操作 する方法を模索してい僕に 「PPTP」 という存在を教えて下さった IT 企業の社長さんがおりましたが、なんとそのお方が 「げんちゃんの将来の教育ためにネットワーク勉強会を開いたげる！」 と気にかけて下さったことでした。
この勉強会では、「ヤマハルータを使った PPTP サーバの構築」 を学習しました。この成果は今の業務でも大変役立っており、なによりも僕自身の知識と経験を磨かせて頂きました。
この場を借りて、社長さんと講師のネットワークエンジニアさんにお礼を申し上げます。
さて、せっかく学んだ知識と経験です。今回学んだ PPTP の知識をより一層深くするため、いつものように概念や仕組みを以下にメモしていこうと思います。
PPTP とは？
PPTP (Point to Point Tunneling Protocol) とは、名前の通り 「PPP パケットをトンネリング」 するプロトコルです。
PPTP は Microsoft 社の 「MS-Chap」 という認証プロトコルや、その他の暗号化技術を利用することで、暗号化された VPN を組むことができます。昨今のインターネット VPN では、IPsec による暗号化通信がデファクトスタンダード化していますが、手軽に VPN を組める PPTP もまだまだ健在の VPN 実現プロトコルのようです。
↑図1：PPTP のイメージ図
※今回は PPTP に重点を置いたメモですので、PPP と PPPoE を混合させて記載することがあります。これらの違いや詳細は別の機会にメモいたしますので、今回は同じような意味合いだと受け止めて下さい。
VPN ってなに？
PPTP のメモの前に、簡単に VPN についてメモします。
VPN とは Virtual Private Network の略でして、こちらも名前の通り 「仮想的なプライベートネットワーク」 と表すことができます。プライベートネットワークと言えば LAN のことを意味します。
基本的に LAN は建物内で構築され、またプライベートな通信はインターネットを出ることができないことから、LAN はガラパゴスな存在として扱われます。しかし中には離れた拠点間で LAN をつなぎ合わせたいときもあります。こういったときに、インターネット回線や専用線を介して、物理的に距離が離れた LAN 同士を繋ぎ合わせる技術、すなわち VPN が用いられます。
↑図2：VPN は物理的に離れた LAN 同士を仮想的に繋げる
また VPN は大きく分けて 3種類 に分けられます。以下、それぞれの VPN の特徴を簡単にメモしていきます。
1．IP-VPN
2．インターネット VPN
3．エントリー VPN
1．IP-VPN
IP-VPN は、通信事業者が持つ専用線を使った閉域 IP 網の VPN です。インターネット回線とは全く違う、別のキャリア独自の回線で VPN を構築することから、セキュリティがとても頑丈であり、かつ 「帯域保証型」 の回線を用いることで、通信速度が安定した VPN が構築できます。しかし IP-VPN は専用線を使うこともあり、費用がとにかく高くのが特徴です。
↑図3：IP-VPN
2．インターネット VPN
インターネット VPN は、インターネット回線を経由して構築する VPN です。このブログの閲覧や Youtube の動画再生などは、言うまでもなくインターネット回線を使って実現していますが、まさにこのインターネット回線を使って VPN を構築します。専用線とは違ってただのインターネット回線を使うことから、費用が安く・かつ手軽に VPN を組めるのが特徴です。しかし閉域網の IP-VPN とは違ってインターネット網はオープンですから、インターネット VPN は IP-VPN に比べると 「速度・セキュリティ」 は段違いに劣ってしまいます。ちなみに今回の PPTP は、このインターネットで VPN を構築するためのプロトコルです。
↑図4：インターネット VPN
3．エントリー VPN
エントリー VPN は、IP-VPN とインターネット VPN を間に位置する VPN です。エントリー VPN は、IP-VPN のように通信事業者が所有する閉域網を使いますが、アクセス回線はインターネット VPN と同じ ADSL や FTTH などの 「ベストエフォート型」 です。こちらは速度はあまり期待できませんが、閉域網を使っていますので、低価格で安全な VPN を構築することができます。
僕自身、インターネット VPN には馴染みがありませんが、このエントリー VPN である 「フレッツ・VPN・ワイド」 での VPN は何度か構築したことがあります。このサービスは NTT が持つ 「NGN (Next Generation Network)」 回線内で VPN を構築するものです。
↑図5：エントリー VPN（VPN ワイド）
余談ですが、この記事をメモしている今現在の僕は、NTT 東日本の 「フレッツ v6 オプション」 という IPv6 アドレスを使った NGN 網内の IPv6 VPN の構築を研究しております。東日本の NGN は、現在主流の IPv4 通信は 200Mbps の帯域幅を持ちますが、IPv6 通信は 1Gbps の帯域幅を利用できます。この IPv6 アドレスで VPN を組めれば、かなり高速な VPN が実現できると予想しています。
↑図6：v6 オプションを使った VPN
……けれども一向に IPv6 の NGN VPN に成功せず、日々 IPv6 の悪夢にうなされている日々が続いていたりします。。OTL
PPTP セッション
さて、そろそろ本題の PPTP についてメモしていこうと思います。
前述もしましたが、PPTP は Microsoft 社の暗号化・認証技術を使って PPP を拡張させたトンネリングプロトコルです。ここでは PPTP が繋がる (セッションが確立する） 仕組みを順を追ってメモします。
インターネットが繋がった状態で PPTP セッションが確立するには、以下の 3フェーズ が必要です。
1．TCP コネクションの確立
2．PPTP コネクションの確立
3．PPTP セッションの確立
1．TCP コネクションの確立
これは PPTP に限ったことではなく、TCP の通信であれば全てに当てはまります。とても基本的なゆえにとても重要なのでメモします。
TCP 通信は 「コネクションの確立」 が必ず必要です。別名を 「ハンドシェイク (3-Way Handshake)」 とも呼びます。この仕組みはいたって単純で、TCP では通信を行うクライアントとサーバ同士が 「これから通信を始めますよ」 という意識合わせを必ず行います。
クライアント 「これから通信を始めますよ」 （1回目）
サーバ 『オッケーっ！こっちも通信してもいい？』 （2回目）
クライアント 「もちろんｗ」 （3回目） ← 3way-handshake
↑図7：3回やり取りするから 3Way Handshake
繰り返しますが、TCP 通信は上記のようなハンドシェイクが必ず行われます。PPTP も同じです。PPTP クライアントが PPTP サーバへ接続を開始すると、クライアントとサーバ間でハンドシェイクが行われ、TCP セッションが確立します。このハンドシェイクを終えて、PPTP は初めてコネクション確立処理を始められます。
↑図8：ハンドシェイクは SYN/ACK に1フラグが立つ
上記の図は 「Wireshark」 という通信パケットの中身を読むツールから、TCP コネクションのパケットを取り出したものです。 SYN パケットには 「SYN : Set」 に 1 フラグが立っています。SYN の承諾には ACK を返しますので、ACK パケットには 「Acknowledgement : Set」 に 1 フラグが立っていることがわかります。
2．PPTP コネクションの確立
ハンドシェイクを終えて TCP コネクションが確立したら、次は PPTP コネクションを始めます。PPTP は 「1723ポート」 を使いますので、TCP コネクションが確立した PPTP サーバの 1723 ポートに対し、PPTP クライアントは PPTP コネクションの要求メッセージを送ります。
TCP コネクションは 「SYN/ACK」 パケットを送受信しますが、PPTP コネクション の場合は 「Start-Control-Connection-Request」 と 「Start-Control-Connection-Reply」 を送受信します。Request と Reply から分かるように、Request が PPTP クライアントのメッセージで、Reply は PPTP サーバのメッセージです。この第2フェーズを終えると、最終フェーズの PPTP トンネリングを張る処理に入ります。
↑図9：PPTP コネクションも SYN/ACK と基本同じ
3．PPTP セッションの確立
PPTP コネクションが確立後、PPTP トンネリングを張るために PPTP クライアントは 「Outgoing-Call-Request」 パケットを PPTP サーバへ送ります。PPTP サーバは今までと同じ要領で、通信を承諾するパケット、すなわち 「Outgoing-Call-Reply」 パケットを PPTP クライアントへ返します。そして最後に PPTP クライアントは 「Set-Link-Info」 パケットを送信します。これにより PPTP トンネリングが正常に構成されるのです。
↑図10：PPTP セッション（トンネリング）の確立
また、Outgoing-Call パケットを交換するとき 「Call ID」 という ID を交換します。
Call ID はトンネリングに用いる 「GRE」 プロトコルのフィールドに入る数値ですが、PPTP トンネリング内ではこの Call ID で PPP パケットを判別します。Wireshark を使って Outgoing-Call パケットの中身を覗いてみると、確かに Outgoing-Call パケットで Call ID の情報が存在しました。
・ちょっと混乱
PPTP クライアントの Call ID には、通常の通信で使われるエフェメラルポートだったのですが、PPTP サーバの Call ID には 1723 ではなく同じくエフェメラルポート （たぶん…） の数値が書かれていました。最初は 「え、なんで 1723 じゃないの？」 と思いましたが、ポート 1723 は PPTP の制御に使われるポート であることを忘れておりました。PPTP のセッションが確立したあとは GRE プロトコルの通信に移りますので、1723 の役割はもう終えているのです。ただ GRE パケットは 「ポート番号の概念がない」 ため、Call ID をポート番号代わりとして DTE の判別をしているのでしょうかね。。
ちょっとここが気になるので、また別途 GRE の記事を書く機会があれば上記のことを追ってみたいと思います。とりあえず本記事では 「GRE プロトコルはトンネリング内で使われるプロトコル」 と思ってくださいまし。(^ω^)
↑図11：Call ID
さて、次に PPTP セッションの切断についてメモしていきます。
切断も接続と同じく 「切断してよろしいですか？」 『おうよ！また来いよｗ』 といったメッセージを交換します。切断も以下の 3フェーズ から行われますが、これは接続の手順を反対にさかのぼっているのが以下から分かると思います。
1．PPTP セッションの切断
2．PPTP コネクションの切断
3．TCP コネクションの切断
1．PPTP セッションの切断
PPTP トンネリングを終了させたい場合は、PPTP クライアントが 「Call-Clear-Request」 パケットを PPTP サーバに対して送ります。すると切断を承諾した PPTP サーバは、「Call-Disconnect-Notify」 パケットを送り返します。ちなみにこの通信では 「セッション切断」 のやり取りをしていますので、GRE プロトコルではなく TCP 1723 ポートへの通信となります。
2．PPTP コネクションの切断
Call-Disconnect-Notify パケットを受け取り、セッションが切断されたことを確認した PPTP クライアントは、次に 「Stop-Control-Connection-Request」 パケットを送信します。このレスポンスパケットは 「Stop-Control-Connection-Reply」 です。こうして PPTP 通信が終了していきます。
↑図12：PPTP の終了
そして最後に忘れてはならないのが TCP コネクションの切断です。
TCP コネクションの切断も、基本的にはハンドシェイクと同じです。ただ、少しだけ違う点があります。TCP コネクションの接続は、接続情報を 「3回」 にわたって交換するのに対し、TCP コネクションの切断は 「4回」 にわたって切断情報を交換します。
サーバ 『通信を切断しちゃってもいいっすか？』 （1回目）
クライアント 「はい、切断して問題ありません」 （2回目）
クライアント 「ではこちらかも終了いたしますが？」 （3回目）
サーバ 『おっけーっす。切断しちゃってくださいｗ」 （4回目）
また、コネクション接続には SYN パケットを使いますが、コネクション切断には 「FIN」 パケットを使います。FIN パケットは 「Fin : Set」 に 1 フラグが立っており、FIN を受け取った機器は ACK を返して切断を受け入れます。
↑図13：切断は4回のやり取りが行われる
以上が PPTP トンネリングが確立する一連の流れです。
以下に PPTP トンネリングの確立から切断までのパケットを解析した Wireshark の画像を載せます。画像右側の Info にて、送受信しているパケットの簡易情報が表示されていますので、パケットを深く解析しなくとも、大体のパケット内容を把握できるようになっています。
↑図14：PPTP トンネリングのパケット内容
PPTP フレームの構造
次は PPTP フレームのアーキテクチャについてメモしていきます。
ざっくりと書いてしまいますと、PPTP トンネル内では PPP パケットを IP データグラムでカプセル化 したものを送受信しますので、IP パケットと PPP パケットが覗き見・改ざん対策として 暗号化 されます。次にトンネリング通信には欠かせない GRE 、インターネット通信を制御する IP が PPP パケットに付加されます。こちらは通信に必要な経路情報などが記載されていますので、PPP パケットとは違って暗号化されません。
↑図15：PPTP 通信のカプセル化
パケットのカプセル化は PPTP に限ったことではなく、コンピュータネットワークの世界でしたら必ず発生する仕組みです。インターネットを閲覧するときに使われる HTTP なども、このカプセル化されたパケットが使われています。以下の図は、PPTP で使われる IP データグラムのカプセル化一覧です。
↑図16：PPTP カプセル化
少し話はそれますが、カプセル化……というかネットワークの勉強を始めると、避けて通れない概念があります。それは 「OSI 参照モデル」 という概念です。ネットワークのデータ通信を分けた階層ごとに分けた考え方で、とても重要です。
僕はこの概念をまだ理解しきれていないので、コンピュータネットワークで扱うデータを全て パケット と呼んでしまいますが、厳密には階層によって 「フレーム（データリンク層）」 や 「セグメント（トランスポート層）」 といったように呼び方が変わります。いつか7階層モデルについての記事も書きたいと思っていますので、その日が来るまではフレームのことをパケットと呼んでいても呆れたりしないでくださいまし。。(´・ω・`)
PPTP の認証
IPsec と比較して PPTP はセキュリティに弱いと言われていますが、そもそも PPTP はどのようなセキュリティ対策をとっているのでしょうか。そこの部分を調べてみましたので、以下にメモしていきます。
PPTP では、大きく分けて 2つのセキュリティ対策を施します。それは 「認証方法の暗号化」 と 「PPP パケットの暗号化」 です。まず PPTP クライアントがトンネリングを張るための要求メッセージを投げますが、PPTP サーバからしたら相手が許可されたユーザであるかを確認する必要があります。その確認が 「認証」 にあたります。
次に、認証が通ると PPTP トンネリングが張られますが、トンネリングとはいえども実態はインターネット上のルータやスイッチングハブを物理的に経由していますので、第三者にパケットを覗き見される恐れがあります。そこで PPP パケットに 「暗号化」 をかけておけば、運悪くパケットを覗き見されたとしても、それは暗号化されたパケットですので解析・解読することができなくなるのです。
↑図17：PPTP のセキュリティ対策
本項では、その中でも 「認証」 についてメモしていきます。
PPTP では、主に以下の 2種類 の認証方法が使われています。
・PAP (Password Authentication Protocol)
・CHAP (Challenge Handshake Authentication Protocol)
「PAP」 は読んで字のごとく、パスワードを用いる認証プロトコルです。クライアントは認証に必要な ID とパスワードをサーバへ送信し、サーバはそれが正しい情報だと判断すれば認証が成立します。ちなみにこのパスワードは暗号化されていない平文 （ひらぶん） ですが、どうやら電話回線の PPP 認証で使われるようで、今のインターネットのように改ざんされる心配はなさそうです。
↑図19：PAP 認証
一方 「CHAP」 は、Challenge Handshake Authentication Protocol が正式な名称ですが、Challenge という 乱数 を使って ID とパスワードを暗号化した情報を Handshake して認証する方式です。Handshake は TCP コネクションの確立でもメモしたように、クライアントとサーバがデータ送受信の前にコネクションを確立する方式です。この認証では 「チャレンジ・レスポンス認証」 と呼ばれる認証方式を用います。
まずクライアントは 「認証していいですか??」 というメッセージをサーバへ投げます。するとサーバは、何らかのアルゴリズムで 乱数 を生成し、『この乱数で ID とパスワードを暗号化して下さい』 というメッセージと乱数をクライアントへ送り返します。サーバから乱数を受け取ったクライアントは、認証に必要な ID とパスワードをこの乱数で暗号化し、「ID とパスワードを暗号化しました」 というメッセージを再びサーバへ暗号化データと共に送ります。この暗号化データのことを 「Response（レスポンス）」 と呼び、サーバも ID とパスワード情報を元にレスポンスを生成します。クライアントから受け取ったレスポンスが、サーバのレスポンスと合致すると 『認証に成功しました』 というメッセージがクライアントに返り、はじめて認証が成功する仕組みになっています。
↑図19：チャレンジレスポンス認証
この CHAP をもう少し機能拡張したものに 「MS-CHAPv2」 があります。これは Microsoft 社が開発した CHAP ベースの認証プロトコルです。今現在 PPTP で使われる認証プロトコルといえば、この MS-CHAPv2 が一般的です。
しかし 2012年夏に MS-CHAPv2 を クラック するツールが作られてしまったそうです。僕も含めて、企業ではまだまだ PPTP を使っている方々が多いですが、こういった問題が起きてしまった以上、PPTP での VPN 構築の未来はそう長くないのかもしれませんね。。
最後に
以上で PPTP に関してのメモを終わりにします。
GRE や OSI 参照モデル、また L2TP や IPsec などなど、まだまだ理解し切れていないところが多く、課題が残ってしまった今回の PPTP のメモですが、PPTP に関してはだいぶイメージがついてきたと思っています。
僕はインフラまわりのお仕事を任されておりますので、「ネットワーク機器の設定」 に関しては、色々と経験を積み重ねてきたつもりでした。しかし一方で今回の PPTP の記事のように、「ネットワークの仕組みの勉強」 を積み重ねたことは、実は全くありませんでした。
今の僕のように、ネットワークの知識をあまり持ち合わせていなくとも、ネットワーク機器の設定方法などを WEB やコマンド集から 調べる ことができれば、ネットワーク管理者は成り立ちます。これはネットワークだけでなく、プログラマーやサーバ管理者なども同じだと思っています。表面の操作だけを知っていればあとは 体が覚えてくれます ので、中身がブラックボックスでも業務を進めることができます。
ただ今回の記事を書いていくにつれ、徐々に自分の知識の無さに気づかされました。そしてこの道で食っていくつもりでいる以上、インフラまわりのプロを目指していく以上、こういった知識は必ず必要であること にも気づきました。
前回の記事にも書きましたが……日々精進です。。
スポンサーサイト
