Вы ўстаўляеце аднарадковы загад усталёўшчыка з інструкцыі, націскаеце 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 зноў працуе, а не тады, калі ўсталёўшчык перастае скардзіцца.

Падобныя артыкулы