PPTP エラー 800 と 812、そして一分後に切れる接続

一つの PPTP クライアントからの三つのエラー メッセージは、通常三つの異なる障害を表しています。エラー 800 はトンネルがまったく形成されなかったことを意味し、エラー 812 はサーバーが認証方法を拒否したことを意味し、一分後の切断は健全なピアが消えたと判断する keepalive タイマーです。各段階はそれぞれの理由で失敗するため、それぞれに独自の確認が必要です。

エラー 800 はトンネルがまったく形成されなかったことを意味します

Windows はトンネルをまったく構築できないときにエラー 800 を出しますが、到達できないサーバーや不適切なセキュリティ パラメーターについての文言は診断ではなく要約です。PPTP は資格情報が調べられる前に、ネットワークから二つの別個のものが必要です。TCP 1723 が制御チャネルを運び、IP プロトコル 47、つまり GRE がカプセル化されたペイロードを運びます。

その外側の経路は自分の LAN の外からテストしてください、なぜならオフィス内で機能する接続はエッジについて何も証明しないからです:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

1723 が応答し、クライアントが接続しようとする間もキャプチャが空のままなら、経路がプロトコル 47 を落としています。1723 を転送しているが PPTP パススルーを切っているルーターは、TCP ハンドシェイクが完了した後で GRE パケットが消えるため、まさにそのパターンを作り、ログインが試みられていないのに資格情報の問題のように見えます。

転送先をサーバーの現在の LAN アドレスに向け、ルーターが提供する場所で PPTP パススルーを有効にし、同じ外部の地点から再試行します。GRE が上流でフィルターされていて変更できない場合、TCP 443 上の SSTP または UDP 500 と 4500 上の L2TP/IPsec のほうが、Windows 側でできるどんな変更よりも見込みがあります。

エラー 812 はサーバーが認証方法を拒否していることです

エラー 812 はトンネルが上がった後に返ってくるので、パスワードの問題のように感じられます。サーバーは接続のために交渉された認証方法を拒否しており、必ずしもパスワード自体ではありません。クライアントで VPN エントリを開き、セキュリティ タブに移動し、種類を Point-to-Point Tunneling Protocol に設定し、明示的なプロトコル一覧を選び、Microsoft CHAP バージョン 2 にチェックを入れます。

現在の設定はダイアログをクリックせずに読めます:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2 を要求するサーバーは、PAP や、より弱いものを交渉する自動の種類のままにされたクライアントを拒否し、エラーはユーザーのパスワードが評価される前に届きます。アカウントの形式は同じ拒否のもう半分です。ある事例では、サーバーがローカルまたはドメイン アカウントを求めていたのに、Windows は MicrosoftAccount\[email protected] という形の Microsoft アカウント ID を送りました。SERVERNAME\username と入力すると、Windows にどのアカウント ストアを参照するかが伝わり、エラーが消えました。保存された資格情報に以前の形式を再現させるのではなく、名前を手入力してください。

一分後の切断は keepalive の判断です

トンネルが接続し、少しトラフィックを通してから切断する場合は、クライアントに触れる前にサーバーの LCP エコーの挙動を見てください。デーモンは定期的にピアへ、まだそこにいるかの確認を求めます。設定された予算の中で返答が少なすぎると、ユーザーにまだ使えるリンクがあってもセッションは破棄されます。

Linux の pptpd サーバーでは、その値は /etc/ppp/options.pptpd にあり、通常の修復は間隔を短くするのではなく予算を広げることです:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

五秒間隔で三十回の取りこぼしは、ピアが消えたと宣言するのではなく短い停止を許します。回数を一か二に減らすと、翻訳された経路での通常のジッターがほぼ一分ごとの切断になります。サーバーが pptpd ではなく Windows RRAS の場合は、代わりに PPP セッションのタイムアウトとアイドル時の切断ポリシーを見てください。それらは別の場所にあり、存在しない pppd ファイルを編集しても何も変わりません。

重複するサブネットはデータ経路を壊します

両方の拠点が同じプライベート範囲、たとえばオフィスと自宅で 192.168.1.0/24 を使っていると、PPTP トンネルはきれいに認証できても何にも到達できないことがあります。クライアントはあるアドレスがどのホストを指すのか判断できず、一部のスタックは一つを選ぶ代わりに経路のインストール自体を拒否します。

それを設計上の欠陥として扱い、片側の番号を振り直すか、クライアントに意図的に変換したアクセス範囲を渡してください。PPTP クライアントをデバッグしても二重に存在するアドレス空間は直せず、症状はランダムな切断のように見え続けます。

失敗した段階から始めてください: 800 には GRE、812 には方法とアカウント文字列、予定どおりに死ぬトンネルにはエコー設定です。