「invalid secrets」は入れ物の問題であり、パスワード規則の問題ではない
GUI の欄、キーチェーン、認証情報ファイル、自動化の環境変数。同じパスワードでも通る封筒が違えば壊れる場所も違います。パスワードを単純化する前に、どこで止まったかを見極めてください。
「invalid secrets」と表示されると、たいてい VPN が記号を嫌っているという結論に飛びつきます。それは多くの場合まちがいで、このメッセージはゲートウェイがアカウントを見る前のローカル処理から出ていることがよくあります。同じパスワードを渡す設計は、グラフィカルな入力欄と認証情報ファイルの二通りあり、失敗する場所もそれぞれ違います。もともと問題のなかったパスワードを単純化する前に、入れ物のほうを比べてください。
エラーはゲートウェイより手前で起きる
ローカル検証、ロックされたシークレットストア、見つからないエージェント、壊れた認証情報ファイル。どれも利用者には一つの拒否として体験されますが、認証サーバーは関与していません。ゲートウェイ自身の拒否は別の出来事で、たいていメッセージもタイミングも異なります。それはトンネルが確立し、認証情報が送信された後に起こります。
ですから最初の問いは、どの文字が許されるかではなく、試行がどこで止まったかです。接続を一度も開かなかったクライアントは、誰にも拒否されていません。観察した段階を書き留めてください、以後の手順はすべてその分類にかかっています。
この区別は、誰が直すかも変えます。入れ物の問題は端末とその所有者のもので、アカウントの拒否は認証バックエンドを運用する人のものです。
文字ではなく入れ物を比べる
GUI のパスワード欄、キーチェーンの項目、二行の認証情報ファイル、自動化用のシークレット、どれも同じ値を別の封筒で運んでいます。封筒には独自の規則があり、たいてい壊れるのはその規則のほうです。問題になるのは値ではなく、値の運び方です。二つを切り離して考えれば、診断は短くなります。
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Community OpenVPN 2.6 のクライアントオプションには、auth-user-pass 用のこの二行ファイルの説明があり、パスワード行がない場合の挙動も含まれています。その場合はクライアントが入力を求めます。この一点が「もう渡したはずのパスワードを聞かれる」という報告の一群を説明します。また、二行目が空であることは無害な書式の選択ではなく、意味のある状態だということも教えてくれます。
引用符はまた別の層であり、素の認証情報ファイルの中ではデータとして保存されるのに、シェルはプログラムが何かを見る前にそれを取り除きます。同じ文字が一方では無害で、他方では構造的です。表だけではクライアントがどの入れ物を使ったか分からないので、行を選ぶ前にクライアント自身の設定を読んでください。
改行も構造的です。行区切りのフィールドを持つファイルは、改行を含む値を運べません、これは書式の制約であって、パスワードの強さへの判断ではありません。その場しのぎのファイルに合わせて秘密を切り詰めるのではなく、配備が対応している受け渡しの仕組みを使ってください。
シェルに傷つけられずに認証情報ファイルを作る
最も安全なローカルの道は、秘密をシェルの履歴にもプロセスの引数一覧にも残しません。両方のフィールドを対話的に読み、クライアントが期待する二行を書き込みます。それ以外はレビューしやすい設定ファイルに置いておけます。
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds最初の二つのコマンドはユーザー名を、次にパスワードを表示せずに読み、三つ目が二行を書き込み、四つ目がファイルを制限し、最後がそのファイルでクライアントを起動します。read -r がバックスラッシュを保持する点に注意してください、これを省くと、動いていたパスワードが失敗するようになる、まさにそういう種類の細部です。
クォートされていない変数や、シェル展開だらけのヒアドキュメントでファイルを作るのは避けてください。どちらもファイルに届く前に文字を変換し得て、その結果の失敗は VPN の拒否に見えます。ディスク上のパスワードが、あなたの知っているパスワードと本当に違うからです。疑わしいときは秘密自体を表示せずに、ファイルのバイト長を期待値と比べてください、一、二バイトのずれは、引用の事故の署名です。
最初のエラーから段階を読む
一度の試行から最初の具体的なメッセージを控え、それを分類します。ローカル検証エラー、見つからない秘密鍵、利用できないシークレットエージェント、ゲートウェイの認証失敗、これらは四つの異なる結果で、担当者も四者四様です。アカウントに関わるのはそのうち一つだけです。
ゲートウェイが正しく届けられた認証情報を本当に拒否しているなら、管理者とともにアカウント、認証バックエンド、必要なチャレンジを確認してください。一般的な認証失敗は、禁じられた文字を名指ししません。
認められた値を正しい仕組みで復元してください、文字と数字に縮めるのではなく。パスワードポリシーは運用者のものであり、それを静かに無効にする回避策は修正ではありません。次の人から本当の欠陥を隠してしまい、その人はより弱いパスワードで同じエラーに会い、より良い考えも持てません。