OpenConnectのログインが誤ったページに着く?まずパスを確認する
VPNの完全なURLには、サインインの入口を選ぶパスが含まれます。それをフォームのグループとは分けて扱い、プロファイルを編集する前にリダイレクトを確認してください。
オンボーディングのメールからアドレスを貼り付けると、クライアントはゲートウェイに到達し、表示されるログインフォームはオペレーターが説明したパートナー用ではなく一般のポータルです。エラーが何も出ないことがかえって混乱を招きますが、トンネルは上がることさえあり、ただ誤った入口の背後にあるだけです。あのURLのパスは仕事をしていて、それを置き換えた何かがその仕事を落としました。
チケットの中で一つの文字列として届く二つのもの、つまりサービスに到達するアドレスと、認証がどこから始まるかを決める入力を切り分けてください。前者を直して後者を無視するのが、正しいホスト名でも誤ったログインになる理由です。
フォームが表示される前にクライアントが送るもの
https://vpn.example.net/partners のようなアドレスでは、クライアントの最初の動作は裸のホストではなくそのパスへのHTTPSリクエストです。返ってくるのは通常、サインインのエンドポイントへのリダイレクトか、フォームそのものです。vpn.example.net だけを与えられたクライアントは、既定のランディングページが何であれそこから始めますが、それは別のポータル、別のグループ一覧、まったく別のプロトコルを期待するページかもしれません。違いは、資格情報が入力されるはるか前に応答ヘッダーに現れます。
だからこそ、機能するブラウザータブと失敗するクライアントプロファイルが同じゲートウェイを指していながら食い違うことがあります。ブラウザーはパスをたどり、プロファイルはそれを持っていなかったのです。
交換可能に見えてそうではない二つの入力
OpenConnectは最初のHTTPSパスを --usergroup として公開し、マニュアルのページはそのパスを含む完全なURLを、同じ要求を別の書き方で表したものとして扱います。--authgroup は別のオプションで、ログインフォームの中でゲートウェイが提示する一覧から項目を選びます。プロトコルによってその項目をグループと呼んだりドメインやゲートウェイと呼んだりし、まさにそこで二つのフラグが混同されます。
サービスが正当に両方を必要とすることもあります。パスが正しいポータルへ導いても、フォームはその中のグループから選ぶよう求めるかもしれません。ポータル名をグループ名として渡す、あるいはその逆をすると、値が構文的に正しく意味的に誤っているために、受け入れられたように見えてから認可に失敗します。
オペレーターには、入口のパス、フォームでの選択、そして両方が必要かどうかを、それぞれ別の行で尋ねてください。ラベルが似ているからといって、一方から他方を導き出さないでください。
パスを切り詰めると結果が変わる理由
ホストとポートだけを受け付けるクライアントでも接続できることは多く、症状が明確な失敗になることはまれです。代わりに得られるのは、誤ったログインページ、空のグループ一覧、オペレーターが公開したものと一致しなくなった証明書名、あるいは目的のサービスへの経路なしに上がるトンネルです。それぞれ別の層に属し、どれもホスト名として文書化された欄に長い文字列を貼っても直りません。そのうち二つは、どちらも単に続行しないログインフォームとして届くため、外から見分けもつきません。
ホスト名をIPアドレスに置き換えるのは別の誤りで、しばしばこれと一緒に運ばれます。名前によるサービスの選択と証明書の検証はどちらも名前に依存するため、数値アドレスはパス形式の問題をTLSエラーに変えてしまいます。
ブラウザーのアドレスはパス以上のものも運びます。セッション識別子、リダイレクト先、言語プレフィックス、一時的なサインインパラメーターはどれもアドレスバーに現れ、いずれも保存されたクライアントプロファイルに属しません。
他の何かを編集する前に入口を確認する
与えられたパスのヘッダーを読んでください。curl -sS -o /dev/null -D - https://vpn.example.net/partners のような要求は、リダイレクトをたどらずにステータス行と任意の Location ヘッダーを出力します。名前付きのサインインエンドポイントを指す 302 はパスが存在することを確かめ、どこへ向かうかを示し、404 はオペレーターのアドレスが古いという意味です。
次に、たとえば openconnect --usergroup=partners vpn.example.net のようにして承認されたクライアントで同じ入口を再現し、どのフォームが出るかを見ます。フォームが正しく、それでもトンネルが失敗するなら、パスは問題ではなく、次の停止点はポリシーかルーティングです。
ホスト名、ポート、プロトコル、入口のパス、フォームでの選択を五つの独立した欄としてチケットに記録してください。その一覧があるからこそ、次のエンジニアは到達不能なサーバー、TLSの拒否、拒否された選択、必要な経路なしに上がったトンネルを区別できます。