システム奮闘記：その27

VPNサーバー構築 PPTP暗号通信

はじめに

  「システム奮闘記：その25」(ヤマハルーターRTA55iでVPN通信(PPTP))で
VPNを取り上げた時、LinuxでVPNサーバー(PPTP)を構築するのを断念した。
  理由は、VPNサーバーを構築するのには、カーネル再構築をする必要があると
各所のWebサイトで書いてあったからだ。

  カーネルの再構築。
　以前、「システム奮闘記：その23」(バックアップ。RAID、UPSの導入)で
導入したCD-RWで、増設する際、カーネル再構築が必要だったため、
一度は挑戦したものの、ネットワークにつながらなくなったりなど
問題が発生したので、恐くなってやめた。

  それ以来、カーネル再構築は腫れ物を触る感じになった


  さて、「システム奮闘記：その25」(ヤマハルーターRTA55iでVPN通信(PPTP))で
LinuxでVPNサーバー構築を断念したが、素直に諦めたわけではなかったので

　LinuxでVPNサーバーを構築したい!

　という気持ちで燻っていた。
  私は事務員なので「技術者としての意地を！」という気持ちは全くない。
 
  理由は、システム奮闘記のネタが減るという危機感からだった。

  実は、営業マンに1人1台、ノートパソコンを持たせて、本社へ接続して
データのやりとりをする計画が出ている。
  このまま自力でVPNサーバーが構築できないと、VPNサーバー構築の話は
業者に持っていかれてしまう。
  外注で構築してもらった話を書いたって面白い話なんぞ書けるわけがない。
  そのため、失敗談などのネタを作るためにも「何が何でも自力で構築せねば」
