Како да составите клиентски профил на OpenVPN од издадените датотеки

Датотеката ovpn е конфигурација, не сертификат. Составете еден клиентски профил од издадените CA, сертификат и клуч, потоа закачете идентитет и директориум.

Вашиот оператор ви предава 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 сметка.

На крајот, направете попис на пакетот како материјал за акредитиви. Предавањето на истиот сертификат и клуч на втор преносен сметач го копира идентитетот, а преименувањето на датотеката не ви дава второ регистрирање. Тоа е разликата помеѓу составување профил и негово издавање.

Поврзани статии