システム奮闘記：その25

PPTP方式でVPN通信

はじめに

  うちの会社、本社と営業所との間は、フレームリレー回線で結ばれている。
  しかし、フレームリレー回線の費用は高いため、他に安い回線を探した結果
行き着いた先は、インターネットVPNだった。

  本来ならば、インターネットVPNが導入されるまでの物語を書きたい所ですが
何せ、量が膨大になるため、分割して書く事にしました。

  そこで今回は、インターネットVPN導入を検討している段階で、
実際に、インターネットVPNが、どんな物かを体験するために、自宅と会社の間を
既存のシステムを活用して、VPN通信ができるようにしました。

  そこで、サブタイトルを「自宅から会社に接続するぞ！」にしました。


  さて、VPN導入を進めるため、1冊の本を買ってもらった。
  「最新VPNハンドブック」（伊藤幸夫、紫藤政義、野口修：秀和システム）

  本を開いて読んでいくと、手軽でインターネットVPN通信ができるという。
  既存のヤマハのルーター(RTA55i)と、外部のWindowsXPのマシンとを使って
VPNができる事が本に書いてあった。

  自宅から会社に接続できたら、会社に来ているメールが自宅で読み書きできたり
画像データなどを会社に送信したり、会社からダウンロードできたりするので
便利になる。

  しかし、不安があった。VPNの暗号化には2種類ある。
  一つはPPTP方式。もう一つはIPSeC方式がある。

  本にはIPSeCの方がセキュリティー的に安全と書いている

  こんな文章を見ると、PPTPに対して不安を持ってしまう。
  そこで、実際にPPTPでも大丈夫なのか確かめるために、
びぎねっとのMLに聞いてみる事にした。

  今年6月号のSoftware DesignにPPTPで構築するVPNサーバー
の記事を書きましたが、PPTPだとアカウントとパスワードがばれて
しまうと成りすましを防げないので確かにセキュリティ的に不安は
あります。

　ですが、運用次第（定期的にパスワードを変更する等）では十分に
使用に耐えうると考えます。

# 実際に私はそうしています。

  このお返事を見た私は、会社に接続する場合だけでなく、社内に導入する
インターネットVPNもPPTP方式を選択しようと思った。

  実際には、インターネットVPNの場合は、IPSeC方式になったのだが、
その経緯は「システム奮闘記：その35」(インターネットVPN導入)をご覧ください。

  しかし、この時は、PPTPの方が手軽な感じがするし、導入しやすいと思った。

PPTP方式でVPN通信に挑戦

  さて、PPTPでインターネットVPNを導入しようと考えた。
  しかし、一体、PPTPが何なのか知らなければ、設定も何もできない。

  そこで、お勉強する事になった。


  PPTPは、パスワードがバレなければ安全というが、1つ、疑問が出た。
  パスワードが盗聴された場合だ。もちろん、パスワードは暗号化される。
PPTPサーバーが受け取るのは、暗号化されたパスワードだ
  だが、暗号化されたパスワードが、ネット上で、第三者に盗聴され、
その暗号化パスワードを使って接続を試みたら成功するのではないか。
  となれば、パスワードの暗号化は無意味ではないかと思った。

パスワード認証の概略

アクセスごとにサーバーから乱数文字列を与えられる。 それをパスワードに追加して暗号化したパスワードを認証に使う。 暗号化されたパスワードは1回きりなので、盗聴されても、 暗号を解読しない限り、「なりすまし」で接続される心配はない。

  この図を見て「これは、CHAPやで。MS-CHAPやMS-CHAPv2とちゃうで」
