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

Мэта тут — OpenVPN 2.6 для Linux: кліент каманднага радка, маршрутызаваны TUN праз UDP, з аўтэнтыфікацыяй па сертыфікаце.

Збірайце толькі файлы кліенцкага боку

Працуйце ў абароненым каталозе і збярыце ўхвалены давераны матэрыял CA, выдадзены вам кліенцкі сертыфікат і прыватны ключ, які да яго падыходзіць. У гэтым прыкладзе імёны — ca.crt, laptop-a.crt і laptop-a.key. Імёны файлаў — толькі этыкеткі; яны нічога не кажуць пра тое, што змяшчае кожны файл.

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

Пакіньце прыватны ключ подпісу CA, прыватны ключ сервера і параметры DH па-за гэтым пакетам.

Злучыце файлы ў невялікі профіль

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

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

Радок remote выбірае сеткавы канчатковы пункт. remote-cert-tls server патрабуе, каб партнёр прадставіў сертыфікат з роляй сервера. verify-x509-name фіксуе чаканае імя, тут vpn-gateway як Common Name сертыфіката сервера з полем імя па змаўчанні OpenVPN. Гэтае значэнне не выводзіцца з DNS-імя хоста, таму выкарыстоўвайце схему ідэнтычнасці, якую даў аператар.

Не адмаўляйцеся ад гэтых праверак толькі таму, што тэставы канчатковы пункт паказвае іншы сертыфікат.

Гэты базавы профіль мяркуе адсутнасць асобнага выкліку ўліковага запісу і ключа канала кіравання. Калі сэрвісу патрэбныя auth-user-pass, tls-auth або tls-crypt, захавайце канфігурацыю і матэрыял, які вам далі, бо сакрэт канала кіравання, створаны вамі самастойна, не супадзе з тым, які захоўвае сервер. Захавайце таксама шыфравальную палітыку сэрвісу, замест таго каб імпартаваць радкі сціскання або шыфравання са старога прыкладу.

Зрабіце працоўны каталог яўным

Адносныя шляхі ідуць за працоўным каталогам працэса, а не за размяшчэннем файла .ovpn.

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

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

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

Трымайце ключ чытэльным толькі для прызначанага карыстальніка або ідэнтычнасці службы.

Правярайце перадачу, а не імёны файлаў

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

Калі з’яўляецца запыт парольнай фразы, ён належыць прыватнаму ключу, а не ўліковаму запісу VPN.

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

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