Cisco vpn puppy linux

HowTo: Подключение к Cisco VPN с использованием Aladdin eToken в Linux (Ubuntu)

Сравнительно недавно я решил перевести домашний компьютер с Windows на Linux. То есть идея такая бродила уже некоторое время, подогреваемая новостями с фронтов борьбы с добровольно-принудительной установкой Windows 10 и размышлениями о неизбежном устаревании «семерки» следом за XP, а вот поводом взяться за дело стал выход очередного LTS-релиза Ubuntu. При этом основным мотивом такого перехода я назову простое любопытство: домашний компьютер используется в основном для развлечений, ну а знакомство с новой ОС — развлечение не хуже прочих. Причем развлечение, как мне кажется, полезное в плане расширения кругозора. Дистрибутив же от Canonical был выбран просто как наиболее популярный: считаю при первом знакомстве с системой это немаловажным подспорьем.

Довольно быстро я на собственном опыте убедился, что для котиков и кино Ubuntu вполне подходит. Но, поскольку компьютер используется еще и для удаленной работы, для отказа от Windows не хватало настроенного подключения к Cisco VPN c авторизацией по eToken.

Набор программ

Было ясно, что для подключения понадобятся по меньшей мере драйвер токена и некий VPN-клиент. В результате поисков в сети получился такой список:

1. OpenConnect — VPN-клиент, «совершенно случайно» совместимый с серверами Cisco «AnyConnect»
2. GnuTLS — свободная реализация протоколов TLS и SSL. Что важно, в состав этой библиотеки входит утилита p11tool для работы со смарт-картами
3. SafeNet Authentication Client — набор драйверов и дополнительных утилит, обеспечивающий работу с электронными ключами eToken

Поскольку для установки соединения OpenConnect-у требуется URL сертификата клиента, который можно узнать с помощью утилиты p11tool, и обеим программам требуется драйвер для работы со смарт-картой — с установки этого драйвера и начнем.

Установка клиента eToken

Как резонно замечено в статье про настройку eToken в Ubuntu 12.04, ссылка на SafeNet Authentication Client почти секретная. Но в то же время на просторах интернета нашлась более свежая заметка про аналогичные танцы с бубном уже в 14.04, причем с живой ссылкой на дистрибутив где-то в бразильском филиале SafeNet. Что еще интереснее, на том же сервере есть файл с актуальной версией клиента — 9.1, которая, ура-ура, не требует устаревших библиотек. Правильный же способ получения клиента — конечно обратиться к поставщику вашего ключа.

На текущий момент пакет SafenetAuthenticationClient-9.1.7-0_amd64.deb ( или SafenetAuthenticationClient-9.1.7-0_i386.deb для 32-битных систем ) элементарно ставится двойным щелчком по нему в файловом менеджере. Но во время начала работы над этим материалом еще не была исправлена ошибка в Ubuntu Software, из-за которой не работала установка сторонних пакетов. Поэтому была написана

При успешной установке в меню Applications появляется приложение SafeNet Authentication Client Tools.

Установка и настройка GnuTLS

Дело в том, что в определенный момент я совершенно застрял, не понимая, почему токен из родного клиента виден, а через p11tool — нет. И именно отсюда я понял, где же лежит собственно драйвер. Зная путь к драйверу, ставим и настраиваем GnuTLS по инструкции.

Теперь с токеном смогут работать любые приложения, использующие GnuTLS. А мы сможем воспользоваться утилитой p11tool для выяснения URL-а нашего сертификата.

Чтение данных токена

Вывести список имеющихся в токене сертификатов можно следующей командой:

Вывод p11tool выглядит примерно так:

Object 0:
URL: pkcs11:model=eToken;manufacturer=SafeNet%2c%20Inc.;serial=99999999;token=Username;id=%XX%XX;object=%7bXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX%7d;type=cert
Type: X.509 Certificate
Label:
ID: XX:XX
Object 1:…

Сертификатов может быть несколько, а для подключения требуется один конкретный. В инструкции по p11tool от OpenConnect в такой ситуации предлагают попробовать каждый. Я же для сопоставления сертификата с его URL составил небольшой скрипт, который выводит как URL, так и текстовые данные каждого сертификата:

Здесь в цикле по URL-ам объектов p11tool —info выводит данные сертификата в своем представлении, а p11tool —export передает сертификат в формате pem-файла на вход openssl, который и выводит текстовое представление. Для передачи в OpenConnect нам нужен тот, где найдется строка Client Authentication — запоминаем его URL. Кроме того, если сервер использует самоподписанный сертификат, запоминаем еще и URL объекта с флагом CKA_CERTIFICATE_CATEGORY=CA.

Экспортируем сертификат удостоверяющего центра в файл (весь URL не обязателен — лишь бы он однозначно определял объект):

Наконец-то OpenConnect

Минимальный набор аргументов для подключения приведен в следующей команде:

Если сервер использует самоподписанный сертификат, при запуске в таком виде OpenConnect уточнит, доверяем ли мы серверу, и к тому же будет занято окно терминала. Поэтому слегка расширим команду:

С помощью cafile мы указали сертификат удостоверяющего центра — теперь не будет вопроса относительно доверия серверу. Опция background говорит сама за себя, а pid-file позволяет указать имя файла, в котором сохранится идентификатор фонового процесса. Кроме того, пароль токена может быть указан прямо в URL с помощью атрибута pin-value. Но это несколько… небезопасно.

Останавливать фоновый процесс правильно следующей командой:

По сообщению SIGINT OpenConnect корректно завершает соединение, а если разорвать соединение «жестко», могут быть проблемы при следующем подключении. Хотя у меня не было.

Послесловие

