Vpn on Twistedminds

GRE over IPSeс

Thu, 16 Aug 2012 16:04:37 +0000

Настоятельно рекомендую ознакомится с предыдущей статьей, посвященной теории.

Настройка GRE туннеля Link to heading

Нет ничего проще, чем настроить GRE туннель:


Rx(config)# interface tunnel #_number
Rx(config-if)# tunnel source [ source_router_IP_addr | source_router_interface ]
Rx(config-if)# tunnel destination [ dst_router_IP_addr | dst_router_fqdn ]
Rx(config-if)# keepalive [seconds [ retries ]]
Rx(config-if)# tunnel mode mode

tunnel interface – создает туннельный интерфейс, в процессе создания туннель автоматически переходит в состояния UP, no shutdown подавать на нем не нужно; tunnel source – указывает на адрес, который должен будет использован маршрутизатором в IP заголовке GRE пакета; tunnel destination – указывает, где GRE туннель должен быть терминирован; Обратите внимание, что source и destionation адреса – это адреса loopback или физических интерфейсов непосредственно маршрутизатора, а не адреса самого туннельного интерфейса. tunnel mode – по умолчанию GRE point-to-point. О GRE multipoint мы поговори буквально в следующий раз, когда речь пойдет про DMVPN. keepalive – по умолчанию выключен, если при включение команде не будут переданы параметры, то keepalive будет отправляться каждые 10 секунд, а после 3-х безуспешных сообщений будет принято решение о недоступности пути.

Site-to-Site IPSec VPN между Cisco и Mikrotik

Thu, 02 Aug 2012 18:21:42 +0000

Не смотря на то, что статей в этих ваших интернетах море я все равно внесу немного энтропии и напишу еще одну.

Я всегда с осторожностью отношусь к хвалебным отзывам и хайпу на форумах, особенно когда дело касается железки стоимостью 60$. Как оказалось, делаю я это совсем не зря. Mikrotik не подвел и порадовал таким набором фееричных багов, что пару раз белому мерзавцу грозила неминуемая смерть.

Стабильной работы удалось добиться с следующими параметрами:

Cisco Site-to-Site IPsec VPNs

Mon, 23 Jul 2012 10:21:38 +0000

Наконец-то долгожданная практика ,)

[][1]

В этой статье мы рассмотрим два простых случая построения site-to-site VPN на оборудовании Cisco. В первом случае оба устройства имеют белые адреса (static crypto map), а во втором один из маршрутизаторов оказывается за NAT (dynamic crypto map). Ну и в качестве бонуса рассмотрим ситуацию совместного сожительства и static и dynamic crypto map на одном маршрутизаторе.

Те, кому лень читать 1000+ слов могут перейти сразу к конфигурациям, располагающимся в самом конце статьи.

IPsec VPNs – теория

Fri, 20 Jul 2012 14:36:18 +0000

[][1]IPsec – это на самом деле целый фреймворк, который предоставляет следующие сервисы:

Конфиденциальность данных посредством их шифрования алгоритмами DES, 3DES и AES;
Целостность данных и их аутентификация посредством HMAC функций MD5 и SHA-1;
Защита от атак типа MitM с помощью зашифрованных порядковых номеров;
Аутентификация устройств и пользователей. Фреймворк IPsec описан в нескольких RFC. У него есть две группы стандартов:
ISAKMP/IKE/Oakley/SKEME используются для создания безопасных соединений, по которым проводится изначальное согласование параметров шифрования, сигнатур, ключей;
AH и ESP используются непосредственно в таких механизмах защиты данных, как обеспечение конфиденциальности (только ESP), целостность данных, подтверждение того, что данные пришли из валидного источника и защиту от mitm атак. IPsec VPN: Конечные устройства или пользователи проходят пять начальных шагов для установки соединения:

