PPTPの分割トンネリングが動かない：まずGRE経路を直す

PPTP接続が立ち上がるのを見ると、クライアントが認証し、ppp0アダプターやWAN Miniportが現れ、ステータスウィンドウが緑になったところで、難しい部分は終わったと信じたくなります。ところが内部ホストへの最初の要求がタイムアウトすると、プロファイルのせいにされます。実際には独立した二つの層を片付ける必要があり、TCP 1723とGREを運ぶ外側の転送と、どの宛先がPPPインターフェイスを使うかを決める内側のポリシーです。緑のステータスは最初の層が交渉したことだけを示し、二つ目の層については何も語りません。

プロファイルから制御ソケットまでクライアントを追う

クライアントのログを開き、サーバーに接続する箇所を特定します。PPTPはまずポート1723へのTCP接続を開き、そのチャネルでトンネルのパラメーターを交渉します。この手順が失敗すると、その先は何の意味もなく、エラーは通常サーバーのアドレスかタイムアウトを示します。

ルートに触れる前に、制御接続をネットワーク上で確認します。クライアントまたはミラーポートで、一回の接続試行についてTCP 1723を取得します:

sudo tcpdump -ni any 'tcp port 1723' -c 20

ハンドシェイクが完了しセッションが確立していれば、外側の制御チャネルは機能しています。SYN-ACKをまったく受け取らないSYNは、ファイアウォール、誤ったサーバーアドレス、ポートをフィルタするプロバイダーを示します。ハンドシェイクの直後にリセットが来る場合は、サーバーが資格情報かトンネル種別を拒否したことが多いです。

GREは二つ目のプロトコルであり、ポートではない

PPTPはPPPペイロードを拡張GRE、IPプロトコル47の中に運びますが、これにはルーターが追跡できるポート番号がありません。そのためTCP 1723を許可するルールでも、トンネルにデータ経路がないままになることがあります。ステートフルNAT機器は応答を戻すためにGRE内部のコールIDを理解する必要がありますが、多くの機器は対応していません。PPTPの仕様は制御チャネルとGREペイロードを別々の部品として扱っており、テスト計画もそうあるべきです。

同じキャプチャーでプロトコル47を観察し、出ていくものと戻ってくるものを比較します:

sudo tcpdump -ni any 'proto gre' -c 20

TCP 1723が健全なまま、応答のないパケットが出ていくのは、GREブロックの典型的な兆候です。家庭用ルーターのPPTPパススルーはそのファームウェア固有の機能なので、あるホテルのネットワークで動いても次のネットワークの保証にはなりません。ルーターにパススルーがなく変更できないなら、問題はルートテーブルではなくプロトコルの選択です。

トンネルがパケットを一つ運ぶことを証明する

GREが流れ始めると、PPPの交渉がクライアントインターフェイスにアドレスを割り当てます。推測せずに割り当てを読み取ります:

ip -4 addr show ppp0

ポイントツーポイントリンクの宛先として表示されるピアアドレスにpingを送ります。この段階で応答があれば、カプセル化された経路が端から端まで機能し、サーバーがトンネル内部で応答していることが分かります。ピアは応答するのに内部ホストが応答しない場合、外側の転送は正常で、障害は内側に移っています。

分割ルートを追加する前にこれを行います。転送が壊れた状態でルートを変更すると、二つ目の変数が生まれ、一つ目が隠れます。

分割ポリシーを書く（DNSも含める）

分割ルーティングは決定の一覧であり、チェックボックスではありません。トンネルを通す必要がある各プライベートプレフィックスにはPPPインターフェイス経由のルートが必要で、ローカルに残す各プレフィックスはそこに存在してはいけません。アプリケーションサブネットのルートが、そのプライベートリゾルバーへの対応するルートを欠いているのは、アプリが壊れたように見える障害を作るよくある方法です。

各カテゴリーの一つのアドレスについて、カーネルが下す決定を確認します:

ip route get 10.20.5.10
ip route get 203.0.113.25

一つ目はppp0を、二つ目は通常のゲートウェイを示すはずです。両方が同じインターフェイスを示すなら、ポリシーはまったく分割されていません。DNSサーバー自身のアドレスをトンネル一覧に追加してください、そうしないと内部ホストの名前解決がローカルリゾルバーから出て行き、役に立つものを返しません。

五つの手順で繰り返せる確認

層を順番に実行し、最初に失敗した層で止めます: 制御チャネル、GREの可視性、PPPピアの応答、一つの内部アドレスに対する分割ルート、トンネル経由のアプリケーション要求です。各手順には独自のコマンドがあるので、失敗は謎ではなく帰属できます。

Linuxクライアント向けの簡潔な版は次のとおりです:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windowsでもroute printとクライアントに表示されるアダプターの状態で同じ順序が当てはまります。PPTPは旧式のプロトコルであり、サーバーがSSTPやIKEv2を提供しているなら、各ホップでプロトコル47が通過することに依存する経路を調整するより、移行するほうが通常は時間の有効活用です。古いプロファイルを新しいリリースにコピーするのではなく、代替の証明書と認証契約を確認してください。