チュートリアルのインストーラーの一行コマンドを貼り付けて Enter を押すと、curl: (77) と表示されます。メッセージに証明書検証パスとあるため、VPN 事業者の証明書が壊れていると決めつけ、検証を飛ばすフラグに手を伸ばしたくなります。その読み方は誤りで、それに従って動くとローカルのファイル問題がセキュリティ上の判断にすり替わります。最初から順に見直しましょう。

ステップ1:この数字が何を意味するかを読む

エラー 77 はローカルの CA 入力に関するものです。curl は信頼するよう指示された証明書素材を読めなかった、あるいは読み込めませんでした。エラー 60 は相手側に関するもので、サーバーのチェーンが検証できないときに出ます。チュートリアルでは並んで登場しますが、意味は正反対です。

出力が 77 なら、サーバーは最初から問題ではありません。クライアントが検査に使おうとしたファイルを開けなかったということで、これはお使いのマシン上のパス、権限、パッケージングの問題です。

ステップ2:コピーしたコマンドを読む

コピーしたコマンドは文字を隠します。小文字の -l は --list-only で、プロトコルの一覧表示に使います。大文字の -L は --location で、HTTP のリダイレクトを追います。両者は別の表記ではなく、片方を書きながらもう片方を説明するチュートリアルは、意図されていなかったリダイレクトの道筋へ人を送り込みます。

リダイレクトを追ってもトラストストアのパスは直りませんし、最終的なホストが意図した発行元である証明にもなりません。コマンドがフォーラムの投稿由来なら、貼り付けた内容を信用せず、プロジェクト自身の手順から打ち直してください。

ステップ3:そのビルドがどの CA 入力を使うか調べる

まずバイナリを特定します。答えはそのコンパイル方法によって変わるからです:

curl --version

バージョンと TLS バックエンドを記録します。ネイティブのトラストストアを使うビルドは TLS ライブラリ経由でシステムのストアを読み、バンドルを指すビルドはファイルを読みます。明示的な --cacert、CURL_CA_BUNDLE の設定、あるいは shell ラッパーがどちらも上書きし得るため、パッケージでのインストールは実際に失敗しているファイルに触れていない可能性があります。

ファイルベースのストアなら、三つを順に確認します。パスが存在するか、呼び出し元のアカウントが読めるか、期待する CA 素材が入っているか。権限の誤ったバンドルは欠落したものとまったく同じように失敗し、どちらもサーバーについてのネットワーク上のやり取りが始まる前に失敗します。

ステップ4:検証ではなく入力を直す

サポートされた信頼設定を、それを所有する経路で復元します。ディストリビューションのパッケージ、構成管理、あるいは文書化された環境変数です。目的は、そのバイナリにとって読める正しい CA 入力です。

URL を HTTP に変えたり、--insecure を足したり、説明のないダウンロードからコピーした証明書を信じたりしないでください。どれも curl が読めなかったものを直すのではなく、何を受け入れるかを変えるもので、その変更はたいてい障害より長く残ります。

番号の参照先は curl のエラー目録 で、一度きちんと読むのに十分短いものです。

ステップ5:ダウンロードし、見てから実行する

インストーラーを同じコマンドで shell にパイプするのではなく、ファイルに取得します。この一つの変更が、検査できる転送と、あなたの権限で動くコードとを分けます。

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

応答が期待したスクリプトであり、HTML のエラーページ、リダイレクトの通知、空のファイルではないことを確認します。発行元がチェックサムや署名を提供するなら、同じフォーラムのスレッドに書かれた値ではなく、文書化されたリリース手順で検証します。

HTTPS がしたことと、しなかったことを覚えておきましょう。接続したホストまでの通信を認証しただけで、スクリプトの中身を審査したわけでも、発行元が信頼できるか教えてくれるわけでもありません。

ステップ6:インストールの手順を分けておく

ファイルのダウンロード、クライアントのインストール、トンネルの設定、ルートの検証は、それぞれ異なる失敗の仕方を持つ四つの作業です。一つずつ行えば、手順の後半で起きたエラーの原因は四つの候補ではなく一つに絞れます。

インストールが成功してトンネルが上がったら、チケットを閉じる前にルートと実際の宛先を一つ検証します。curl のエラーが直ったと言えるのは、単純な curl -I https://example.invalid が再び通ったときであり、インストーラーが文句を言わなくなったときではありません。

関連記事