Як праверыць сервер профілю OpenVPN перад імпартам

Хтосьці дасылае вам профіль, вы імпартуеце яго, і праз трыццаць секунд кліент набірае кірунак, які ніхто не праверыў. Спачатку прачытайце файл у тэкставым рэдактары, бо ўсё істотнае змяшчаецца ў жмені дырэктыў: remote, proto, port, ca, cert, tls-crypt і verify-x509-name. Астатняе — значэнні па змаўчанні, і менавіта там хаваюцца сюрпрызы.

Пералічыце ўсе канчатковыя пункты, якія можа выкарыстаць файл

Пачніце з канчатковых пунктаў, бо адзін профіль можа ўтрымліваць некалькі. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn друкуе ўсіх кандыдатаў у парадку файла, уключаючы тыя, што ўкладзеныя ў інлайн-блокі <connection>.

Калі дырэктыва не ўказвае порт, кліент вяртаецца да значэння па змаўчанні слухача, таму адзін remote vpn.example.com азначае порт 1194 з любым proto, які сустрэнецца далей у файле. Некалькі простых радкоў remote — гэта альтэрнатывы: кліент спрабуе іх па чарзе, пакуль remote-random іх не перамяшае, і ён ніколі моўчкі не падстаўляе хост іншага аператара. Два радкі remote на розных даменах — гэта момант, калі трэба спыніцца і спытаць, які з іх меўся на ўвазе.

Звярніце ўвагу і на напісанне proto. tcp прымаецца як сінонім кліенцкага tcp-client, але tcp-server у кліенцкім профілі — памылка канфігурацыі, якая схільная завісаць, а не чыста падаць.

Спачатку пацвердзіце імя, потым порт

dig +short vpn.example.com паведамляе, ці існуе імя і якія адрасы яно вяртае, а вузел з некалькімі адрасамі або за проксі можа цалкам законна вярнуць некалькі. Развязанне імені — гэта перадумова, а не доказ уласнасці; любы можа накіраваць імя на адрас, і адзін адрас можа адказваць за многія імёны.

Затым праверце слухача на знойдзеным порце, згодна з транспартам. Праз TCP openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com друкуе ланцуг, які падае сервер. Праз UDP патрэбны DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 праводзіць тое ж рукапоцісканне праз датаграмы. Завершанае рукапоцісканне даказвае, што нешта слухае і трымае сертыфікат, — гэта больш, чым паказвае ping, і менш, чым патрабуюць уласныя налады даверу профілю.

Калі рукапоцісканне не ўдаецца, а хост адказвае на ping, порт, верагодна, няправільны або адфільтраваны. Лічыце гэта прычынай запытаць правільны порт, а не запрашэннем прачэсваць суседнія. nc -vzu таксама паведамляе пра поспех на некаторых стэках, калі нішто не слухае, таму голы UDP-запыт нічога не значыць без рукапоціскання за ім.

Чытайце шпількі даверу асобна ад адраса

Адрас вырашае, куды ідзе кліент; блок даверу вырашае, каму ён верыць, калі прыбыў. verify-x509-name "vpn.example.com" name замацоўвае агульнае імя суб'екта, а remote-cert-tls server патрабуе пашыранага выкарыстання ключа для аўтэнтыфікацыі сервера. Профіль, які перадаў вам аператар, павінен мець абодва.

Шукайце ca, інлайн-блок <ca> і або tls-crypt, або tls-auth. Профілю з tls-auth патрэбны key-direction 1 на кліенце, калі бок сервера выкарыстоўвае кірунак 0, і неадпаведнасць правальвае рукапоцісканне з памылкай TLS, якая чытаецца як дэфект сертыфіката. Інлайн-CA, які не належыць таму аператару, чыё імя вы толькі што развязалі, азначае, што файл сабраны з двух крыніц, і гэта менавіта той выпадак, які варта рашуча адхіліць.

verify-x509-name прымае рэжымы name, name-prefix або subject, і апошні чакае поўнае адрозненае імя ў тым самым парадку, у якім яго друкуе сервер. Выбірайце рэжым, які адпавядае форме значэння, бо кліент адхіляе кожнае злучэнне замест папярэджання пра блізкі прамах. Для файла, які вы не пісалі, name з простым імем хоста — найменш нечаканы выбар.

Праверце параметры, якія ціха правальваюцца

OpenVPN 2.6 узгадняе шыфры праз data-ciphers, і профіль, які мае толькі стары радок cipher AES-256-CBC, можа завяршыць кантрольны канал і затым затрымацца на даных. Чытанне гэтага значэння паказвае, ці файл старэйшы за сервер, да якога вы далучаецеся; старонка даведкі 2.6 пералічвае парадак узгаднення, калі трэба працытаваць яго аператару.

auth-user-pass без імені файла азначае, што кліент спытае, таму профіль, які выглядае самадастатковым, усё роўна патрабуе ўліковых даных. auth-user-pass credentials.txt азначае, што ён чакае файл, які вам, хутчэй за ўсё, не даслалі. nobind і resolv-retry infinite — звычайныя і бясшкодныя, а explicit-exit-notify толькі для UDP і бессэнсоўны праз TCP.

Нішто з гэтага не змяняе, куды падключаецца профіль, але кожнае змяняе, ці падключыцца ён наогул, і нішто з гэтага не бачна ў дыялогу імпарту кліента.

Вырашыце, потым запішыце сваё рашэнне

Пасля гэтага чытання ёсць тры вынікі, і толькі адзін — імпарт. Калі канчатковы пункт і шпількі супадаюць з інструкцыямі, атрыманымі па асобным канале, імпартуйце. Калі канчатковы пункт выглядае правільна, але шпількі ці CA не супадаюць, запытайце выпраўлены файл. Калі файл мяшае канчатковыя пункты ці матэрыял CA з розных крыніц, выдаліце яго і запытайце свежую копію.

Запішыце хэш, які вы прагледзелі, каб наступны чалавек мог зразумець, ці змяніўся файл: sha256sum profile.ovpn, устаўлены побач з канчатковым пунктам у вашых нататках. Профіль — гэта цэлая кампазіцыя, а не спіс адрасоў, таму ніколі не ўстаўляйце працоўны remote у чужы блок даверу, пакідаючы яго ўліковыя даныя.

Трымайце прыватныя ключы і паролі па-за здымкамі экрана і абмеркаваннямі, пакуль параўноўваеце нататкі. Канчатковага пункта і несякрэтных параметраў дастаткова, каб задаць дакладнае пытанне, а астатняе месца — у файле.

Калі вы ўсё ж імпартуеце яго і першая спроба няўдалая, запусціце кліент з --verb 3 і прачытайце першыя дзесяць радкоў: развязаны адрас remote, узгоднены proto і памылка TLS з'яўляюцца менавіта ў гэтым парадку, што паказвае, якую з праверак вышэй вы прапусцілі.