Должно быть что-то, что инициирует процесс установки соединения. К примеру трафик до назначения, которое описано в ACL. Естественно, соединение может быть установлено чуткими нежными руками сетевых инженеров.
IPsec в процессе ISAKMP/IKE Phase 1 установит безопасное управляющее соединение, которое будет использоваться для последующего обмена информацией, необходимой для установки защищенного канала передачи данных. Соединения первой фазы – служебные соединения. По этим каналам не передаются какие-либо пользовательские данные или данные приложений.
Через служебный канал конечные устройства согласуют параметры, необходимые для созданиях защищенных каналов передачи данных и устанавливают их.
Как только защищенный канал передачи данных создан, устройства могут начинать передачу информации. Если используются HMAC функции, источник создает fingerprint, а получатель его проверяет. Если нужно шифрование – источник, соответственно, зашифровывает информацию, получатель ее расшифровывает.
И каналы передачи данных, и управляющие каналы имеют время жизни, по истечении которого соединение будет разорвано. Если вам все еще необходимо передавать информацию, то они перестроятся автоматически. Security Assotiation (SA) – группировка компонентов безопасности (алгоритмы шифрования, HMAC функции, время жизни соединения, DH группы, AH/ESP протоколы, различные идентификаторы, такие как SPI), которые необходимы для установки надежного канала передачи данных. Процесс установки соединений для l2l:
Происходит инициация соединения;
Начало ISAKMP/IKE Phase 1 – соседи договариваются о том, как управляющее соединение будет защищено;
С использованием DH алгоритма соседи обмениваться ключами, которые необходимы для алгоритмов шифрования и работы HMAC функций;
Происходит аутентификация устройств;
Phase 1 на этом заканчивается, начинается ISAKMP/IKE Phase 2. Соседи согласовывают параметры и ключи необходимые для защиты канала передачи данных (либо через управляющее соединение, либо с использованием алгоритма DH снова);
Phase 2 заканчивается и устанавливается защищенный канал передачи данных;
По истечению времени жизни, канал передачи данных должен быть перестроен. С Remote Access VPN все несколько сложнее, так как дополнительно вам может понадобится аутентификация пользователей или необходимость применить какие-либо политики. Для Remote Access VPN это будет выглядеть так:
Происходит инициация соединения;
Начало ISAKMP/IKE Phase 1 – соседи договариваются о том как управляющее соединение будет защищено;
С использованием DH алгоритма соседи обмениваться ключами, которые необходимы для алгоритмов шифрования и работы HMAC функций;
Происходит аутентификация устройств;
Опционально: происходит аутентификация пользователя (стандарт XAUTH).
На это шаге проходит применение политик. У Cisco это называется IKE Mode Config или IKE Client Config. Процесс изменяется от производителя к производителю, но смысл остается примерно один: клиент получает внутренний IP, имя домена, DNS, WINS, политики split tunnel, политики МСЭ и другие.
Опционально: в Cisco Remote Access VPNs происходит Reverse Route Injection (смысл в том, что клиент рассказывает о своих маршрутах VPN терминатору).
Phase 1 на этом заканчивается, начинается ISAKMP/IKE Phase 2. Соседи согласовывают параметры и ключи необходимые для защиты канала передачи данных (либо через управляющее соединение, либо с использованием алгоритма DH снова);
Phase 2 заканчивается и устанавливается защищенный канал передачи данных;
По истечении времени жизни канал передачи данных должен быть перестроен. Теперь поговорим подробнее про фазы 1 и 2.

ISAKMP/IKE Phase 1 Link to heading

Как уже было сказано выше, в процессе первой фазы устанавливается управляющее соединение. Используется 500 udp порт (4500 в случае NAT-T). Вне зависимости от того, является ли VPN l2l или remote access во время первой фазы происходит следующее:

VPN: ключи, шифрование, hmac, key exchange

Thu, 19 Jul 2012 06:57:13 +0000

До того как мы приступим непосредственно к внедрению IPsec VPN, поговорим о технологиях, на которые он будет опираться, предоставляя защиту трафику: ключи, шифрование, аутентификация пакетов, обмен ключами, методы аутентификации пользователей и устройств.

Ключи Link to heading

Ключи используются в таких критически важных функциях VPN как: шифрование, проверка целостности пакета, аутентификация.

Ключи бывают двух видов – симметричные и асимметричные.

Симметричный ключ, это единый ключ, который используется для защиты информации. Алгоритм шифрования использует его и для шифрования, и для дешифрования, что делает подобные алгоритмы быстрыми, но менее криптостойкими. К таким алгоритмам относятся DES, 3DES, AES, RC4 и другие.

VPN intro

Mon, 16 Jul 2012 20:20:09 +0000

[][1]

Virtual Private Network – кто все эти люди? Link to heading

Изначально виртуальный частные сети (VPN) были разработаны для того, чтобы смягчить или полностью исключить такие проблемы, как передача данных прямым текстом по таким протоколам как telnet, ftp, pop, smtp. Заодно было бы неплохо решить проблемы прослушивания трафика, выдачи злодеем себя за легитимного пользователя и атаки типа MitM – man in the middle (с помощью аутентификации, проверки целостности пакетов и шифрования). disclaimer: цель этой и следующих статей не является пересказ похожей информации из бесчисленных источников, а мое желание уложить все в голове по причине того, что в security в целом и в VPN в частности я, что называется, “плаваю”.

Постоянное соединение vpnc

Sun, 23 Oct 2011 13:45:18 +0000

Сбыдлокодил на коленке скрипт, поддерживающий соединение с vpn-шлюзом:

#!/bin/bash 
if 
[ &#8220;$(/sbin/route -n | /bin/grep &#8220;172.16.10.0&#8221; | /usr/bin/awk &#8220;{print \$8}&#8221;)&#8221; = &#8220;tun0&#8221; ] 
then 
echo &#8220;$(/bin/date &#8220;+%X %x&#8221;)&#8221; route exist >> /var/log/vpnc.log 
else 
echo &#8220;$(/bin/date &#8220;+%X %x&#8221;)&#8221; no route to scse &#8211; reconnecting >> /var/log/vpnc.log 
if [ -f /var/run/vpnc/pid ] 
then 
echo &#8220;$(date &#8220;+%X %x&#8221;)&#8221; found vpnc pid &#8211; deleting >> /var/log/vpnc.log 
&#8220;$(/bin/rm -f /var/run/vpnc/pid)&#8221; 
fi 
echo &#8220;$(date &#8220;+%X %x&#8221;)&#8221; establishing scse vpn tunnel >> /var/log/vpnc.log 
&#8220;$(/usr/sbin/vpnc /etc/vpnc/scse.conf)&#8221; 
fi