Linux の SSTP がログイン前に失敗する？実行時コンポーネントを確認する

SSTP プラグインをインストールすると、ネットワークエディターにラジオボタンが現れ、ゲートウェイとユーザー名を入力すると、パスワードを尋ねる前に一般的なエラーでプロファイルが失敗します。この流れに珍しい点はなく、トンネルのソフトウェアがインストールされている証拠にもなりません。SSTP 接続は別々に配布される部品から組み立てられます。NetworkManager が起動できる VPN プラグイン、TLS と PPP のセッションを持つ SSTP クライアント、その下の PPP デーモン、そして接続が読むことを許された秘密の保管場所です。

メニュー項目が加えるもの、加えないもの

プラグインは、NetworkManager に起動方法を伝えるサービス記述と、ほとんどのディストリビューションではフォームを描く小さなエディターを提供します。メニュー項目の範囲はこれだけです。クライアントは別のソースパッケージから供給され、プラグイン自身の README もその分担をはっきり書いています。これはプラグインであって、クライアントではありません。

次にクライアントは PPP を必要とします。SSTP は TLS 接続の中に PPP セッションを運ぶからです。pppd がないと、トンネルは TLS ハンドシェイクを完了しても最初の制御フレームで停止し、これは認証情報の問題に見えてそうではありません。Debian と Ubuntu では部品は network-manager-sstp、sstp-client、ppp として入り、最初の一つだけを入れるのが、フォームがすべての欄を受け付けるのに接続が決して終わらない最も一般的な理由です。

デスクトップの選択でさらに分割が増えます。Plasma は plasma-nm でプロファイルを編集し、これには独自の SSTP コンポーネントが必要で、同じサービス記述を読みます。だから SSTP の項目がないエディターと、プロファイルを問題なく作れる CLI は、壊れた実行環境ではなく、エディターの半分が欠けている状態です。

何かを再インストールする前に、最初に失敗する段階を読む

失敗した SSTP の試行は決まった順序で段階を通過し、失敗した段階がどのコンポーネントを見るべきかを教えてくれます。

最初はプラグインの起動で、ここでの失敗はサーバーではなく VPN サービスについてのメッセージを出します。次にポート 443 への TCP 接続が来ます。ここでの拒否やタイムアウトは到達性の問題で、TLS の問題ではありません。続いて TLS ハンドシェイクとサーバー ID の確認、次に PPP の折衝とアカウント認証、最後にアドレスの割り当てとルートです。プロファイルを一度有効化する間 journalctl -f -u NetworkManager を監視し、最後の一般的な行ではなく最初の具体的な行を読んでください。

この順序がよくある誤読を説明します。証明書の苦情は認証情報を送る前に報告されるので、パスワードを変えても役に立ちません。PPP 認証の拒否はハンドシェイク成功の後に届くので、証明書を替えても役に立ちません。最初のエラーとその段階を残せば、症状ではなく診断が手に入ります。

証明書の信頼とアカウントのログインは別々の関門

ハンドシェイクは、設定した発行元と名前を使って、サーバーが目的の相手であることを検証します。その後にだけ PPP 層がユーザー名とパスワードをゲートウェイの認証方式に渡します。つまり独立した二つの確認が決まった順序で評価され、それぞれ別の設定を持ちます。パスワード欄に打ち込むものは最初の確認に影響できません。

間違った発行元を信頼するプロファイルは、最初の関門で ID エラーを出して失敗します。正しく信頼していても古いパスワードを保存するプロファイルは、二番目の関門で認証拒否として失敗します。どちらも接続しない VPN に見え、どちらも他方の薬では直りません。

エディターの既定値を推測するのではなく、ゲートウェイを運用する人から期待される発行元とサーバー名を入手し、要求される認証方式を記録してください。組織がプラグインで表現できない方式を必要とするなら、正直な答えはそれを扱える承認済みクライアントであり、エラーを消すために検証を切ったプロファイルではありません。

プロファイルと秘密の持ち主を一人にする

プロファイルができたら NetworkManager で有効化し、結果として生じるルートとリゾルバーの変更もその管理者に所有させてください。NetworkManager がすでに接続を動かしているのに二つ目の独立した SSTP クライアントを起動すると、二組のルート、二つの DNS 設定、単一の真実の源がないデバッグ作業が待っています。

秘密にも所有者がいます。システム全体での使用として印を付けた接続は、ユーザーセッションに限定した接続とは資格情報の保存方法が異なり、キーファイルに手作業で作ったプロファイルは、パスワードを対話的に渡すことを期待する秘密エージェントから読めないかもしれません。決して問題ではなかったパスワードを打ち直す前に、プロファイルがどの文脈を期待しているかを確認してください。同じプロファイルを端末から nmcli で有効化するのが最速のテストです。決して現れないプロンプトは、エージェントにもう渡すものがなかったことを告げます。

トンネル、ルート、リゾルバーを別々に確認する

接続済みの表示は、リンクが上がったことだけを主張します。実際に必要な宛先、それを運ぶルート、使用中のリゾルバーを一つずつ確認してください。それぞれが間違っていても、残りの二つは正常なことがあります。

失敗した試行では、各コンポーネントのバージョンと、機密を除いたエラーの文面を記録してください。プロファイル全体ではなくそれらを共有してください。プロファイルには事前共有の秘密と保存された資格情報が含まれうるからです。

最後に切断して再接続し、一度再起動してください。プロファイルが最初の試行でしか動かないなら、問題は秘密の扱いかルートの所有にあり、どちらも勤務日の途中より今のほうが安く直せます。