Задача решена, и я радостно пользуюсь для удаленного доступа приложением Remmina, которое запускаю сразу при подключении к vpn, добавив в скрипт запуска OpenConnect команду:

Правда, пришлось отключить синхронизацию буфера обмена: иначе на удаленной машине он в некоторых приложениях не работает; и включить настройку «Disable tray icon»: в противном случае при каждом подключении в трей добавляется новая иконка. Опять же, переход в домашнюю директорию перед вызовом Remmina неспроста: приложение почету-то не видит путь , а задавать полный путь с именем пользователя мне кажется неправильным.

Выводов относительно применимости Linux дома делать не буду — мне пока хватает, а статья задумана именно как HowTo.

P.S.: На окончательный выбор версии Ubuntu повлияло именно решение данной задачи: в пятой, включенной в Ubuntu 14.04, версии OpenConnect обнаружилась ошибка, мешавшая установке соединения. Вот ради лишенной той ошибки седьмой версии OpenConnect я и поставил возможно еще сырую 16.04.

EDIT: в Ubuntu 19.04 обновилась версия libcrypto и даже драйвер, поставляемый с 10 версией SafeNet, не находит данную библиотеку. Спасаемся симлинком
sudo ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/libcrypto.so

Еще раз ссылки на использованные материалы:

Источник

Configuring an IPSec Tunnel Between a Cisco VPN Client for Linux and a VPN 3000 Concentrator

Available Languages

Download Options

Contents

Introduction

This document describes how to form an IPSec tunnel from a Linux-based PC running the Cisco VPN Client to a Cisco VPN 3000 Series Concentrator so that you can access the network inside the concentrator securely.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

This document uses these configurations:

Components Used

The information in this document is based on these software and hardware versions:

Cisco VPN 3000 Concentrator version 3.x

Cisco VPN Client version 3.0.8

Red Hat Linux® version 7.2 with 2.4.7-10 Kernel

Note: Support for RedHat8 is available in VPN Client versions 3.6.2a and above. Registered customers can obtain specific information by researching bug ID CSCdy49082 (registered customers only) .

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Network Diagram

This document uses the network setup shown in the diagram below.

Configurations

In this section, you are presented with the information to configure the features described in this document.

Configuring the VPN 3000 Concentrator

Use the following steps to configure the VPN 3000 Concentrator.

Connect to the VPN Concentrator console port and verify that there are IP addresses assigned to the private (inside) and public (outside) interfaces. Also verify that there is a default gateway assigned so that the concentrator can forward the packets for the destinations that it does not know about to the default gateway.

Note: The default is normally the Internet Gateway Router.

This table shows current IP addresses.

To assign an available range of IP addresses, point a browser to the inside interface of the VPN 3000 Concentrator and go to Configuration > System > Address Management > Pools > Add. Specify a range of IP addresses that do not conflict with any other devices on the inside network.

To tell the VPN Concentrator to use the pool, go to Configuration > System > Address Management > Assignment, and check the Use Address Pools box.

Configure an IPSec group for the users by going to Configuration > User Management > Groups > Add and defining a group name and password. The example below uses group name «ipsecgroup» with the password/verify as «cisco123.»

On the Groups General tab, select IPSec.

On the Groups IPSec tab, set the authentication to Internal.

Go to Configuration > User Management > Users > Add, and add a user to the previously defined group. In the example below, the user is «ipsecuser» with the password «xyz12345» in the group «ipsecgroup.»

Configuring the Linux Client

Follow these steps:

Navigate to the /etc/CiscoSystemsVPNClient/Profiles directory where VPN connection profiles are stored.

Open a new profile file by either copying the sample profile to a new name or by creating one from scratch. In the example below, the sample .pcf file was copied, renamed, and edited.

Edit the newly named .pcf file to include the following information.

A new description that will identify the connection

A new host IP address that will be the IP address of the public interface of the VPN 3000 Concentrator

A new group name that will need to match the group configured in the VPN 3000 group setup

A new user name which is the same user name that is configured on the VPN 3000 Concentrator that coincides with the VPN Group on the concentrator

Save the file and exit.

From the command prompt, use the vpnclient connect ipsec command to connect to the VPN Concentrator using the IPSec .pcf file. You will be prompted to enter the group password. This is the same password that was configured on the VPN 3000 Concentrator (password «xyz12345», in this example).

If the connection is not successful, please see the Troubleshooting section below.

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

This section provides information you can use to troubleshoot your configuration.

Turning on Logging on the VPN Client

Below is troubleshooting information relevant to this configuration. Follow the instructions below to troubleshoot your configuration.

Create a global profile, if one does not already exist in the /etc/CiscoSystemsVPNClient/ directory. The global profile should look like the example below.

Note: Verify that each one of the log levels is set to «3»; this will ensure that the highest level of logging can be achieved.

From the command prompt, use the /usr/local/bin/ipseclog command to start the IPSec log utility and to move the information in that log to a directory and file of your choice. In this example the file is named clientlog.txt, and it is in the /etc/CiscoSystemsVPNClient directory:

In a separate window, use the tail -f (for filename) command to get a constantly updated snapshot of the clientlog.txt file while you are connecting to gather debug information.

Turning on Logging on the VPN 3000 Concentrator

Follow the instructions below to troubleshoot your configuration.

Go to Configuration > System > Events > Classes to turn on the following debug if there are event connection failures.

AUTH — Severity to log 1-13

AUTHDBG — Severity to log 1-13

IKE — Severity to log 1-13

IKEDBG — Severity to log 1-13

IPSEC — Severity to log 1-13

IPSECDBG — Severity to log 1-13

Note: If necessary, AUTHDECODE, IKEDECODE, and IPSECDECODE can be added later.

You can view the log by going to Monitoring > Filterable Event Log.

Источник