と思った (^^;;

VPNサーバー構築の準備

  さて、PPTP方式のVPNサーバー構築の方法が書いてあるWebサイトを
探したら、いくつか見つかった。
  まずは、http://www.e-ryoichi.net/index.htmlを方法を見てみる事にした。

  やはりカーネル再構築の話が出ていた。
  諦めて、色々なサイトを見てみたが、同じだった。

  でも、カーネル再構築なしでできる方法がないかと考えた。
  ふと、もう一度、上に書いたURLのサイトを見てみた。
  その時、こんな記述が目に入った。

(6)PPPのアップデート及びPoPToPのインストール
   これは簡単です。
   ダウンロードしてきた ppp-2.4.1-3mppe.i386.rpm と pptpd-1.1.3-1.i386.rpm の
   2つのファイルをいつものコマンドでインストールするだけです。

  これを見た私は「もしかして、これだけでVPNサーバーができるかも」と
トンデモナイ勘違いを起こしてしまった。

  トンデモナイ勘違いの理由だが、色々なサイトを見ている時に、
MPPEのパッチをRPMファイルであてるなどが色々な記述があった。
  あまり頭の中が整理されていない状態の時に、カーネル再構築をせずに済む方法を
探していただけに、この文章だけに強く反応してしまった。


  さて、「これでカーネル再構築をせずに済む」と喜んだ私。
  手元には、次のファイルがある。

  ppp-mppe-2.4.1-7.i386.rpm
  pptpd-1.1.3-4.i386.rpm

  早速、インストールをしてみた。
  次に設定ファイルの設定を行なった。

# CHANGE TO SUIT YOUR SYSTEM
lock

## turn pppd syslog debugging on
#debug

## change 'pptpd' to whatever you specify as your server name in chap-secrets
#name pptpd
name pptp-server

proxyarp
bsdcomp 0

# This option applies if you use ppp with chapms-strip-domain patch
#chapms-strip-domain

# These options apply if you use ppp with mppe patch
# NB! You should also apply the ChapMS-V2 patch
-chap
-chapms
+chapms-v2
mppe-128
mppe-stateless

# These options will tell ppp to pass on these to your clients
# To use ms-wins or ms-dns in options.pptpd it must exist in /etc/resolv.conf
#ms-wins your.server.here
ms-dns （DNSサーバーのIP）

　次にpptpd.confファイルを見てみる。

#################################################################################
# Sample PoPToP configuration file
#
# for PoPToP version 1.1.4
#
################################################################################
# TAG: speed
#
#	Specifies the speed for the PPP daemon to talk at.
#
#speed 115200

# TAG: option
#
#	Specifies the location of the PPP options file.
#	By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/options.pptpd

# TAG: stimeout
#
#	Specifies timeout (in seconds) on starting ctrl connection
#
# stimeout 10

# TAG: debug
#
#	Turns on (more) debugging to syslog
#
#debug

# TAG: bcrelay <if>
#
#	Turns on broadcast relay to clients from interface <if>
#	Not yet implemented this way. Read README.bcrelay
#
#bcrelay eth1

# TAG: localip
# TAG: remoteip
#
#	Specifies the local and remote IP address ranges.
#
#	You can specify single IP addresses seperated by commas or you can
#	specify ranges, or both. For example:
#
#		192.168.0.234,192.168.0.245-249,192.168.0.254
#
#	IMPORTANT RESTRICTIONS:
#
#	1. No spaces are permitted between commas or within addresses.
#
#	2. If you give more IP addresses than MAX_CONNECTIONS, it will
#	   start at the beginning of the list and go until it gets 
#	   MAX_CONNECTIONS IPs. Others will be ignored.
#
#	3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#	   you must type 234-238 if you mean this.
#
#	4. If you give a single localIP, that's ok - all local IPs will
#	   be set to the given one. You MUST still give at least one remote
#	   IP for each simultaneous client.
#
#localip 192.168.0.1
#remoteip 192.168.0.234-238,192.168.0.245
localip 192.168.1.XXX  ←　PPTPサーバーのIP
remoteip 192.168.1.10-20 ←　接続したクライアントに割り当てるIP
# or
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245

　次に、cha-psecretsファイルを見てみる。

####### redhat-config-network will overwrite this part!!! (begin) ##########
####### redhat-config-network will overwrite this part!!! (end) ############
#* * &/etc/samba/smbpasswd *
pptpuser pptp-server "（パスワード）"  *

　最後に/etc/modules.confファイルの設定だ。

  設定ファイルを以上のように書いた。設定ファイルは問題なく書けていた。

  そして、次のような実験を行なった。

Windows98でVPNサーバーに接続

  結果は・・・

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

  これでVPNサーバーを構築できたので、ネタが減らなくて済んだという
安堵感で一杯だった。

  そして、確認のため、クライアントをWindows2000proに変えて実験してみた。

Windows2000ProでVPNサーバーに接続

  結果は・・・

  エラーが出た (TT)

  なんで、Windows2000proだと認証が受け付けてくれないのか。
Windows98だと問題なくいけたので、クライアント側の設定の問題だろうと考え
googleで症例などを探してみた。

  Windows2000で使われる暗号化の強度が触れられていた。
  私は「まさか、Windows2000もMPPE40ビットしか対応していないのでは」と考え
調べてみると、なにやら対応するソフトらしく物を見つけた。
  藁をもすがる気持ちで、インストールをして、再度、実験をしたが・・・

  エラーが出た (TT)

  「これはドツボにハマるぞ・・・」と思いつつ、Windows2000Proでの
症例を探してみたが、これと言った物は見つからない。

  なんでだろうと思いつつ、もう一度、Windows98で通信を行なってみた。
  うまく接続している。ふと、通信状態を見てみた。

Windows98の接続状態

  これを見て「なぜ、TCP/IPとしか出ていないのだろうか?」と思った。
自宅のWindows98から、会社のVPNルーターへ接続した時は、
上図の赤丸の部分には、他の内容の表示も出ていたので不思議に思った。
  そこで、サーバー側のログを見たら、思いがけない事がわかった。

Jan 30 13:56:01 penguin /etc/hotplug/net.agent: assuming ppp0 is already up
Jan 30 13:56:01 penguin modprobe: modprobe: Can't locate module ppp-compress-18
Jan 30 13:56:02 penguin modprobe: modprobe: Can't locate module ppp-compress-18
Jan 30 13:56:02 penguin pppd[2774]: MSCHAP-v2 peer authentication succeeded for pptpuser
Jan 30 13:56:02 penguin pppd[2774]: found interface eth0 for proxy arp
Jan 30 13:56:02 penguin pppd[2774]: local  IP address 192.168.1.138
Jan 30 13:56:02 penguin pppd[2774]: remote IP address 192.168.1.10
Jan 30 13:56:02 penguin pppd[2774]: CCP terminated by peer
Jan 30 13:56:02 penguin pppd[2774]: Compression disabled by peer.
Jan 30 13:56:21 penguin pppd[2774]: LCP terminated by peer
Jan 30 13:56:21 penguin pppd[2774]: Modem hangup

  もしかして、暗号化していない通信をしていたのでは・・・  （・・）
  そこで、Windows98側の設定を見てみると、案の定、暗号化通信をしていなかった。

Windows98の設定状態

  やはり暗号化通信をしていなかった事がわかった。
  そこで、暗号化の所にチェックを入れて接続してみたら・・・

  エラーが出た (TT)

  ここで、ようやくサーバー側に問題がある事がわかった。
  それにしても、まさかデータの暗号化をせずに、VPN接続ができるのには驚いた。

  なぜなら、サーバー側の設定で、暗号の種類をMPPE128ビットだけと
設定しているはずだからだ。

カーネル再構築

  LinuxでVPNサーバー構築は、双六ゲームの如く、振りだしに戻された。

  やはりカーネル再構築は避けて通れない！

  しかし、腫れ物に触る感じがする。でも、この壁を突破しないと前に進まない。
  もちろん、VPNサーバー構築のネタも業者に持っていかれる (^^;;

  幸い、実験サーバーを使ってカーネル再構築を行なえば、例え、設定が
グチャグチャになっても困る事はない。
  そこで清水の舞台から飛び降りる気分で、カーネル再構築に挑戦する事になった。

  そこでカーネルの再構築について触れている次の本を取り出した。
  「RedHat7.3対応で作るLinux7」（サーバー構築研究会：秀和システム）
  本の題名の通り、使っているLinuxは、RedHat7.3です。
  そして本の通りにコマンドを打った。

  まずは、カーネル再構築のためディレクトリーの移動を行なう。
  cd /usr/src/linux-2.4

  そして、PPTPの暗号化にカーネルを対応させるため、パッチを充てる。
  実験に使ったカーネルは、Linux-2.4.18-3 （RedHat7.3のデフォルト）
  linux-2.4.16-openssl-0.9.6b-mppe.patch.gz を使う。

  zcat linux-2.4.16-openssl-0.9.6b-mppe.patch.gz | patch -p1

  パッチが充てれば、いよいよカーネル再構築の設定を行なう。
  make xconfigコマンドを叩くと次の画面が出てくる。

make xconfigを打つと出てくる画面。

  ここで「Networking options」を選択する。
  そして、PPPに関する所を全て「M」（モジュール）に選択する。

  そして、画面を終了させてから make dep コマンドを叩く。
  次に、カーネルをコンパイルさせるため make bzImage を叩く。
  
  コンパイルが問題なく終われば、make modulesコマンドを叩く。
  これも無事、終えると、今度は、モジュールインストールのために、
make modules_installコマンドで使ってインストールを行なう。

  さて、カーネルのインストールだが、cd arch/i386/bootでディレクトリー移動を行なう。
  そして、できたbzImageファイルを /boot ディレクトリーに
  vmlinuz-2.4.18-3custom というファイル名で保存させる。

  カーネルが、Linux-2.4.18-3の場合、初期状態で、カーネルのファイルの後ろに
「custom」が付くようになっている。これは、元々あるカーネルと別々に
保存させるためにある。再構築したカーネルが立ち上がらなくなる危険性があるので、
危険性回避のため、そういう仕組みになっている。

  同様に、System.mapのファイルも、/bootフォルダに System.map-3custom という
ファイル名で保存を行なう。

  そして、私の場合、起動はLILOで行なっているので、/etc/lilo.confを書き換える。
  そして、リブートして、新しいカーネルで起動させる。

  まさに、本の通りに行なった。

  本の通りに行なっているので無難なはずだが、フタを開けてビックリ。

  ネットワークがつながらへん (TT)

  ここで、再起動させて、元々あるカーネルで起動させる。
  そして、カーネル再構築に挑戦する。
  ネットワークがつながらないという事は、必要なはずのネットワーク関係の
オプションが無効になっている可能性が高い。
  だが、何を有効にして、何をモジュールにして、何を無効にして良いのか
全く見当がつかない。そこで、思いついたのは

  わからない物に関しては全て有効にする！

  どうせ、実験サーバーの性能は、Celeron1GHz RAM256M なので、
ちょっと余分なオプションが増えたぐらいで重くなったりする事はない。
  使える資源は有効活用(?)という事で、どんどん気前良く「Networking options」
を有効にしていった。

  そして、カーネルの再構築のためコンパイルを行なったのだが・・・

  コンパイルエラーが出た (TT)

>make[2]: 出ます ディレクトリ `/usr/src/linux-2.4.18-3/arch/i386/lib'
make[1]: 出ます ディレクトリ `/usr/src/linux-2.4.18-3/arch/i386/lib'
make[1]: 入ります ディレクトリ `/usr/src/linux-2.4.18-3'
ld -m elf_i386 -T /usr/src/linux-2.4.18-3/arch/i386/vmlinux.lds -e stext arch/i3
86/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o init/do
_mounts.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kerne
l.o mm/mm.o fs/fs.o ipc/ipc.o  drivers/char/char.o drivers/block/block.o drivers
/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o driv
ers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/
driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pcmcia/pcmcia
.o drivers/net/pcmcia/pcmcia_net.o drivers/pnp/pnp.o drivers/video/video.o drive
rs/usb/usbdrv.o net/network.o abi/abi.o /usr/src/linux-2.4.18-3/arch/i386/lib/li
b.a /usr/src/linux-2.4.18-3/lib/lib.a /usr/src/linux-2.4.18-3/arch/i386/lib/lib.
a --end-group  -o vmlinux
net/network.o: In function `ip_vs_init':
net/network.o(.text.init+0x6e1): undefined reference to `ip_vs_control_cleanup'
make[1]: *** [kallsyms] エラー 1
make[1]: 出ます ディレクトリ `/usr/src/linux-2.4.18-3'
make: *** [vmlinux] エラー 2

  エラーの内容を見た時

  ip_vs_initって何?

　だった (^^;;

  気前良く「Networking options」を有効にしたため、こんなエラーが出た。
  ip_vs_initは何かは、わからないが、

  エラーが出る物は不要のはず！

  そんな感じで、とてもいい加減な判断に基づいて、カーネル再構築のための
オプションを選んで、コンパイルをかけて、コケたら、該当する物は、
オプションから外して、再コンパイルを行なうという事を、2回ぐらい繰り返した。

  そして、なんとか、コンパイルが通った！！
  

  やれやれと思い、新しいカーネルで再起動した。
  そして、PPTPを動かすために、Webの説明通りに設定ファイルの設定した。
  だが・・・

  今度は認証すらダメになった (TT)

  だった。
  説明通りの手順で行なったのに、うまくいかなかった。

Feb  2 12:58:44 penguin pptpd[1255]: CTRL: Client 192.168.1.133 control connection started
Feb  2 12:58:44 penguin pptpd[1255]: CTRL: Starting call (launching pppd, opening GRE)
Feb  2 12:58:44 penguin pptpd[1255]: GRE: read(fd=5,buffer=804d720,len=8196) from PTY failed: 
status = -1 error = Input/output error
Feb  2 12:58:44 penguin pptpd[1255]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
Feb  2 12:58:44 penguin pptpd[1255]: CTRL: Client 192.168.1.133 control connection finished

  これを見ただけでは、原因が何であるか、さっぱり理解できなかった (--;;
  ただ、通信に失敗している事しか情報が得られない。

  もう1度、カーネルの再構築を行なったが、結果は同じだった・・・ (--;;


  そこで別のホームページを探してみる事にした。
  http://www.komoto.org/vpn/pptp-linux.html

  OSを再インストールして、綺麗な状態(?)にしてから挑戦する事にした。

  ppp-2.4.2_cvs_20030610.tar.gzをダウンロードしてからWebサイトに
書いてある通りに展開した。
  そしてsh mppeinstall.sh /usr/src/linux-2.4.18-3で走らせたが・・・

   エラーが出た (TT)

  そこで、RPM形式のppp-2.4.2_cvs_20030610-1.i386.rpmを探してダウンロードした。
  問題なくインストールができたので、ホッとした (^^)  

  これでいけるかなぁと思いカーネルの再構築を行なった。
  コンパイル中は「早く終わらないかなぁ。早く結果がみたい」とワクワクさせる。
まるで、小学生が翌日が遠足で夜が眠れない気分だ。童心に帰れる一時だ。
  さて、再構築が終わり、再起動をかけてから、PPTPを動かしてみた。
  そして、VPN通信を試みた結果は・・・

　やっぱり動かへん (TT)

  だった。

  どこかで誤っている可能性があるので、もう1度、同じ事を再現してみたが、
やはり駄目だとわかった。


  ここまでくれば意地になる私。何が何でも成功させたい！
  次に、http://www.itmedia.co.jp/help/howto/linux/vpn/02.htmlのサイトの方法を真似する。

  linux-2.4.16-openssl-0.9.6b-mppe.patch.gz
  ppp-mppe-2.4.1-7.i386.rpm
  ppp-2.4.2-b3.i386.rpm

  を用意した。

  linux-2.4.16-openssl-0.9.6b-mppe.patch.gzでカーネルにパッチをあてる。
  そして、カーネルの再構築。もちろん、Webサイトに書いている通りに、
PPPの部分はモジュールにした。

  そして、ppp-mppe-2.4.1-7.i386.rpmとppp-2.4.2-b3.i386.rpmをインストールした。
  そして、VPN通信を試みた結果は・・・

　やっぱり動かへん (TT)

  だった。トコトンVPNに嫌われている・・・

PPTP向けのLinuxカーネル再構築のための設定

  色々、挑戦してみたが、全く駄目だった。
  もう嫌。カーネル再構築をしてVPNサーバーを導入するのは、
私には、まだ、早すぎた内容ではないかと思い始めた。
  技術力が向上するまで、VPNサーバー構築は保留にしようと思いつつも、
調べていくと、次のページを発見した。
  http://www8.ocn.ne.jp/~penko/pptp.htm

  これが駄目なら諦めようと思って、Webサイトに書いてある通りに
設定を進める事にした。
  最初に、Linuxを再インストールをした。

  インストールが終わると、3つのソフト（うち2つはパッチ）をダウンロードした。

   ppp-2.4.1.tar.gz
   ppp-2.4.1-openssl-0.9.6-mppe-patch.gz
   ppp-2.4.1-MSCHAPv2-fix.patch.gz

  そして、ppp-2.4.1.tar.gzを展開してから、ppp-2.4.1-openssl-0.9.6-mppe-patch.gzと
ppp-2.4.1-MSCHAPv2-fix.patch.gzのパッチを充てる。
  configureをしたあと、makeでコンパイル。そして、make installを行なった。

  そして、PPTPのインストール。
  こちらは、手元にあったpptpd-1.1.3-4.i386.rpmをインストールをした。

  次に、カーネルの再構築を行なう。
  まずは、カーネル再構築のためディレクトリーの移動を行なう。
  cd /usr/src/linux-2.4

  そして、PPTPの暗号化にカーネルを対応させるため、パッチを充てる。
  linux-2.4.16-openssl-0.9.6b-mppe.patch.gzを使う。

  パッチが充てれば、いよいよカーネル再構築の設定を行なう。
  今度は、make menuconfigコマンドを叩くと次の画面が出てくる。

make menuconfigを打つと出てくる画面。

  オプションを選ぶ際は、GUIで選択できるmake xconfigを使うよりも
make menuconfigを使う方が良いみたい。
  なぜなら、make xconfigを使うと、ほとんどのオプションを選択していない状態になるようだ。
  そのため、1つ1つ、オプションを見て、必要な場合は、チェックを入れていく
必要がある。結構、手間がかかる上、知識も必要になる。
  make menuconfigを使うと、現在の状態にプラスαでオプションに
チェックが入っていたり、モジュールになっていたりする。
  これだと、必要な部分だけ見れば良いので、他の知識がなくても大丈夫。

  しかし、上に挙げた話は、あくまでも私の経験則で正しいとは言いがたい (^^;;

「Networking options」を選択する画面

  上図のように、PPPに関する所を全て「M」（モジュール）に選択する。
  Webの説明には、PPP関連の所は全てモジュールにしないと
肝心の暗号部分のMPPEがコンパイルされないという。

  そして、画面を終了させてからmake dep コマンドを叩く。
  次に、カーネルをコンパイルさせるため make bzImage を叩く。
  
  コンパイルが問題なく終われば、make modulesコマンドを叩く。
  これも無事、終えると、今度は、モジュールインストールのために、
make modules_installコマンドで使ってインストールを行なう。

  さて、カーネルのインストールだが、cd arch/i386/bootでディレクトリー移動を行なう。
  そして、できたbzImageファイルを /boot ディレクトリーに
  vmlinuz-2.4.18-3custom というファイル名で保存させる。
  同様に、System.mapのファイルも、/bootフォルダに System.map-3custom という
ファイル名で保存を行なう。

  私の場合、起動はLILOで行なっているので、/etc/lilo.confを書き換える。
  そして、再起動して、新しいカーネルで起動させた。


  いよいよ、VPNサーバーが稼働するかどうか確かめた。すると
  見事、接続できた！！ (^^)V

  さて、実際にデータ転送などができるか確認をしてみたら・・・
  全く通信ができへん (TT)

  「なんで？」と思ったが、Webサイトの説明を読むと、すぐに理由がわかった。
  パケットを転送する設定をする必要があった。
  echo 1 > /proc/sys/net/ipv4/ip_forward

  そして気を取り直して、再度、ファイル転送を行なうと
  見事、成功！！ (^^)V

  これにより、ようやく長い格闘が終わったかに見えた。

PMTUブラックホール問題

  しかし、そうは問屋が卸さないのは毎度の事。
  自宅に帰って、自宅と会社をVPNで結んでみた。

  Windows2000Pro、WindowsXP（HOME版）では接続ができたのだが・・・

     Windows98では接続が切られる (TT)

切断された様子

  pingは問題なくできるが、データ転送や、VPN接続を使って、
社内向けのホームページを見ようとすると、接続が切断される。

  原因が全くわからない上、どこから原因を調べたら良いのか全く見当すらつかない。

  もし、会社のマシン（Windows98）でも、接続が切断されたら、Windows98の
固有の問題と考えて、そこを出発点にして問題解決への糸口を探すのだが、
会社のマシンで、社内での接続には問題ない。

  翌日、出社して、接続が切断された原因を探るため、ログを見てみた。

Feb 14 22:16:02 pptp pptpd[2575]: CTRL: Client （接続元IP） control connection started
Feb 14 22:16:02 pptp pptpd[2575]: CTRL: Starting call (launching pppd,opening GRE)
Feb 14 22:16:02 pptp pppd[2576]: pppd 2.4.1 started by root, uid 0
Feb 14 22:16:02 pptp pppd[2576]: Using interface ppp0
Feb 14 22:16:02 pptp pppd[2576]: Connect: ppp0 <--> /dev/pts/4
Feb 14 22:16:02 pptp /etc/hotplug/net.agent: assuming ppp0 is already up
Feb 14 22:16:02 pptp pppd[2576]: MSCHAP-v2 peer authentication succeeded for pptpuser
Feb 14 22:16:03 pptp pppd[2576]: found interface eth0 for proxy arp
Feb 14 22:16:03 pptp pppd[2576]: local  IP address （VPNサーバーのIP）
Feb 14 22:16:03 pptp pppd[2576]: remote IP address （VPNが割り当てるIP）
Feb 14 22:16:03 pptp pppd[2576]: MPPE 128 bit, stateless compression enabled
Feb 14 22:19:55 pptp pptpd[2575]: GRE: read(fd=6,buffer=8055780,len=8260) from network failed:
 status = -1 error = Message too long
Feb 14 22:19:55 pptp pptpd[2575]: CTRL: GRE read or PTY write failed (gre,pty)=(6,5)
Feb 14 22:19:55 pptp pptpd[2575]: CTRL: Client （接続元IP） control connection finished
Feb 14 22:19:55 pptp pppd[2576]: Modem hangup
Feb 14 22:19:55 pptp pppd[2576]: Connection terminated.
Feb 14 22:19:55 pptp pppd[2576]: Connect time 3.9 minutes.
Feb 14 22:19:55 pptp pppd[2576]: Sent 5242 bytes, received 15032 bytes.
Feb 14 22:19:56 pptp pppd[2576]: Exit.
Feb 14 22:19:56 pptp /etc/hotplug/net.agent: NET unregister event not supported

  ログにあるエラーを重要語句として、googleで症例を探したが、見つからない。

  新規購入のパソコンで、Windows98を使う事はないから、Windows98で
接続できなくても止む得ないで、逃げる手がある。
  しかし、原因追求はできなくなる。Windows98だけの症状なのか、
それとも、Windows2000、XPでも起りうる問題なのかもハッキリしない。

  原因を調べる必要はあるのだが、原因解決への糸口が全く見えない。
  困り果ててしまい、びぎねっとのMLに質問する事にした。

  すると、吉田さん＠町田からお返事を頂いた。

> Feb 14 22:19:55 pptp pptpd[2575]: GRE: read(fd=6,buffer=8055780,len=8260)
> from network failed: status = -1 error = Message too long


「メッセージが長すぎる」と言っているのですよね。
XPと98のMTUのサイズの違いなどは関係ないのでしょうか。

数十バイトくらいの小さなファイルでもエラーに
なるような場合は関係ないと思いますが、
ある程度の大きさ以上のファイルの場合のみ98とXPで
差異がでるのであればちょっとは関係するかな？

  MTUが最大パケット長さだという事は知っていた。

  早速、MTUについて調べてみる事にしたら、見つかった。

  Windows98の場合、ダイヤルアップ時代にあったため、ダイヤルアップ通信で
最適値の576になっている。
  Windows2000とWindowsXPは、LAN内のEthernetで最適値の1500だ。

  この違いがあったとは知らなかった。
  そこで、Windows98のMTUを変更する方法を調べたら、フリーの変更ソフトを
見つけた。
  早速、自宅のWindows98に入れてみる事にした。
  色々、MTUの値を変えてやってみた結果・・・

  それでも接続が切断される (TT)

  MTUの値を変えてもダメだったため、この時点では、MTUが犯人ではないと
思った。

  しかし、1つ良い事を発見した。
  接続回線の違いで、MTUの最適値が変わってくるのは知っていた。

  ところで、私は、パケットの長さが異っても分割されて送られる話は知っていたし
ある情報（入手先は忘れた）では、MTUを変更するのは、ADSLの速度を
早くするのが目的だが、そんなセコイ事をしても、あまり速度は変わらないだった。
  そのため、MTUには全く関心はなかった。

  しかし、自宅のWindows98のMTUの値を1500に変更すると、
ネットのダウンロードの速度が早くなっている。
  あくまで体感で、厳密な測定ではないが、MTUの値を変更して早くするのは
決して、姑息でセコイ技でない事を発見した！


  だが、Windows98で生じる問題の原因を突き止めたわけではなかった。
  犯人探しが双六で戻されるが如く、フリダシに戻った。

  しかし、どこから攻めて良いのやら全く見当がつかない。

  そこに、今野さんからお助け舟がやってきた。

昔、同じような現象が起きた事があり、一つ目はNICのDriverの問題で、
もう一つは、MTUの問題でした。
確かWin9xシリーズはMTUの自動調整機能がなかったはずなので、PPPoEとかで
MTUが変更されている時に、PPTPのパケットが上手く受け取れないとか言う
問題が出ているのではないでしょうか？

  これを読んで私は「そうか！ NICが犯人だと考えられる！」と思った。
  そこで考えたのは、自宅のマシンのNICを取り替えてみて、
取り替えたNICが正常に動けば、NICが犯人だとわかる。
  もし、NICのドライバーが原因だとすれば、全てが解決する。
  そこで、会社に余っているNICがあるか確かめる事にしたのだが・・・

  1枚も余ってへん (TT)

  でも、諦めない私。
  帰宅すると、自分のノートパソコンに、Windows98をインストールした。
  そして、VPNの設定をして、会社へ接続を試みた結果

  やっぱり接続が切断される (TT)

  ふと思った。会社のWindows98は、VPNサーバーに接続すると
正常に動いている。もしかして、ノートパソコンも会社で接続すれば、
正常に動くかもしれない。そう思って、会社へ持っていく事にした。
  そして、会社で接続実験をやってみた所、案の定、正常に動いた。

  この奇妙な現象に、ますます原因がわからなくなった。
  ふと、別の事が頭の中をよぎった。VPNサーバーがヤマハのルーターの場合
自宅のWindows98でも正常に動いている。  

ヤマハのルーターでVPNサーバーを構築した様子

この話の詳しい事は「システム奮闘記：その25」をご覧ください

  この時、MTUの事を思い出した。
  ルーターでVPNを構築して場合、問題なく接続ができるのは、
サーバー側でMTUの調整をしているのではないかと考えた。
  そこで「そういえば、クライアントのMTUしか考えてなかったが、
サーバー側のMTUの設定を見てみる必要があるかも」と思った。

  ifconfigコマンドを使えば、MTUの数値が出る事がわかったので、
早速、コマンドを打つが・・・

  全く表示されへん (TT)

eth0      Link encap:Ethernet  HWaddr 00:90:99:16:7F:B8  
          inet addr:192.168.1.AAA  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:156903 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39375 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:52981131 (50.5 Mb)  TX bytes:18863522 (17.9 Mb)
          Interrupt:11 Base address:0x1100 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:156 errors:0 dropped:0 overruns:0 frame:0
          TX packets:156 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11865 (11.5 Kb)  TX bytes:11865 (11.5 Kb)

  そこで、調べてみると、次の事がわかった。

   VPN接続でないと、PPP0の表示はされない！

  そこで、もう一度、VPN接続をした状態で、ifconfigコマンドを打つと
求めていたPPP0での、MTUの値が表示された

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:192.168.1.AAA  P-t-P:192.168.1.BBB  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:701 errors:0 dropped:0 overruns:0 frame:0
          TX packets:678 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:71830 (70.1 Kb)  TX bytes:340207 (332.2 Kb)

  これを見た時、VPN通信の時も、Ethernet同様、MTUが1500になっていた。
  そこで、ifconfig ppp0 mtu 1400コマンドを打って、MTUの値を変更した。
  問題なくMTUの値が変更された (^^)

  だが、問題が残った。例え、MTUの値を変更しても、VPN接続をやめて
再びVPN接続を行なった時は、MTU値が1500に戻っている。

  MTU値を元に戻らないようにしないと、自宅で実験したくてもできない。

  調べた結果、options.pptpdの設定ファイルに、次の事を書き加えれば良い事がわかった。

## CHANGE TO SUIT YOUR SYSTEM
lock

## turn pppd syslog debugging on
#debug

## change 'pptpd' to whatever you specify as your server name in chap-secrets
#name pptpd
name pptp-server

proxyarp
bsdcomp 0

# This option applies if you use ppp with chapms-strip-domain patch
#chapms-strip-domain

# These options apply if you use ppp with mppe patch
# NB! You should also apply the ChapMS-V2 patch
-chap
-chapms
+chapms-v2
mppe-128
mppe-stateless

mtu 1400

# These options will tell ppp to pass on these to your clients
# To use ms-wins or ms-dns in options.pptpd it must exist in /etc/resolv.conf
#ms-wins your.server.here
ms-dns XXX.YYY.ZZZ.AAA

  そして、ifconfigコマンドを打つと、見事にMTU値が変更されていた。

  その日の晩、自宅からWindows98で接続を試みたら

   見事、成功 V(^^)V

  ようやく肩の荷が降りた感じだった。


  それにしても、なんでMTUの値が悪さをするのか知りたくなる。
  原因を追求しなければ、今後、同じ問題に出くわして苦しむかもしれない。

  色々、調べてみると、わかってきた事が出てきた。
  まず、一つ目は、PPTPのパケットにあるIPへッダーが原因を思われる。

  通常、ネットワーク上をパケットが流れている時、パケットよりも
MTUが小さい回線に出くわした場合、下図のようにパケットが分割されて
MTUの小さい所でも通れるようになっている。

パケットの分割

  だが、PPTP通信パケットの場合、IPへッダーが分割禁止のフラグが
立っているみたい。

パケットの分割ができない

  このため、MTUが小さい回線に出くわした場合、パケットが分割できずに、
パケットを通す事ができず、通信不能に陥る。
  そのため、通信エラーが出たと考えられる。


  確かに、LinuxサーバーのMTUが1500なのに、会社が使っている
フレッツADSL回線のMTUは1454なので、MTUが1500のパケットが
通れないのは、納得できる。

  だが、それだけだと、Windows2000、XPで接続実験を行なった時に、
問題なく接続ができるため、話に矛盾が生じる。

  今野さんはＭＬで「Win9xシリーズはMTUの自動調整機能がなかった」と
書かれておられた。裏を返せば、Windows2000、XPにはMTUの自動調整機能がある
という事を意味する。

  そこで調べてみると、Windows2000、XP、Linuxには、MTUの自動調整機能が
付いている事がわかった。
  そして、MTUの自動調整を行なう仕組みは次のような感じだ。

MTUの自動調整を行なう仕組み

通信をする場合、共にMTU自動調整機能がついたOSとする。 送信側が分割禁止のフラグが立ったパケットを発信して、 送信先まで届くかどうかの確認を行なう。届かない場合は、 MTUの値を小さくして、相手に届くまで行なう。 そして、届いた時に、それがお互いを結ぶ経路上の最小MTUとして お互いが認識して、通信を行なう仕組みになっている。

  この説明だと、両方のOSが、Windows2000、XP、Linuxのどれかの場合、
接続が問題なく行なわれる事が納得できる。

クライアントが、Windows98の場合

Windows98は、MTU自動調整機能がないため「データくれ！」としか言わない。 サーバー側も、最小MTUの値がわからないため、とりあえずということで、 サーバー側で設定されているMTUの値の通りのパケットを送信するが、 途中の経路で邪魔されて、送れない。そのため、通信ができずに接続が切断される。 今回の場合、サーバーのMTUが1500で、フレッツADSLが1454なので ADSLの所でパケットが通れずに、エラーが出るといった現象が起こった。

  これで、Windows98がクライアントの場合に、PPTPで接続できなかった理由が
上手に説明できた。

  ちなみに、MTUを1400にして実験して成功したのは、偶然の産物だ。
  もし、経路上の最小MTUが1300だったら、実験は失敗に終わり、
下手をすれば、ますます混乱してしまっていたと思う。

  あと、私の場合は実験が成功したが、実験がうまくいかない例として
次の問題もある。

ＰMTUブラックホール問題

経路途中のルーターでICMPを破棄するルーターが存在する事もある。 MTU自動調整のために送るパケットは、ICMPプロトコルのために、 途中のルーターでパケットを破棄される場合もあり得る。 もし、破棄された場合、到達不能の信号が帰って来ないため、 送信側がMTUの値を間違えて認識して送信してしまう。 しかし、送信パケットがPPTPのパケットのように分割不可能な場合は、 いつまで経っても送信できない。そして、接続が切断されてしまう。 MTU自動調整のパケットを吸い込んでしまう事から「ブラックホール」と 名付けられたという。

  ちなみに、MTU自動調整機能はRFC1911に、PMTUブラックホール問題は
RFC2923に載っている。しかし、私は読んでいない。なぜなら・・・

  日本語訳が見つからなかった！！

  だった。
  英文なんぞ読む気が起こらないので、紹介するだけに終わってしまった (--;;


  それにしても、MTUの重要性を嫌でも認識させられた事件だった (--;;


  ついでにMTU問題とセットで出てくるRWIN値の話も書きます。

  TCP/IP通信を行なう時、パケットを送信すると、相手から確認の信号が送られる。
  「送信→確認」のやりとりをして、正しくパケットが送られるのを保証する。

  上図のように、1つのパケットの度に、確認信号を送っていると効率が悪い。
  そこで、下図のように、いくつかのパケットを、まとめて送信して、
受信確認ができれば、確認するという形をとっている。

  まとめてパケットを送る時、何個のパケットを送るのかが問題になる。
  この値の事を、RWIN値という。

  RWIN値は、Windows2000、XP、Linuxの場合だと、お互いがTCP層の階層で
やりとりをして、最適な値を自動的に割り出すようになっている。
  RWIN値の自動調整機能の事を「スライディング・ウィンドウ」という。

  ちなみに、Windows98の場合、自動調節機能がないため、値は固定値になっている。

  ここで暴露しまーす！

  実は、RWIN値の話を知りませんでした！！
  もう一つオマケに、MTU自動調整機能の事を「スライディング・ウィンドウ」と
誤解していました！！  (^^)

  MTUの事を調べていると「スライディング・ウィンドウ」という言葉が
よく出てくるので、すっかり誤解してしまい、あわや、システム奮闘記に
堂々と「MTU自動調整機能の事をスライディング・ウィンドウと言う」と
書く所でした。

  大恥をかく所だった (^^;;


  VPNサーバーの構築はできたのだが、実験サーバーを、そのまま運用するわけには
いかない。開発・実験に使うからだ。
  そのため、サーバーの確保が必要になってくる。
  Webに書いてある情報を読んでいたら、かなりCPUを消費すると
書いていたりする。「これは新規に購入する必要があるかも」と思った。

  だが、社内に余っていた社長のお古があった。Pentium150MHz RAM48。
  遊ばしておくのは勿体ないので、ダメ元で、社長のお古をVPNサーバーにして
動作実験を行なった。

社長のお古でVPNサーバー

  データ通信の状態を体感してみたが、結構、速度がありイライラは感じない。
  実験サーバー（Celeron1GHz RAM258）と体感速度は変わらない。

  この事から、接続するマシンの数が増えれば、話は別かもしれないが、
同時に接続するマシンが数台ぐらいなら、問題なく使えると思う。

  大企業のように、数十人、数百人が同時接続するわけでないので、
社長のお古で十分対応可能だと思った。

PPTPの暗号強度について

  VPNサーバーが運用できるようになったので、部長と上司に報告のメールを書いた。
  J社が提案しているのはIPSeC方式。私はPPTP方式。

  確かに、IPSeC方式の方が暗号化強度が強い上、パケット認証もある上、
暗号鍵の自動交換まで行なってくれる。
  だが、J社の提案は費用面に高い上、PPTP方式のMPPE128ビットだって、
簡単に破られる暗号とは、とても思えない。

  そこで、部長に突っ込まれないように、詳しく比較してPPTPでも
大丈夫だという事をメールで書いた。

  部長の返答で「Ｊ社にIPSeCとPPTPの比較を出したもらうように」という
指示がやってきた。
  私は「人が一生懸命調べて、ここまでやっているのに、部下を信用せんと、
なんで、業者に聞かんとアカンねん」と思い、ムッとした。

  部長が、暗号強度の事が心配なら、数値で出した方が良いと思った。
  そこで、googleで調べる事にしたら、載っていた。

  暗号の強度はビット数で決まる。
  1ビット増える度に、2倍強度が増す

  IPsecでは、3DES方式を使う事を仮定すると、3DESは158ビット。
  MPPEは128ビット。この場合、暗号強度の差は、2の30乗になる。
  ちなみに、2の10乗は、約1000なので、2の30乗は100億になる。

  MPPE128ビットと3DESは100億倍、強度が違う！

  確かに、3DESの方が強力だという事がわかるが、ここまで数字が大きいと
ピンとこない・・・ (^^;;

  次に、MPPE128ビットが、どれくらいの期間で破られるかを計算してみた。
  1999年に、DES(56ビット)が1日で破られた事実がある。
  仮に、現在でもDESを破るのに、1日かかると仮定する。
  まず、暗号の強度の差は、約4000×100億×100億。
  4000を10年と近似させて計算すると、1000億×100億年。

  MPPE128ビットを破るのに、1000億×100億年かかる！

  うーん、太陽の寿命が、あと50億年と言われているだけに、
太陽の寿命よりも遥かに長い事がわかる。

  さて、部長が「セキュリティーの事を考えて、強度の強い方を使うべきだ」
と言っても、数値で示せば文句は言えなくなる。

  そして、部長に「J社に問い合わせてみますので、もし、何か問題点などが
ありましたら、おっしゃってください」と言った。

　すると部長曰く・・・
　メールで、PPTPとIPSeCと書いてあるけど、わからへん。
　使う回線が違うのか、接続形態が違うのか、出して欲しいんや

　だった。

  私は「そんな事だったのか。たはは・・・」と思いながら、部長には
「単に暗号化する時の暗号の種類の違いですよ」と言ったら、
部長曰く「そうなんか」と言って納得してくれた。

  うーん、突っ込まれないように、色々、予防線を張ると、逆に話が細かくなりすぎて
理解してくれない良い例だなぁと思った (^^;;

  主任に、暗号強度を数値化した話をすると「そんな事、言われても
ピンとけぇへんなぁ・・・」だった。あまりにも非日常的な数字だからだ。

2005年6月18日に追加

  散々、苦労して構築したLinuxによるPPTPサーバーだが、2005年2月に、
ヤマハのルーター(RTX1000)の導入により、簡単に、PPTPサーバーが構築できるため
RTX1000に移行した。
  詳しくは「システム奮闘記念：その37」(ヤマハルーターRTX1000の設定入門)をご覧ください。


  だが、PPTPサーバーそのものを廃止する方向で考えている。
  実は、サーバーを構築して「外部との接続ができる」と喜んでいたのだが
出張した人から「ホテルから接続できへんで」と言われた。

ホテルから接続ができない

  実際、自分の目で確かめたいと思った時、インターネットVPNの導入で
全国行脚する機会ができた。「システム奮闘記：その35」をご覧ください。
　(インターネットVPNの構築事例)
  その時、宿泊先のホテルから接続を試みたのだが、ことごとく失敗。

  よく考えると、うちの家の環境が特殊だという事が考えられる。

自宅からの会社への接続形態

なんと加入しているプロバイダーは気前よく8つもグローバルIPを 割り当ててくれているのだ。普通では考えられない。

通常、考えられる会社への接続形態

通常ならホテルなどではDHCPサーバーなどでIPを割り当てるが ほとんどの場合、プライベートIPになるはずだ。

  そこで以下の2つの仮説を立てる

  (1) ファイヤーウォールによる影響
  (2) 応答パケットが迷子なる現象

ファイヤーウォールによる影響

ホテルにあるファイヤーウォールの設定で、応答パケットを通す時 TCP、UDP、ICMP以外のパケットを破棄している可能性がある。 PPTPの場合、GREプロトコルなので、充分に可能性が考えられる。

  もう1つ目の仮説が応答パケットが迷子なる現象だ。

応答パケットが迷子なる現象

  もし、2番目の仮説が正しいとなれば、自宅から会社へ接続できた理由も
説明がつく。
  実は、うちの家が加入しているプロバイダーは固定IP(グローバルIP)を8つも
割り振ってくれている。
  そこで以下のような状態になっている。

自宅から会社へ接続できる理由（推測）

  いずれにしても、2005年6月17日現在でも、仮説そのものが正しいかどうか
わからない状態にある。

  「調べろ！」という声がありましたら、反論します。

  だって、事務員だもーん。わかんなーい (^^)V


最後に

  「システム奮闘記：その25」で断念した、LinuxでVPNサーバーですが、
構築したいという欲求から、ついにサーバー構築に挑戦しました。
  今まで恐くて、手を出さなかったカーネル再構築にも手を出しました。
  七転八倒の末、なんとか構築に成功しました。

  PPTPとIPSeCとの暗号の強度の違いも定量的に求める事もでき、
PPTPでの暗号化でも問題なく使える事がわかりました。
  PPTPの問題点は認証部分ですが、定期的なパスワードの変更をすれば
問題はないでしょう。

  それだけでなく、MTUの話なども知ることができ、かなり収穫はありました。

  今回、使ったソフトは以下のURLからダウンロードできます。
  http://public.planetmirror.com/pub/mppe/

  他の方々が、こんな地獄にハマらない事をお祈り致します。