DD-WRT の PPTP クライアント同士が通信できない：五つの確認

二台のノート PC が DD-WRT の PPTP サーバーにダイヤルインし、どちらもアドレスを受け取るのに、互いに ping が通らない。共有フォルダはいつまでも現れず、最初に疑うのはルーターが配る 255.255.255.255 のマスクが間違っているのではないかということだ。それは原因ではないし、変えても新しい隣人は一人も増えない。以下の五つの確認を順に行い、一つ失敗したらそこで止める。それぞれ対処法が違うからだ。

確認その一：/32 は不具合ではない

PPTP は PPP を運び、PPP リンクはちょうど二つの端点、つまりクライアントとサーバーを結ぶ。ネットマスクはどのアドレスがローカルセグメントを共有するかを表すが、ここにセグメントはなく、一本の線の向こう側にピアがいるだけだ。すべて一のマスクはまさにそのことを言っているので、DD-WRT はこのリンク種別に対して正しい値を配っている。このアドレスはピアのアドレスであって、LAN 上のインターフェースアドレスではない。

255.255.255.0 のマスクは何百台もの機器がぶら下がる共有媒体用であり、PPP インターフェースに置いてもトンネルの反対側が隣人になるわけではない。

確認その二：PPTP サーバーのページの値を読む

重要な設定はすべてサービス、VPN、PPTP サーバーにある。サーバーを有効にし、サーバーアドレスをルーターの LAN アドレスにし、クライアント範囲は DHCP プールの外に置いて、ダイヤルインするクライアントと有線のマシンが同じアドレスを受け取らないようにする。CHAP-Secrets にはアカウントごとに username * password * という形の行を一つ追加し、名前に空白を入れない。適用したら、ルーターといずれかのアカウントを指定したプロファイルで接続する。

クライアントがどこで止まるかで、どの層を見るべきかが分かる。認証は通るがアドレスが来ないならプールかシークレットの問題、アドレスは来るが何にも届かないなら経路かファイアウォールの問題だ。

確認その三：二つのピアの間の経路を探す

ルーターで終端するトンネルはそれぞれ独立したインターフェースで、通常は ppp0、ppp1 などになる。一方のクライアントから他方への通信はこれらのインターフェース間で経路制御される必要があり、ルーターがそれを転送する気でいなければならない。ルーターで ip route を実行し、接続中の各ピアについて、対応する PPP インターフェースを指すホスト経路があるか確認する。ピアに経路が欠けていれば、クライアントの状態画面が何と言おうとトンネルは完全には上がっていない。

別々の ppp インターフェースへ向かう二本のホスト経路、それが先に進む前に欲しい形だ。

確認その四：INPUT ではなく FORWARD チェーンを見る

クライアント間の通信は転送されるものでローカルで受け入れられるのではないから、INPUT チェーンは見る場所が違う。iptables -L FORWARD -v -n を実行し、PPP インターフェースに当たるドロップ規則と、そもそもチェーンに何か届いているかを見るパケットカウンターを確認する。トンネル通信を受け入れる規則のない既定ドロップの方針は、まさに最初の症状を生む。単独ならどのクライアントも問題なく、一緒になると互いに見えなくなる。

小さな ping は通るのに大きな転送で止まるなら、トンネルは遮断ではなく断片化している。PPP 上の PPTP は通常 MTU と MRU を 1450 前後にしたがるもので、1500 のままにするとハンドシェイクは通るが実際のペイロードで失敗するリンクになる。

確認その五：インターネットアクセスに何をさせるか決める

事務所経由で閲覧させたいクライアントには、WAN インターフェース向けの送信元変換が要る。LAN に届けばよいクライアントには経路だけで足りる。これは別々の意図であり別々の規則集合であり、マスクの話はこの二つ目の判断を完全に覆い隠す。規則を一つ足す前に、どちらの挙動が欲しかったのかを書き出しておくこと。事務所の回線から予期せず出ていくクライアントは、ログではなく会議で露見する驚きだからだ。

最後に一つ、修正とは関係のない話。PPTP は時代遅れで、その認証は何年も前から破られている。上のチェックリストは PPP リンクが何をするかを今も説明しており、後でクライアントを現代的なトンネルへ移す場合も同じ理屈が当てはまる。