TCP 1723 の転送は PPTP の前半だけを開き、残りを壊れたままにするため、試行時に Windows は依然としてエラー 807 を返す。次の衝動はポート 47 の規則を追加することだが、まさにその手順が午後を丸ごと無駄にする。GRE は IP ヘッダー内のプロトコル番号であり、転送テーブルが照合できるポートではない。ルーターがプロトコル 47 を通し、それを同じ呼び出しに結び付けるまで、トンネルは開始できない。以下の節では二つの経路を分け、その後一つずつ検証する。

ポートテーブルにはプロトコル番号の行がない

PPTP は失敗の仕方が異なる二つの会話を使う。TCP 1723 上の会話は呼び出しを開始し、リンク情報を渡し、利用者が切断するとそれを破棄する。ペイロード側は GRE の中で動作し、IP ヘッダーはそれをプロトコル番号 47 で示す。そのトンネル内で PPP がリンクを交渉し、MS-CHAPv2 が資格情報を確認する。

GRE はトランスポートヘッダーを持たないためポートを公開せず、ポート向けに書かれた規則には照合する対象がない。1723 を転送するルーターはその TCP セッションのマッピングを作り、そこで止まる。後半を扱うファームウェアはこの機能を PPTP パススルーまたは PPTP ALG と呼び、どちらも提供せずその隙間を一切説明しないファームウェアもある。チェックボックスの表示名より、プロトコル 47 がそもそも認識されるかどうかが重要だ。

データ経路が死んだときに Windows が報告する内容

エラー 807 は接続を完了できなかったと述べるが、実際には呼び出しがサーバーに届き、データ経路が立ち上がらなかったという意味だ。これはトランスポートについての判定であり、アカウントについての判定ではない。資格情報や認証プロトコルの不一致を指すのはエラー 691 であり、まったく別の場所へ導く。

パスワードに触れる前にトランスポートを扱う。807 を追って資格情報を変えても本当の不具合はそのまま残り、次の試行が読みにくくなるだけだ。

二人目のクライアントが動作中のトンネルを壊す理由

識別するポートがないため、NAT 機器は二つの HTTPS セッションを分けるのと同じようには二つの PPTP クライアントを分けられない。そのため多くの家庭用機器は PPTP 呼び出しを一つだけ許可し、送信元アドレスで追跡する。単独で動いていたノート PC も、二台目がダイヤルした時点で完了しなくなり、クライアント側からは失敗が無作為に見える。この挙動はファームウェアに属し、プロファイルの変更では変わらない。

両方のクライアントがダイヤルしている間に接続テーブルを見る。常に最初のホストだけがマッピングを持つなら、ルーターは対応できる限界に達しており、クライアント側の設定では動かない。

どちらの半分が失敗しているかを証明する

ルーターで何かを変える前に TCP 1723 が届くことを確認する。その答えがどちらの半分を試しているかを決めるからだ。これらは Windows クライアントから自分のサーバー名に対して実行する。一つ目はポートが応答したかを表示し、二つ目はダイアログなしでダイヤルするため、繰り返しの試行を比較できる。

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

ポート試験で真の結果が出れば制御経路は開いており、残る容疑者は GRE だ。偽の結果ならルーティング、フィルター、転送のいずれかが壊れており、GRE を変えても救えない。データ側は見える場所、つまりサーバー側かルーター側で監視する必要がある。

tcpdump -ni any proto 47

Wireshark での相当物は表示フィルター ip proto 47 で、シェルに慣れていない人に渡すのも簡単だ。応答として何も出ずに GRE が到着するなら、戻り経路の修正が必要だ。

実際にエラーを直すもの

ルーターが設定を公開している場合は PPTP パススルーを有効にするか、規則を受け付けるファームウェアでプロトコル 47 を明示的に許可する。RouterOS では転送規則がプロトコルを直接照合し、ポートベースの転送には決してできないことができる。家庭用ファームウェアは同じ判断をチェックボックスの裏に隠しており、ポート転送ではなくセキュリティ設定の下にあることもある。そのような制御が存在しなければ、クライアント側では補えない。

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP を置き換えるのがもう一つの選択肢であり、多くの場合より安価だ。VPN を自分で終端するルーターは受信クライアントの二重 NAT を避けられ、ポートベースの NAT がすでに扱えるプロトコルならパススルーは一切不要だ:UDP 上の OpenVPN、TCP 443 上の SSTP、あるいは ESP を UDP 4500 に包む NAT-T 付きの L2TP/IPsec。PPTP は MS-CHAPv2 にも依存しており、その文書化された弱点はエラーが消えた後でも新規導入には不適切だ。

どの規則が違いを生んだかを書き留める。二番目の利用者がアクセスを求めるとき、同じサイトは同じ制限に直面するからだ。プロトコル水準の修正はネットワーク記録に残すべきで、次の技術者がそこを見る。

関連記事