という突っ込みがあるかと思います。
  正直な事を書きますと、上の図は、CHAPというパスワードの認証方法です。

  この時点では、PPTPのパスワード認証が上図だと誤解していました (^^;;
  詳しくは、後述しています。

  さて、上の図で不可逆暗号が出てきた。
  復元不可能な暗号化だというのは知っていたが、一定の長さの文字列になるのは
知らなかった。

不可逆暗号（ハッシュ関数）とは？

任意の長さの文字列（文章など）があり、これに不可逆暗号をかけると、 一定の長さの文字列に変換される。できた文字列をハッシュ値とも言う。 「不可逆」という言葉の通り、復元不可能な暗号で、一度、暗号化すると、 中身を見る事ができない。 ハッシュ値を別名「指紋」とも言う。指紋はご存じの通り、同じ物はこの世にない。 ハッシュ値も、不可逆暗号にかけられる前の文字列の文字を、少し触っただけで、 全く別物になってくる。そのため、ハッシュ値は、同じ物は存在しないので 「指紋」と呼ばれるゆえんだ。 主な用途としては、パケット認証に使われる。パケットの中身が改竄されていないか チェックするため、送信時に、不可逆暗号を付けてパケットを送る。 到着先で、文章の中身を不可逆暗号をかけて、送信時についてきた 不可逆暗号化の部分と照らし合わせる。一致すれば改竄されていないとなる。 だが、復元できないからといって、100%解読されないわけでない。 ランダムに文字列を作り出し、不可逆暗号をかけて、その結果と、 盗聴したパスワードとを照らし合わせて、一致する物を見つけ出す方法もある。 力づくの方法だが、解読できないわけではない。それにパソコンの性能の向上が 著しいので、力づくでの方法でも、パスワードが解読される事も考えられる。

  さて、通信を行なう際、パケットの中身も気になる。
  PPTPの場合、第2層の「データリンク層」で暗号化を行なっている。

お馴染の階層構造

PPTP通信でのパケットの中身

カプセリングの状態

  GREへッダーとは何かが気になる。
  本を読むと、TCPへッダーを簡素化した感じの物だという。

GREへッダー

TCPへッダー

  見た感じ、GREへッダーの方が構造が簡単だ。

  GREへッダーをつける理由が本に書いてあった。

  IPへッダーだけだと、コネクション管理をしてくれないので、
パケットを紛失しても、わからなくなる。
  しかし、TCPへッダーだと処理のための負担が重いので、負担の軽い
GREパケットを使っているという。

  確かに、ポート番号などがないため、TCPへッダーよりも
処理の負担が軽いのかなぁと思ってしまうのだが、負担が軽いといっても
実際に体感していないので、「へぇ〜」という程度だった  (^^;;

  だいたい概略が、わかってきた感じがした。
  でも、それは表面的に過ぎなかった事を、後で知るのであった (^^;;

  この時、ダイヤルアップでないのに、なぜPPPでカプセリングするのか
疑問だった。
  しかし、この時点では「なるほど！」と思うような事例などはなかった。
  そのため「まぁ、後で調べよう」という感じだった。
 
PPTP方式の通信の仕組み

  一通り、PPTPのお勉強した。
  ゆっくり設定に挑戦しようと思った、2003年12月の、ある日の事だった。

  東京支店の部長が「菅ちゃん、モバイルを使って、俺のノートパソコンから
会社へ接続して、メール見れるようにしてくれへんか？」と言ってきた。
  少し前に部長にVPNの話をしていたが、まだ先の話だという事も言ったのだが
「まだか、まだか」で待っていたみたい・・・ (--;;
  私は「そんな、すぐにできるわけないでしょ。無理ですよ」と言うと、
部長は「それって、そんなに難しい事なんか？」と聞いてきたので、
「そうですよ。難しいですよ」と答えた。

  魔法使いじゃあるまいし、そんなに簡単にできれば、苦労はいらないと思った。


  自宅から会社に接続してメールを読む話。
  実は、これが最初ではなかった。うちの会社が、インターネット接続した頃、
社内で「自宅から接続してメールを読めるようにしてくれへんかなぁ」と
言う人がいた。
  しかし、ルーター側でPOP3のポートを開けるだけではなく、暗号化されていない
パスワードをネット上に流れてしまうため、盗聴などの危険性が増える。
  さすがに、恐いので「セキュリティー的に危険すぎるので、できません。
その代わり、ホットメールなどに転送する事は可能です」と提案して、
必要な時には、その人の個人のメールアドレスへ転送する事になった。

  他の人の依頼も全て転送で対応する事にした。

  最初の頃は、それでも問題なかった。
  しかし、大量のデータを送る人が出てくるようになった時、巨大な容量のため、
プロバイダーから受信拒否されたり、添付ファイル付きのメールがウイルスと
間違えられ、受信が拒否される事も出てきた。



  さて、部長の要請もあり、重い腰を上げる事にした。
  とりあえず、PPTPを使って自宅から会社へ接続して。メールが読めるように
できないかと思い、さっそく設定してみる事にした。


  だが、ヤマハのルーターに問題がある。
  商品としては良い物を作っているのだが、説明書の内容が不足しすぎ。
  しかも、ヤマハのホームページを見ても、わかりにくい。
と書くよりも、わからん所が多すぎる (--;;

  なんとかして、ヤマハのホームページで、それらしい設定のページを
見つけて触ってみた。
  ちなみに、ルーターの機種はRTA55iです。
  
  次に、困った問題に出くわした。

  どうやってクライアントの設定をするかだった。

  Webで調べたら、WindowsXPでのクライアントの設定方法は載っていた。
  しかし、問題は、動作検証を行なうためのクライアントが、どこにあるかだった。

  そこで、自宅にADSLを引いていて、しかも、WindowsXP搭載のノートパソコンを
持っているＴ君に実検台になってもらう事にした。

  まず、会社でＴ君のパソコンを設定する事にした。
  動作検証という事で、下図のように、接続が実験を行なった。

VPNの設定実験

T君のパソコンを使って、社内からVPNで接続をしてみた。

  結果は・・・

  何でエラーが出るねん （ＴＴ）

  だった。原因が何なのか、全く見当もつかない。

  もしかしたら、ルーターの内部のネットワークから接続しているからダメなので、
実際に外から接続すると、うまくいくのではと思い、Ｔ君に頼んで、
自宅から接続実験をしてもらった。

VPNの設定実験

  結果は・・・

  アカンかった （ＴＴ）

  だった。

  困った事に、実際に、どんなエラーが出ているのか、わからなかった。
  自分で検証したくても自宅の環境が整っていないため、検証できなかった。

  ルーターの設定個所に怪しい場所があると思った。
  注目したのは、割り振るIPの事だった。

ヤマハのルーターのWeb設定の画面（機種はRTA55i）

  この時、「接続先に割り当てるIPアドレス」が、何なのか全く理解してなかった。
  そこで、ヤマハのサポートセンターに電話した。
  だが、話が通じない。相手は、私が「割り振るIP」が、どういう意味を
持っているのか知っていると思い込んでいたようだ。
  センターの人は「固定割り当ての場合は、プライベートIPを入れてください。
DHCPサーバー機能からの割り当ての場合は、任意のプライベートIPが
割り当てられます」と言った。
  もちろん、何の事やらわからない私。私は「あの、接続先はプライベートアドレスの
範囲ではなく、グローバルの範囲なのですが」と言うと、お互い話が通じていないのか
わけがわからなくなってきた。
  私は「これじゃ、根掘り葉堀り聞いても、話が通じない」と判断して、
「一度、試してみます」と言って、ごまかして電話を切った。


  ここで、IPアドレスを割り当てる理由を書く事にします。
  

IPを割り当てる理由

PPTPの場合、上図のような仮想的に接続しているように見せている。 そのため、仮想マシンとしてのIPアドレスが必要になってくる。 しかし、この段階では、仮想マシンとして接続する事を全く理解していないため 頭の中が混乱していた。

  なぜ、IPアドレスを割り振るのか、全くわからなかった。
  何せヤマハのルーターに書かれている日本語も、わかりにくい。
  「接続先に割り当てるIP」と書かれても、何の事か、よくわからない。

  私は「接続先に割り当てるIP」を、次のように解釈した。
  もしかして、接続先のマシンのIPアドレスなのでは？

  そこで、次に接続先のマシン（メールサーバー）のIPを割り振ってみた。
  そして、もう一度、実験をしてみた。

VPNの設定実験

  結果は・・・

  アカンかった （ＴＴ）

  だった。
  WindowsXP搭載のマシンはＴ君の物なので、借りるわけにもいかない。
  いつもＴ君に、実験を、お願いするのも、Ｔ君に悪い。
  だが、私の手元に、ノートパソコンがないので、自宅などで実験できない。
  困ったなぁと思いながら、頭を抱えた。


  ところが、年末になり、私の親が新しいパソコンを購入した。
  偶然は重なるもので、良いタイミングで、私の自宅（マンション）にも
光ファイバーが通ったため、接続の契約をしていた。
  時期が良く自宅に光ファイバーが開通した。

  親が新しいパソコンを買ったので、今まで、親が使っていたノートパソコンは、
使わないという事で、私の手元に転がりこんできた  (^^)V

  これで誰に対しても、気兼ねなく実験できるぞと思った。
  さて、ノートパソコンに、Windows2000proをインストールした。

  早速、転がり込んできたノートパソコンでVPNの通信エラーの内容を見た。

  エラー番号が800だという。
  VPN接続が確立できないというエラーだった。


  大晦日。会社の電話当番の日だった。しかし、電話がないので、実験ができる。
  早速、PPTPクライアントの設定を行なった。

VPNの設定実験

  この時、問題になっていたPPTPサーバーの設定にある
「接続先の割り当てるIP」は、何もしていなかった。
  結果は・・・

  アカンかった （ＴＴ）

  だった。
  しかし、めげずに、余っているIPを割り当てると

  うまく接続できた (^^)V

  それで成功だと思った。
  この時、割り当てるIPアドレスは、余っているIPを使う事だと思った。

  ちょっとした実験で、他のマシンから割り当てたIPアドレスに
pingを打ってみたら、反応した。

  この時、仮想的にネットワーク上に、割り当てたIPを持ったパソコンが
存在している状態だと思った。
  しかし、この時点では、あくまで推測だったけど・・・ (^^;;

  VPN通信の成功したのを確かめる事にした

VPNの設定実験

  自宅から接続してみたのだが・・・

     接続できへん （ＴＴ）

  だった。
  なぜ、接続できないのか見当がつかないだけに、頭を抱えてしまった。
  謎を解くため、正月から出勤したかったのだが、無断出勤は怒られるので、
仕事初めの日まで、うずうずしながら、待っていた。


  仕事初めの日、会社でヤマハのホームページに情報があるかどうか、
探してみた。
  FAQに、次の事が書かれているのを発見した。

[Q7] 圧縮に対応していますか? 

       [A] 対応していません。WindowsのPPTPクライアントの場合は、
           PPPの設定でソフトウェアによる圧縮を行うのチェックを
           外してください。RTシリーズやNetVolanteシリーズが
           クライアントの場合は特に設定の必要はありません。

  そこで、Windows2000proのPPTPの設定の変更を行なった。

設定変更個所（Windows2000pro）

ソフトウェアによる圧縮の所は初期設定ではチェックが入っている そこで設定を外しました

  しかし、接続はできなかった。

  翌日、出社して、ヤマハのサポートセンターに電話をかけみた。
  原因がわかった。

  VPNのパケットを通す設定をしていなかった (^^;;

  PPTP通信の制御のための1723ポート、PPTPのデータの中身を通す
GREプロトコルのパケットを通していなかった。
  そのため、VPN通信が確立できなかったという・・・ (--;;

  そこで、パケットを通すことにした。
  しかし、この時、大きな過ちを2つしてしまった。

2つの過ち
その1	GREはプロトコル番号が47というのを、ポート47と勘違いをして GREプロトコルを通さずに、ポート47を開けてしまった。
その2	PPTPのパケットでも、パケットフィルタリングができる。 どうやら、カプセリングを外した中身のフィルターだ。 何も設定をしなくても良かったのだが、変に設定してしまった。

VPNパケットのフィルタリングの画面 （初期状態で何も設定していない場合）

ここでもパケットフィルタリングの設定ができるのだが 下手に触ると、パケットが通らなくなる。 律儀にも、私は、ここのフィルタリングをしてしまった。

  こんな事だから、失敗談のネタは尽きないのである。

  さて、自宅に帰って、挑戦してみる。
  認証ができた。接続できたと思い喜んだ。

  しかし、喜びも束の間だった。
  今度は、pingが通らない。もちろん、メールサーバーに接続できない。
  なぜ、接続できなかったのか、全く見当もつかなかった。
  なぜなら、この時点では、正しい設定していると思い込んでいただけに

  なんでアカンねん （ＴＴ）

  だった。
  何が悪いのか見当がつかない。

  VPNの本を見て、PPTPの部分を読み直してみた時、ふと、思った。
  制御のための通信に、ポート1723を開ける事は書かれているが
GREのパケットを開けるためのポート番号が書かれていない。
  この時、私は「あれ、ポートは47じゃないのかなぁ。なんで、本には
載ってへんのやろ？？」と思った。
  いくら探しても、GREパケットに関するポート番号の記述はなかった。
  しかし、この時は、GREパケットを通すのにポート47を開ける事に対して
何も疑いを持たなかった。後から考えると、最初の思い込みは恐い・・・ (^^;;


  その原因がわかったのは、数日後だった。
  ふと、ヤマハのホームページで、ルーターの設定を見てみた。
  コマンド形式で書かれているので、普段は見る気も起こらないが、見てみると

  そこで、ルーターのコマンド設定を見てみると、GREプロトコルを通す
記述が見つからなかった。

  それと、ヤマハのホームページのFAQを読み返してみると
次のような記述があった。

[Q9] Firewallの内側にリモートアクセスVPNサーバーを設置する場合に注意する点は？

[A] ネットワーク管理者に相談して、TCPポート番号1723とGREプロトコル番号
    47を通すようにしてください。PPTPでは、トンネル制御に TCPポート1723を
    データ通信にGREプロトコル番号47を使います。

  ここで、ようやく気が付いた。
  ポート番号47でなく、プロトコル番号が47である事が！！

  よく考えると、ポート番号は、TCPプロトコルの通信の場合に使うのであって
GREプロトコルにポート番号の概念なんぞないはず・・・。
  「私って、TCP/IP通信の話を理解していないのでは？」と思ってしまった (--;;

パケットフィルタリングの正しい設定

  これで解決と思って、帰宅して、家からVPN接続を行なった。
  接続確立が完了した。これで、ようやく接続できると思った。
  そこで、導通確認のため、pingで確かめる事にしたのだが・・・

  なんでpingが通らへんねん （ＴＴ）

  だった。何が悪いのか見当がつかなかった。
  翌日、出社して設定を見直したが、思い当たる所がない。
  その晩、家でクライアント側の設定を触ってみたが、ダメだった (--;;

  こりゃアカンと思い、翌日、ヤマハのサポートセンターに電話をかけた。
  設定する手順を聞く事にした。

  早く運用したいという焦りから、ヤマハのサポートセンターの指示通り
真似して設定しようと思い、今までのVPNの設定を消した。
  あとで考えると、なぜ、ダメだったのかの原因追求ができなくなった (--;;

  サポートセンターの人の指示通り行なった。その作業は、私が設定した通りの
方法と同じだったので、センターの人に「前も、同じように設定をしたのですが
ダメだったんですわ」と言った。
  センターの人が「設定状況を解析するため、コマンド一覧を送って欲しい」と
言ったので、メールで送ることにした。
  あとで、センターの人から電話がかかってきて「設定は問題ないですねぇ、
pingも通りましたし。なぜ、今までつながらなかったのかは、わからないです」
だった。

  ここで、考えられる原因は、VPN用のパケットフィルタリングが
悪さをしていた可能性が高い。
  なにはともあれ、めでたく開通する事に成功した。

  解析のためコマンド一覧をメールで送っている。
  もちろん、ID、パスワードが丸見えで、しかも平文の状態だ。
  放置したままだとVPNの意味がないので、ID、パスワードの変更を行なった。

  自宅に帰り、親のWindowsXPのマシンで接続実験を行なった。

VPNの設定実験

  結果は・・・

　成功した V(^^)V

  だった。
  自宅のパソコンで、会社のメールサーバーに接続して、自宅で会社のメールの
読み書きができるように設定をした。
  早速、上司の携帯にメールを送った。

  翌日、上司が「VPN、うまくいったようやな」と言ってくれた。
  うまく携帯にメールが飛んだ事が確認できた。

  早速、WindowsXP用のVPN接続のマニュアルを作成する。
  言い出しっぺの部長は「年末、メールをプロバイダーに転送してもらったやろ。
今の所、それで充分だから、必要になった時に言うわ」だった。
  うーん、折角、設定したのに・・・。


  でも、これで終わっては面白くない。少し発展させてみる事にした。

  実は、他のプロジェクトを進めようという話が出ている。
  営業マンにノートパソコンを持たせて、遠隔地からモバイルを使って
会社にあるAS/400に接続して、受注入力や、見積もりが打てるようにする案だ。
  もちろん、VPN通信を行なう。

  一応、AS/400を納入してくれたＪ社に、見積もりを出してもらってはいるが、
お高い金額が出ている。
  とても、お高い「シスコのルーター」を提案しているからだ。
  そこで、既存のシステムを利用して、会社に接続できないかと考えてみた。

社内LAN内部に接続するための社内ネットワークの構成

社内LANに、VPNサーバーを構築。今回は、Windows98を活用。 自宅から接続を可能にするため、ルーター越えだけでなく、NAT越えもさせる。

  はじめ、NAT越えができるかどうか心配した。
  なぜなら、iptablesがGREパケットを通す機能がついているかどうか
知らなかったからだった。
  しかし、googleで「GRE iptables は」の3点で検索をかけたら、
見事に引っ掛かった。GREパケットも通すことがわかった。

（余談）
    googleなどの検索サイトを調べる時、コンピューターの用語、コマンドは
    アルファベッドになっている。アルファベッドだらけだと英語のサイトも
    出てしまうため、ちょっとした対策として、日本語の「は」を入れている。
    そうする事により、検索されるサイトが日本語のページに限定できる。


  そこで、NATの設定に次の事を追加した。

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1723 -j DNAT --to 192.168.X.Y
iptables -t nat -A PREROUTING -i eth0 -p 47 -j DNAT --to 192.168.X.Y

iptables -A FORWARD -i eth0 -p tcp --dport 1723 -d 192.168.X.Y -j ACCEPT 
iptables -A FORWARD -i eth0 -p 47 -d 192.168.X.Y -j ACCEPT 

  上の設定は、外部からやってきたポート1723のパケットと、
GREパケットを、プライベートアドレス（192.168.X.Y）へ通過させる設定。
  iptablesの詳しい話は「システム奮闘記：その21」をご覧ください。
　(Linuxのパケットフィルター iptablesの設定)

  さて、問題は、Windows98でPPTPクライアントにする設定だった。
  なかなか調べても見つからなかった。しかし、根性で、見つけ出した。

  その日、帰宅する際、会社で使っている私のパソコンと、もう一台のパソコンを
立ち上げたままにした。その晩、自宅に帰って実験する事にした。

  自分のパソコンからVPN通信を行なってみる。

  見事、成功！ V(^^)V

  なんと、社内向けホームページが閲覧できる！！

  おまけに、共有フォルダ─も丸見え！！

  いくら頭では、わかっていても、体感するとVPN接続の凄さに驚きだった。

  仮想的に社内LAN（プライベートアドレス）の内部にパソコンを
置いている感じなので、閲覧できて当然なのだが、外部から閲覧できる事実に
「こりゃ、VPNのIDとパスワードが漏洩したら、何もかも丸見えだなぁ」と思い
ちょっと恐い気がした (^^;;


  会社にある私のパソコンの共有フォルダ─を見てみることにした。
  動きが遅く、ぎこちないが、問題なく見ることができる。
  フォルダ─の中の、ワードやエクセルの資料も見る事ができる。
  全てが成功に思えた。

  だが、画像データを自宅のパソコンにダウンロードしようとすると

  途中でエラーが出てもうた （ＴＴ）

エラーの中身

自宅のパソコンに、VNCのソフトをダウンロードしようとしたが エラーを出て失敗した様子。

  画像データ自体は、50Kぐらいなので、重たくないはず。
もちろん、画像データ以外の物でも、50Kぐらいだと、ダウンロードできない。
  原因がわからなかった。

  そこで、自宅側のパソコンのOSを、Windows2000proでやってみる事にした。
  データをダウンロードする時、次のエラーが出た。

エラーの中身

自宅のパソコンに、データをダウンロードしようとしたが エラーを出て失敗した様子。

  だが、Windows2000proの場合、もっと重症だった。
  データを会社に送る場合に、次のエラーがでた。

エラーの中身

自宅のパソコンから会社に、データをアップロードしようとしたが エラーを出て失敗した様子。

  「なんでエラーが出るねん」という気分だった (--;;


  翌日、会社で次のような試験を行なった。

社内で模擬実験

社内のパソコンをグローバル側に設置して、PPTPでプライベート側に接続 この時、大きなデータを、グローバル側のマシンにダウンロードできるか試してみた

  結果は問題なくできた。4Mもあるデータをダウンロードできた。
  一体、自宅のマシンでは、どんな問題が起こったのだろうか??

  この謎を解こうと考えたが、技術者でない私には、とても越えられない壁だと思い
忍法「先送りの術」で、放置する事にした (^^;;

今となっては推測の域を出ないのだが、恐らくPMTUブラックホールが
発生していた事が考えられる。
LinuxやWindows2000の場合、MTUサイズが1500なのだが、
会社とプロバイダーを結ぶフレッツ網のMTUが1454な上、
恐らくパケットのDFビットも「1」が立っているため、分割できずに
データの送受信がうまくいかなかったと考えられる。
フレッツ網を通さずに、グローバル側にクライアントを置いた時に
送受信が問題なくできている事から、PMTUブラックホール問題が
原因だと推測している。

  本来なら、PPTPサーバーを、Linuxにしてみればと思う所だが、
PPTPサーバーを構築する場合、カーネルの再構築が必要になってくる。
  まだ、私にとってカーネル再構築は未知の領域。
  無念と思いつつ、LinuxでPPTPサーバー構築は断念した (--;;

  LinuxでPPTPサーバーは「システム奮闘記：その27」をご覧ください。

  なぜ、PPTPはダイヤルアップの技術の拡張なのか疑問に思っていた。
  だが、Windows98で、PPTPが使えるように設定した時、なるほどと思った。

PPTPクライアントの設定部分（Windows98）

これを見る限り、VPNのために、仮想モデムを用意している風に思える。

  Windows98の頃は、常時接続なんぞなく、ダイヤルアップが主流だった記憶がある。
  「外部からの接続＝ダイヤルアップ」だった事を考えれば、PPPを拡張して、
暗号化通信をできるようにしようという発想は、普通だと思う。


  さて、PPTPのクライアント側の設定。
  よく考えると、いい加減な設定していた。

PPTPクライアントの設定部分（Windows2000pro）

よくよく考えると、LCP拡張が何かを知らずにチェックを入れているし、 マルチリンクも何かを知らないのに、チェックを入れている。 何も知らずにやっていると、トラブル発生時に、原因調査ができないため 知っておく必要があると思った。

  いつもの如く、パンドラの箱を開けるため、助っ人になる本を取り出した。
  「PPP 設計・実装・デバッグ」（James D.Carlson著：榊原一矢 訳：オーム社）

  だが、この本は開発者や技術者が読む本で、事務員が読む本ではない。
  そのため、本を読み始めてから5分も立たないうちに

     難しすぎて、わからへん （ＴＴ）

  だった。

  そこで、正面突破をやめて、調べたい用語の部分だけを拾いだして
読む事にしてみた。

  まず、「LCP拡張」に注目してみた。
  本だけでなく、Microsoftの技術サポートや、TechNetなども探してみたら、
次のような記述を発見した。

  RFC1570を調べると、どうやらコールバックに関する文書であることが
わかった。
  コールバック。ダイヤルアップの時代、電話代が課金制だったり、高かったりする。
  そのため、相手に電話代を負担したい場合、相手に料金を負担できるよう、
コールバックできるように、考え出された物らしい。
  コールバック。より調べると、ややこしい事がわかる。
  Microsoftが独自に「Microsoft CBCP」という独自規格を作っているからだ。

  さすがに、コールバックは使わないので、泥沼にハマる前に、逃げる事にします。

  だが、いくら調べても「残り時間」や「識別パケット」に該当するものは
見つからなかった (--;;


  マルチリンクを調べてみた。

マルチリンク

低速のモデムをいくつか使って、高速通信にみせる方法。 下手に高速回線を使うよりも、モデムを複数使うことによって、 費用のかからない通信をする場合がある。

  ADSLや光ファイバーなど、ブロードバンドの時代から
インターネットを使い始めた人には、ピンとこないが、
ダイヤルアップ接続だと、最大でも56Kの速度しか出ない。
  それも56Kというのは、色々な技を駆使した結果であって、
9600バイトの時代などもあった。とにかく遅かった！

  「9600バイトの時代」と書いたため、LILOのsmiffさんから、ご指摘を頂いた。

　通信速度の単位は、bps(bits per second) で、56kbpsといえば1秒間に
56キロビット、9600bpsなら9600ビットの転送速度ということです。
1バイトは8ビットとして扱われるのが一般的ですので、9600bpsでは
単純計算して毎秒1200バイトということになります。
更に、この単純計算が成り立つのは、同期通信の場合で、RS-232Cでモデムに
つないでいた頃は調歩同期といって、1バイト毎に頭とお尻に区切りマーク
（スタートビットとストップビット）をつけていたので、速くても
毎秒960バイトしか送れませんでした。

　あの当時は、1200bpsから2400bps+MNP5になっただけで、すんごく高速になっ
たと感動していたんだがなぁ。

  うーん、ビットとバイトを混同した、おバカな私 (^^;;
  Smiffさんの文章を読んでいると、昔の通信速度の遅かった時代の事が
伝わってくる。体験者は語るで、実感がこもっています。


  あと、通信費も、今のように常時接続で数千円というような格安ではなかった。
  安くしかも早くデータを送るための苦心が見えてくる。

PPPの接続確立の手順
	まずは、物理層から最初の段階のLCPへ行く。 そこで、どういう通信方法を行なうのか決める。 例えば、最大転送パケット長、コールバックするのか マルチリンクにするのかなど そして、認証・LQMの段階へ上がる。 最後に、NCPという段階に上がる。 ここでは、パケットの圧縮をしたり、 パケットの暗号化をしたりする。

  クライアントの設定の「ソフトウェアによる圧縮」について、触れてみます。
  PPP通信の場合、データの圧縮機能がついている。
  最初、私は「ソフトウェアによる圧縮」は、PPPの圧縮機能だと思った。
  NCPを細かく見ると、データ圧縮の機能がある。

NCPを細かく見ると

NCPの段階ではCCP（データ圧縮）とECP（暗号化）の２つの役目がある。 圧縮の方が先に行なわれ、そして、暗号化が行なわれる。

  ここで、圧縮する目的は、データを圧縮する事により、ダイヤルアップという
低速回線でも、スムーズにデータを送信する事を可能にする事だ。

  さて、「圧縮→暗号化」という順序になっている。
  それはなぜなのか、本に２つの理由が書かれていた。

  どうも納得がいかないのだが、証明する術を知らないので、断念します (--;;
  「断念するな！ 証明しろ！」という声があるかと思いますが、私は反論します。
  証明できたら、とっくの昔に事務員を辞めて、技術者になってまーす (^^)V

  いつもの決まり手「事務員です」が決まった

  「ソフトウェアによる圧縮」とCCPとの関連性についても、調べてみたが
結局、わからないままになってしまった (--;;


  ここで思ったのは、ダイヤルアップのプロトコル「PPP」の奥の深さだった。
  通常、ダイヤルアップが簡単にできるように、プロバイダーの方から
設定のためのソフトが付いている。
  そのため、コールバック機能や、データ圧縮の機能などがついている事など、
全く気が付かない。

  だが、そのブラックボックスの封印を開けると、知らない事ばかりが
噴出したので、パンドラの箱を開けてしまったなぁという感じだった。

  今回、相当、歯切れが悪い感じで逃げてばかりいます。
  「手を抜くな！」を言われそうなので、次のように反論します。

　事務員なので、わかりませーん (^^)V


  さて、前の方で触れました、パスワード認証の話です。
  最初、私は、CHAPと、MS-CHAPv2の違いを間違えていた理由ですが、
本を読んでいた時に、CHAPの説明の部分を、誤ってMS-CHAPv2と認識してしまった。
  天才的なぐらいの勘違いだと思ってしまう今日この頃 (--;;

  誤解が解けた理由は、MS-CHAPとMS-CHAPv2の違いを書かねば、突っ込みが
来そうな感じがしたので、調べてみた結果、見事に、誤解をしていた事に
気がつきました。

  さて、CHAPというのは、元々、ダイヤルアップのパスワード認証が
暗号化されていない方法（PAP方式）を使っていたため、パスワードが丸見えでした
  簡単に盗聴されるため「なりすまし」の危険性が高かったため、
それを防止するために、改良されたものだ。

  だが、ＭＳは独自規格が大好きなので、独自規格のパスワード認証として
MS-CHAPが作られた。

MS-CHAPによるパスワード認証の概略

CHAPとの違いは、不可逆暗号にMD4を使っている点と 暗号化の上に、さらにDESという暗号をかけている点がある。

  CHAPよりも、頑丈になった感じがする。
  何せ、不可逆暗号（ハッシュ関数）の上に、さらにDESを使うからだ。
  しかし、セキュリティーの専門家から、いくつかセキュリティーホールが
指摘されたため、MS-CHAPの改良版であるMs-CHAPv2が世に出た。

MS-CHAPv2によるパスワード認証の概略

MS-CHAPとの違いは、不可逆暗号にSHA1を使っている点以外に クライアント側もランダムな文字列を、サーバーに送信している点にある。

  MS-CHAPと、MS-CHAPv2とでは、それぞれ別の不可逆暗号（ハッシュ関数）が
使われている。この2つの違いは、以下の通りです。

不可逆暗号（ハッシュ関数）

MD4の場合、任意の文字列を128ビットの文字列に変換する。 SHA1の場合、任意の文字列を260ビットの文字列に変換する。

 
  最初、ビット数の違いからSHA1が安全と思ったが、そうではないようだ。
  力づくで解読する場合、出力されるビット数なんて関係ないのではと思った。

  調べてみると、MD4は暗号解読方法が見つかったからだという。
  そのため、MS-CHAPの利用は避ける必要がある！

  ただし、MS-CHAPv2は100%安全かというと、そうではない。
  DESの暗号は、早ければ1日で解読されている上、SHA1も、力づくで解読すれば
解読可能になってしまう。
  そのため、MS-CHAPv2では、定期的にパスワードを変更するのが無難といえる。


  そういえば、実際に、やりとりするデータの中身の暗号化について、
触れていなかったので、触れてみます。

  PPTPの場合、暗号化の方式は、MSのお得意な独自規格の方式である
MPPE(Microsoft PPE)を使っている。

  MPPE(Microsoft PPE)を調べてみると、Webに目を疑うような記述を発見した。

  CCPは、先に触れました通り、データ圧縮の事である。
  ホンマかいなと思い、本を広げてみると、同じ事が書かれていた。

　なんで、圧縮と暗号が一緒やねん！

  どうやら、CCPとECPを一緒に処理しているという。

  圧縮と暗号。少し考えると納得できる所がある。
  確かに、圧縮したデータなんぞ、読めるわけがないので、
一種の暗号といっても、おかしくない。

  だが、なぜ、圧縮技術を改良してMPPEという暗号化方式を作ったのか
調べてみたが、わからなかった。MSの行動は謎だ・・・。


  Webで色々調べていると、恐ろしい話もわかった。
  Windows95、98、98SEで、PPTPを使う場合だ。

  MPPEは、40ビット、56ビット、128ビットの3種類の暗号の強度がある。
  暗号化の強度は、ビット数で決まる。

  ヤマハのRTA55iは、40ビットと128ビットをサポートしている。

  ここで、注意なのは、Windows95、98、98SEの場合、初期状態では、
MPPEの暗号強度は40ビットしか使えない事にある！

  DESの56ビットでも、1999年に、1日で破られるようになった。
  それより、ビット数の少ない、MPPEの40ビットは、もっと簡単に破られる。

  そのため、もし、Windows9X系で、PPTPを使われる際は、Microsoftのサイトの
「ダイヤルアップ ネットワーク 1.4 アップグレード プログラム」
から修正プログラムをダウンロードされるのをお勧めします。

  実は、私の場合は、会社のアクセス実験などを終えた後に、これを発見したため、
血の気が引きそうになった。幸い、極秘資料などはダウンロードしていないので、
盗聴されても、問題はないのだが、暗号化だと思って安心していただけに、
この事実を知った時は、外部からの遠隔操作の恐ろしさを感じた。

  普段なら、MS嫌いの私なので「MSは、アホか！」となるが、
なぜ、40ビットにせざる得ないのか、理由を知ると、MSには非がない事がわかる。

  その理由は、アメリカの暗号輸出規制にあった

  Windows9X系が世に出た時は、アメリカの暗号の輸出規制は厳しかった。
  理由は、犯罪組織やテロリストが連絡を取り合う際に、通信が暗号化されてしまうと
全く傍受できなくなる事から、危機管理という名目で、外部への暗号の輸出規制を
かけていた。

  そのため、MSは、当時、アメリカの輸出規制に触れないギリギリの所にあった
40ビット暗号を、海外向けに出したという。
 そのため、Windows9X系は40ビットの暗号しか使えないという。


  40ビットの暗号規制の話を書くと、「UNIXのパスワードの暗号は昔から
56ビットのDESやで。輸出規制に引っ掛かるのとちゃうか？」という
突っ込みがきそうなので、それについても、調べてみました。

  認証用に限り、例外的にOKだったという。
  ただし、ソースコードは外に出せなかったという制限付き。
  ちなみに、1997年1月7日に、半年ごとに届け出という条件で
DESの輸出規制が緩和されています。

  アメリカ出身の、Sun、AIX、HPUXなどのUNIXの暗号化パスワードは、
海外向け製品にも、DESを使っても問題なかったという。

  こういう事を書くと「現在の輸出規制は、どうやねん」という声がありますので、
キチンと書くことにします。

  現在では、日本に対しての輸出規制は撤廃されています。

  そのため、MSがWindows9X系の修正プログラムを堂々と出せるようになりました。


  アメリカの暗号輸出規制の話は、この奮闘記を編集したのをキッカケに
知ったわけではない。実は、もっと前から知っていた。

  1996年の終わりの、大学4回生の時だった。
  中学の時の友人Ｙ君が「ねぇねぇ、PGPを使わない？」と言ってきた。
  「PGPって何？」だったので、Ｙ君に聞くと、メールの文章は
平文に流れているため、機密事項などをメールで流すと、盗聴されたりするという。
  そこで、PGPを使って文章を暗号化して、相手に送ると、盗聴されないという。

  相当、強力な暗号化を使っている。公開鍵でロックして、メールを送信する。
受信側は、自分しか知らない秘密鍵を使って、メールを開く。

  早速、私は研究室のUNIXにPGPをインストールして、Ｙ君と数回、
PGPを使ったやりとりをしていたが、どうも私のインストール方法が悪かったのか
Ｙ君から送られたPGPのメールを開ける事ができなかった。

  この時、PGPの事を調べていると、アメリカの暗号輸出規制の話が
いくつかのWebで載っていた。
  アメリカの暗号輸出規制の問題のため、慎重の行動を求める注意書きがあった。

  そのPGPだが、輸出規制があったにも関わらず、なぜ、他国に流れたのか。
  理由は、笑えるような簡単な方法で輸出できたためだった。

  なんと、PGPのアルゴリズムを全て印刷して、本という形で出版して
海外へ持ち出したという。アメリカでは出版の自由があるため、
どんな情報でも出版に規制をかける事ができない。
  古典的なやり方だが、見事に、法の抜け穴を使ったと言える。

  この事をキッカケに、アメリカの暗号輸出規制を知った。
  先に、DESは認証の場合にのみ、例外的に輸出可能だと書いた。
  だが、プログラムソースは輸出規制対象なので、FreeBSDのパッケージを
アメリカのサイトからダウンロードできなかったという。
  認証部分のソースコードに、DESの暗号化が含まれているからだった。

  大学４回生の時、私は、FreeBSDをインストールして遊んでいた。
  FreeBSDの本の後ろのコメントの所に、「パスワードの暗号化に使われるDESは
第3国で作られた」と明記されているのを見て「嫌すぎる」と思った事がある。
  まさに、輸出規制のため、みんなが慎重になっていたという。

  その輸出規制も2000年7月17日に撤廃されました。

  コンピューター関連の同時のニュースを調べると、今だと、ウソのような事が
載っていた。
  例えば、「RedHat6.2がアメリカからダウンロードできる」などなど。

  めでたく、DESの解禁なのだが、安全性というと、1999年の暗号破りの
コンテストで、1日で破られたという。
  DESが出た当時は、安全と言われていたが、急速なコンピューターの性能アップで
1日で、暗号が破られた結果になった。

  私がUNIXと出会った1994年、DESは破られないと言わんばかりに、
/etc/passwsのファイルに、堂々と暗号化パスワードが載っていた。
  当時、シャドウ・パスワードというのがなかった。

  シャドウ・パスワードが出来た後でも、NISを使っている場合だと
yppasswdのコマンドで、簡単に暗号化パスワードが出てきた。
  （あくまでも、1990年代半ばの話です）

  それから、NISのパスワード管理は、現在、どうなっているのか、わからないが
当時は、暗号化パスワードが丸見えだった事を懐かしく思う。

  最後に2点だけ暴露します。

まとめ

  PPTPの接続に挑戦したのだが、ルーターの設定や接続状態を理解するのに
四苦八苦しました。
  ダイヤルアップの話が、こんなにも奥が深いとは思いませんでした。

  PPTPの実用性について、私からの感想としましては、以下の事を守れば
この数年は問題ないと思います。

  ただし、コンピューターの性能が飛躍的にアップしているため、
PPTPは、10年、20年後は安全というわけではありません。

  VPNには、もう一つ、IPSeC方式があります。
  詳しい事は、IPSeC導入で書きます事にして、簡単に違いを書きます。

  PPTPとIPSeCとの違い。

  これを見る限り、PPTPの方がダメなような気がするが、そうとは限りません。
  リモートアクセスに関しては、PPTPの方が上です。
  IPSeCの場合、ルーター同士の通信、端末同士の通信は比較的容易ですが、
端末とルーターという、リモートアクセスの組み合わせは、苦手にしています。
  高い装置を買う必要が出てきます。
  その点、PPTPだと、比較的、手軽に設定ができます。

  用途によって選ぶのが賢い方法だと思います。

  ただ、Linuxで、PPTPサーバーが構築できなかったのは、
非常に無念さを感じてしまう今日この頃です・・・ (--;;
  LinuxでPPTPサーバーは「システム奮闘記：その２７」をご覧ください。