■DebianLenny(amd64)のpptpdによるVPN接続
今回の目標：同じセグメントで接続出来ることを確認する。
■参考URL
http://d.hatena.ne.jp/aiueo88/20100315/1268650074
■pptpdのインストール
$ sudo apt-get install pptpd
■必要な設定を確認する。
既存のネットワークとIPがかぶらないように
待ち受け用と割り当て用のIPのアドレス範囲を指定すればよいということです。
localipにpptpdサーバ用のIPを一つ指定する。
remoteipに接続先IPの範囲を指定する。
$ grep -A 37 "TAG: localip" /usr/share/doc/pptpd/examples/pptpd.conf
■PPTPDに待ち受けIPと割り当てアドレス範囲を設定する。
$ sudo cp -pi /etc/pptpd.conf /etc/pptpd.conf.org
$ LOCALIP="192.168.0.100"; \
REMOTEIP="192.168.0.101-119"
$ echo -e "localip $LOCALIP\nremoteip $REMOTEIP" >> /etc/pptpd.conf
■クライアントからのアクセス時に設定する項目は以下です。
$ sudo cat /etc/ppp/chap-secrets
■パスワードがあるので、rootユーザのみが読み書き出来ます。
$ ls -l /etc/ppp/chap-secrets
-rw------- 1 root root 106 2011-09-04 20:32 /etc/ppp/chap-secrets
■デフォルトで待ち受けるサーバの名前はpptpdです。
$ grep ^name /etc/ppp/pptpd-options
name pptpd
■現在のログインユーザを許可する設定を追加します。
$ export PPASS="password"; \
export PUSER=`whoami`; \
export PSERVER="pptpd"
$ sudo cp -pi /etc/ppp/chap-secrets /etc/ppp/chap-secrets.org
$ su root -c 'echo -e "${PUSER}\t${PSERVER}\t\"${PPASS}\"\t*" >> /etc/ppp/chap-secrets'
$ sudo cat /etc/ppp/chap-secrets
user1 pptpd "password" *
■パスワードも含むのでエクスポートした変数の設定を解除します。
$ env -u PPASS; \
env -u PUSER; \
env -u PSERVER
■pptpdサービスデーモンを再起動します。
$ sudo /etc/init.d/pptpd restart
■Windowsから接続。参考URL(長いので短縮URLを使用)
接続先は、VPNホスト名、またはIPは実ホストのIP、またはホスト名を指定します。
※実サーバへの接続をpptpdの待ち受けIPに渡し、
設定したアドレス範囲からクライアントにIPアドレスを割り当てます。
http://kayanomori.net/memo/index.php?PPTP%A5%AF%A5%E9%A5%A4%A5%A2%A5%F3%A5%C8%A4%CE%C0%DF%C4%EA%20for%20Windows%20XP
http://mcaf.ee/e7u62
■接続したら、サーバ側でログを確認します。
$ sudo grep pptpd --color /var/log/syslog
■デバッグオプションを有効にします。
$ grep -A 3 "TAG: debug" /etc/pptpd.conf
$ sudo cp -pi /etc/pptpd.conf /etc/pptpd.conf.nodebug
$ su root -c ' sed s/^\#debug/debug/ /etc/pptpd.conf.nodebug > /etc/pptpd.conf'
■syslogにGREのエラーが出ています。
$ sudo grep "GRE:" /var/log/syslog | awk -F\: '{print $5}'
Bad checksum from pppd.
■デバッグ有効時のログ
$ sudo grep "GRE:" /var/log/syslog | tail -1 | cut -c 41- | sed s/","/"\n"/g
GRE: read(fd=6
buffer=610a80
len=8196) from PTY failed: status = -1 error = Input/output error
usually caused by unexpected termination of pppd
check option syntax and pppd logs
$ sudo grep pptpd /var/log/debug | cut -c 31-
pptpd[3679]: GRE: Bad checksum from pppd.
pptpd[3728]: CTRL: Starting call (launching pppd,
■tcpdump からcksumのログのうち、bad udp cksum を確認。
ルータが問題のようです。
$ grep --color "bad udp cksum" eth0.log | tail -1 | sed s/"\,"/"\n"/g
21:58:31.363948 IP (tos 0x0
ttl 64
id 25215
offset 0
flags [DF]
proto UDP (17)
length 74) server.example.local.34010 > router.domain: [bad udp cksum 987b!] 854+ PTR? 250.255.255.239.in-addr.arpa. (46)
■システムログは問題ありません。
$ sudo grep -A 13 "Plugin" /var/log/messages | tail -14 | awk -F\: '{print $4 ":" $5}' | sed s/"\:\$"//g
Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
pppd 2.4.4 started by root, uid 0
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
MPPE 128-bit stateless compression enabled
found interface eth0 for proxy arp
local IP address 192.168.0.100
remote IP address 192.168.1.101
LCP terminated by peer (0M-u5^N^@ Connect time 0.2 minutes.
Sent 0 bytes, received 4022 bytes.
Connection terminated.
Modem hangup
Exit.
■マニュアルをチェックしてみます。
$ man pptpd.conf | grep -A 7 "^FIREWALL RULES"
FIREWALL RULES
pptpd(8) accepts control connections on TCP port 1723, and then uses
GRE (protocol 47) to exchange data packets. Add these rules to your
iptables(8) configuration, or use them as the basis for your own rules:
iptables --append INPUT --protocol 47 --jump ACCEPT
iptables --append INPUT --protocol tcp --match tcp \
--destination-port 1723 --jump ACCEPT
■tcpdumpで47ポートのキャプチャが出来ていません。
$ sudo tcpdump -X -vvv dst port 1723 > 1723.log &
$ sudo tcpdump -i eth0 proto 47 | tee -a 47.log
■Firewallを確認。
iptablesは当然許可してあります。
ルータの47ポートをフィルタルールで許可しても、
Windowsファイアウォールを無効にしても同じです。
■参考URLの下記項目のチェックを外したところGREのエラーが出なくなった。
「リモートネットワークでデフォルトゲートウェイを使う(U)」
http://nai.homelinux.net/pptp.html
■GREパケットが通るようになりました。
$ sudo less /var/log/syslog | grep pptpd | grep GRE | awk -F\: '{print $5}' | tail -1
accepting packet #87
■各FireWallを有効にしても問題ありません。
※WindowsFirewallを有効にすると再度、下記詳細設定の項目のチェックを外す必要があります。
「リモートネットワークでデフォルトゲートウェイを使う(U)」
■MSのサイトには以下のような記述があります。
VPN リモート アクセス ポリシー プロファイル上の IP パケット フィルタを使用して、
VPN クライアントから送信されない VPN 接続上の受信トラフィックおよび
VPN クライアントが送信先でない送信トラフィックの両方が破棄されます。
参考URL
http://technet.microsoft.com/ja-jp/library/bb878117.aspx
⇒何をフィルタしてるのかさっぱり分かりません。
■MSのVPNのトラブルシュート
VPN クライアントとサーバー間のネットワーク ファイアウォールを構成して、GRE を許可します。
http://technet.microsoft.com/ja-jp/library/cc772616(WS.10).aspx
⇒分かりにくいですが、VPNクライアント側も設定するという意味のようです。
■ポート47のパケットを確認する。
$ sudo tcpdump -i eth0 proto 47 | tee -a 47.log
$ cat 47.log | cut -c 60- | tail -3
GREv1, call 32768, ack 33, no-payload, length 12
GREv1, call 1664, seq 34, length 113: compressed PPP data
■まとめ
セキュリティ上は望ましい設定ですが、MSの説明は分かりにくい。
「リモートネットワークでデフォルトゲートウェイを使う(U)」を
チェックが入っている場合のルーティングを手動で構成するのは面倒な上、トラブルの元。
なので、これは必ずチェックを外すということにします。
