共有の pppd オプションファイルは他の VPN を壊すのか

手こずっていた PPTP プロファイルを接続させるために一行足しただけで、一週間後には何か月も動いていた L2TP クライアントが止まる。表向きの解釈は、二つのプロトコルが今ぶつかっているというものだ。しかし実際には、両方のクライアントが pppd を起動し、同じ既定値を読み、追加した行は直そうとしていたプロファイルに限定されていなかった、ということが多い。共有オプションファイルこそが結合点であり、プロトコル側に落ち度はない。

クライアントは起動時に何を引き継ぐのか

PPP ベースのクライアントがコマンドラインをゼロから組み立てることはほとんどない。クライアントは pppd を起動し、pppd はシステム既定値、続いてユーザーファイルや端末ファイル、さらにクライアントが渡す引数を読み、クライアントがピアファイルを指定することもある。これらの層はいずれもプラグイン、認証方式、ルート指示を運ぶことができ、保護されたオプションを最初に設定した層が、その後の変更を封じる。

したがって有用な問いは、どの VPN が壊れているかではなく、どの層がその設定を持ち込んだかである。自前の引数を生成するクライアントは自己完結に見えても、システムファイルが持つすべてを引き継いでいる。

変更する前に、その行の出どころを特定する

接続が確立している間に動いているプロセスをまず見る。コマンドラインには明示的に渡されたファイルが現れ、そこに名前がないものは既定のパスから来ている。

ps -o pid=,args= -C pppd

引数リストにピア名が含まれていれば、そのファイルを読む。含まれていなければ、追いかけている設定は共有パスに存在する。pppd のマニュアルには、それらのファイルが読まれる順序と、一般ユーザーが上書きできないオプションが示されており、後から書いた行がまったく効かないことがあるのはそのためだ。プラグインのパスのような保護されたオプションは、後続のユーザーレベルの行では置き換えられないので、誤ったファイルを編集しても目に見える効果はない。

どのクライアントにも付いてくるプラグイン行

システムファイルで読み込まれるプラグインは最悪の原因になる。ユーザーがどのボタンを押したかに関係なく、新しい PPP プロセスが読み込もうとするものを変えてしまうからだ。L2TP プラグインは典型例で、あるプロファイルには正しく、同じ既定値から始まる PPTP プロファイルには無意味か有害になる。

クライアントが選択するピアファイルへ移すか、対応していればクライアント自身の接続ごとの設定へ移す。そのまま削除すると二つ目のクライアントは直るが一つ目が壊れ、こうして問題がチーム間を渡り歩く。

移した後に各クライアントを検証する

同じマシンから二つの接続を順に試し、成功ダイアログではなくネゴシエートされたオプションを読む。次のダンプは pppd が実際に組み立てたオプション一式を出力するもので、意味を持つのはこのリストだけだ。

sudo pppd call office debug dump

二つ目のクライアントでも同じことをして、二つの出力を比較する。移したオプションはどちらか一方だけに現れるはずだ。両方に現れるなら、そのクライアントが自分で再生成しており、修正は共有ファイルではなくそのプロファイルに入れるべきである。設定が今どこにあるかを接続のそばに記録しておけば、次の担当者が再び壊して結合を発見し直すことはない。