WireGuard が秘密鍵の長さが間違っていると表示する: 次にどうするか

メッセージは秘密鍵の長さが間違っていると述べており、その言い回しは暗号理論より先にエンコードを指しています。WireGuard の鍵は 32 バイトを base64 で表し、末尾のパディングを含めて 44 文字になるため、別の大きさの値はどれほどランダムに見えても鍵ではありません。パーサーが受け付けるまで文字列を埋めると、どのピアも決して認識しない整形式の値ができあがります。

このエラーの背後には、有効な鍵のテキストを修復することともう手元にない識別情報を置き換えることという二つの異なる作業が隠れています。結果は異なり、一方はもう一方の端を無効にします。

パーサーが期待するもの

WireGuard の鍵は base64 で表した 32 バイトの鍵素材で、標準のパディングにより 44 文字の固定文字列になります。ツールは、基になる曲線が 32 バイトのスカラーだけを受け取るため、ちょうど 32 バイトにデコードされないものを受け付けません。公開値と秘密値は同じエンコードを使うため、パーサーは形式だけではどちらを貼り付けたかを判別できません。この曖昧さが、このエラーをめぐる混乱の半分を生んでいます。

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

値が 32 バイトにデコードされるなら長さは正しく、苦情はファイルの別の場所から来ています。もっと短いものにデコードされるなら、切り詰められた素材であって形式の問題ではありません。

書式の損傷か、誤った素材か

書式の損傷は端に集まりがちで、シェルが加えた引用符、値と一緒にコピーされた private_key のようなラベル、チャットクライアントが挿入した改行、貼り付けを生き延びた末尾の空白などが典型です。どれもバイトを変えずに文字列を変えるので、取り除けば元の識別情報が戻ります。パーサーが黙るまで句読点を削るのではなく、ファイルをプロビジョニング記録と一文字ずつ比較してください。

誤った素材は別の状況です。パスワード、証明書の鍵、公開値はいずれももっともらしく見え、誤った大きさにデコードされます。どんなにきれいにしても、ピアが期待するスカラーにはなりません。その場合は編集ではなく新しい識別情報が必要です。

秘密フィールドに入った公開鍵

最もよくある混同は、公開値を秘密フィールドに貼り付けること、またはその逆です。どちらも 32 バイトの有効な base64 なので長さの検査は通り、ハンドシェイクは後で役に立つメッセージもなく失敗します。秘密鍵は公開鍵を生み出すスカラーなので、公開値を導出してピアが認可している値と比べれば決着します。導出した値が記録と一致しないなら、タイプミスではなく誤った識別情報を持っています。

クライアントの秘密鍵を置き換えながら遠端の認可済み公開鍵を更新しないと、同じ不一致が再び生じ、しかもクライアント自身のファイルは今、自己整合的に見えます。両端を一つの作業で変更しないと、次の人が間違った半分をデバッグします。

プロファイルを修復し、それからハンドシェイクを証明する

鍵が正しい大きさにデコードされ、認可された組と一致したら、残る作業はプロファイルと経路です。以下のコマンドは必要に応じて新しい組を生成し、既存の鍵のデコード後の大きさを検証し、インターフェースが実際に使っている公開値を読み取ります。秘密値をチケットやデコードサイトに決して貼り付けないでください。

wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes

大きさの検査は素材が鍵の形をしているかを答え、経路の問い合わせはパケットがインターフェースに届くかを答えます。両方の検査を通った後もハンドシェイクの行が空のままなら、診断はピアのエンドポイントと許可されたアドレスへ移ります。保存された古いプロファイルが正しく見えても実際に有効なものは違うことがある]ので、インターフェースの公開鍵をプロビジョニング記録と最後にもう一度照合してください。

どの値を置き換えたのか、認可されたコピーがどこにあるのかを記録してください。次にこのピアを触る人は、どちらの端が変わったのかを知る必要があります。