1. Качаем инсталляцию с сайта. Для Windows сборки на 64 и 32 разряда разные.
2. Инсталлируем. Не забываем поставить GUI.
3. Одну машину ставим в режим сервера, другую в режим клиента.
Та, что будет в режиме сервера - с фиксированным IP, за firewall-ом. В нем ковыряем дырочку, по не стандартному порту, чтобы затруднить сканирование.
Применять будем протокол UDP, по 2-м причинам:
- опять-таки сканировать труднее,
- производительность даже визуально живее. Проверялось при обращении к мапированному диску в винде, чтении с него аксессовской БД.
Сначала сделали c shared keys. Заработало быстро.
Делов собственно два:
- сгенерировать ключ и разложить на обе машины. Можно прямо в каталог config.
<pre>
openvpn --genkey --secret secret.key</pre>
- написать конфиг, положить туда же.
Клиент: <pre> remote 195.1.2.3 1194 dev tun client proto udp ifconfig 10.10.10.2 10.10.10.1 secret secret.key keepalive 60 300 comp-lzo verb 1 mute 20 log-append ../connect.log status ../status </pre> Сервер: <pre> port 1194 dev tun udp-server proto udp ifconfig 10.10.10.1 10.10.10.2 secret secret.key comp-lzo verb 1 mute 20 log-append ../connect.log
</pre>Все, на значке гуя на сервере щелкаем "подключить", он становится желтым.
Будет желтым, пока кто-нибудь не подцепится. Тогда станет зеленым.
На клиенте, том кто вызывает, просто запускаем гуй, "подключить", смотрим какое все зеленое. На сертификатах все сложнее, однако только на первый взгляд. В виндовой инсталляции есть каталог easy-rsa, где лежат скрипты для генерации необходимой инфраструктуры открытых ключей.
Сначала переименовываем vars.bat и правим его. В принципе, достаточно одной правки - указать каталог ключей. Но! Необходимо в этот каталог скопировать файлы index.txt и serial, переименовав их. Если этого не сделать, то CA сгенерируется нормально, а вот ключи для работы не будут подписываться, будут оставаться только запросами на сертификаты, а не сертификатами.
Из запущенного сеанса cmd.exe запускаем последовательно vars.bat, затем командные файлы, которые генерируют dh, ключ и сертификат CA, затем ключи и сертификаты сервера и клиентов. Важно при генерации указывать разные DN для каждого клиента, если только специальной опцией не разрешить проглатывать одинаковые DN.
При каждой генерации образуется закрытый ключ (с расширением key) и сертификат (с расширением srt). Если получается другое расширение, значит открытый ключ у нас сгенерировался, но не подписался ключом CA и остался
Для работы вся эта куча ключей не нужна. На каждой машине кладется сертификат CA, чтобы проверять подлинность сертификатов, предъявляемых другой стороной, свой закрытый ключ, свой сертификат.
Соответственно, закрытый ключ CA прячем, т.к. он нужен для подписания новых ключей, а значит на рабочих машинах ему делать нечего, а лежать он будет в укромном месте.
Потом правим конфиги на работу с сертификатами, кладем ca.srt, client.srt, client.key (или srv.srt и srv.key) прямо в конфиг, чтобы не искать. Далее - все так же как и с shared keys - щелкаем мышкой по гую, соединяемся, отсоединяемся.
Клиент: remote 195.239.178.94 11940 dev tun tls-client proto udp ifconfig 10.10.10.2 10.10.10.1 dh dh1024.pem ca ca.crt cert client.crt key client.key keepalive 60 300 comp-lzo verb 1 mute 20 log-append ../connect.log status ../status Сервер: port 11940 dev tun tls-server proto udp ifconfig 10.10.10.1 10.10.10.2 dh dh1024.pem ca ca.crt cert server.crt key server.key comp-lzo verb 1 mute 20 log-append ../connect.logЕще не раскрыта тема длины ключей, отозванных сертификатов и маршрутизации.
