В очередной раз убеждаюсь, что Циска плохо умеет делать прикладные софтовые решения. Так кажущаяся простой задача с обновлением сертификата аплайнса, превратилась в редкостную "секаса". Итак, народ, решивший посидеть на WiFi был жестоко обломан с записями на беспроводном контроллере, что у них Authentication Failed. На самих ACS'ах в фейловом разделе также гордо указывалось на EAP-TLS or PEAP authentication failed during SSL handshake. Быстрый поиск и нахождение описания ошибки:
This failure occurs when:
•The server validation is not configured correctly on the client.
•The machine certificate is not provisioned on the machine (when used with EAP-TLS).
•Unable to provide a user certificate for authentication.
•The AAA server certificate has expired.
•The Root CA certificate is not installed or is not installed correctly on the client.
•The same CA certificate is used for intermediate CA or Root CA certificate: Root CA duplication.
Проверка аплайнса показала экспайренный пару дней назад сертификат. Вот тут и началось веселье - мануал описывал процесс обновления на пол странички, причем в картинках. Однако первый полученный от Виндового CA сертификат оказался Unsupported certificate format. К слову, сама Винда прекрасно в курсе про формат p7b. Чтож попробуем конвертнуть - первое, что пришло в голову - поставить на локальную машину полученный серт (благо можно), а потом его экспортировать в кошерный вид. Сделано, еще попытка установки, но теперь с ошибкой - Unsupported private key file format. Чтоб тебя! Начинаем копать поиск и курить инфу. Вариантов аналогичной проблемы с 2005 года - масса, решения не всегда всем помогают, в общем никакой определенности. Перевыпускаю реквест на новый сертификат, точно вижу новосозданный приватный ключ, получаю назад p7b, конверчу - фига - Private key you've selected doesn't fit to this certificate. Снова поиск уже по новым вводным. В результате, что нужно учитывать, то бишь описание грабель:
- не использовать при формировании реквеста старых имен (имя файла приватного ключа), так как он странно перезаписывается - лучше явно задать имя нового ключа,
- по умолчанию создается запрос и ключ длиной 2048, с этим траблы - явно указывать длину 1024,
- при конвертировании из p7b в pem я воспользовался онлайновой тулзой https://www.sslshopper.com/ssl-converter.html (помогла!).
понедельник, 16 мая 2011 г.
суббота, 14 мая 2011 г.
Ubuntu подключение сканера Mustek BearPaw 2400 CU Plus
Взято тут: http://smartqmid.ru/index.php?showtopic=85.
Вкратце, нужно поставить пакеты
sudo apt-get install sane xsane libsane-extras
С прилагающегося диска из каталога Drivers (я выбрал драйверы для Windows XP) скопировать PS2Dfw.usb в папку /usr/share/sane/gt68xx/,
потом редактируем
sudo vim /etc/sane.d/gt68xx.conf
раскомментируем строки:
# Mustek BearPaw 2400 CU:
override "mustek-bearpaw-2400-cu"
firware "/usr/share/sane/gt68xx/PS2Dfw.usb"
Теперь при запуске XSane он найдет сканер.
Вкратце, нужно поставить пакеты
sudo apt-get install sane xsane libsane-extras
С прилагающегося диска из каталога Drivers (я выбрал драйверы для Windows XP) скопировать PS2Dfw.usb в папку /usr/share/sane/gt68xx/,
потом редактируем
sudo vim /etc/sane.d/gt68xx.conf
раскомментируем строки:
# Mustek BearPaw 2400 CU:
override "mustek-bearpaw-2400-cu"
firware "/usr/share/sane/gt68xx/PS2Dfw.usb"
Теперь при запуске XSane он найдет сканер.
четверг, 12 мая 2011 г.
Добавление корневых сертификатов в Win.
В меморис, чтобы снова не искать, как оно делается (опробовано на Vista, Server2008R2 и Win7):
запустить IE (англ) от имени админа: Tools / Internet Options / Content / Certificates добавляем (Import) во вкладке Trusted Root Certification Authorities. Для импорта *.pem файла нужно в просмотре каталога выбрать All Files (*.*) и убедиться, что он точно будет добавлен в нужный раздел, а то по-умолчанию выбрана опция автоматического определения, куда его отнести.
запустить IE (англ) от имени админа: Tools / Internet Options / Content / Certificates добавляем (Import) во вкладке Trusted Root Certification Authorities. Для импорта *.pem файла нужно в просмотре каталога выбрать All Files (*.*) и убедиться, что он точно будет добавлен в нужный раздел, а то по-умолчанию выбрана опция автоматического определения, куда его отнести.
понедельник, 25 апреля 2011 г.
Пример PAC файла для балансировки проксей Cisco IronPort WSA.
Для клиентов, прикупивших пару Айронпортовских апплайнсов, на прошлой неделе помог составить файл автоконфигурирования (PAC - Proxy Auto-Configuration). Требования были, в принципе, простые и логичные:
- доступ к ресурсам локальной сети по IP адресам - без прокси,
- доступ к доменам, ресолвищимся в локальные адреса - без прокси,
- доступ к списку конкретных доменов - без прокси,
- балансировка обычных http запросов между проксями,
- для https запросов включен механизм (MIM - Man In the Middle) - передается основная прокся (условно №1), если она не доступна - вторая. То есть режим основной / резервный.
В результате получился такой скриптец:
Пара ссылок, подмогнувших в написании:
http://en.wikipedia.org/wiki/Proxy_auto-config
http://www.findproxyforurl.com/pac_file_examples.html
- доступ к ресурсам локальной сети по IP адресам - без прокси,
- доступ к доменам, ресолвищимся в локальные адреса - без прокси,
- доступ к списку конкретных доменов - без прокси,
- балансировка обычных http запросов между проксями,
- для https запросов включен механизм (MIM - Man In the Middle) - передается основная прокся (условно №1), если она не доступна - вторая. То есть режим основной / резервный.
В результате получился такой скриптец:
function FindProxyForURL (url,host) {Проверку файлец выдержал, под IE и FF не встал колом.
var resolved_ip = dnsResolve(host);
if (isInNet(resolved_ip, "10.0.0.0", "255.0.0.0") ||
isInNet(resolved_ip, "172.16.0.0", "255.240.0.0") ||
isInNet(resolved_ip, "192.168.0.0", "255.255.0.0") ||
isInNet(resolved_ip, "127.0.0.0", "255.255.255.0"))
return "DIRECT";
if (shExpMatch(url, "*.test.room.local")||
shExpMatch(url, "*.test.room.ru")||
shExpMatch(url, "*.citrixweb.test.room.ru")||
shExpMatch(url, "*.test.room.net")||
shExpMatch(url, "*.test.room.com")||
shExpMatch(url, "*.test.room.spb.ru")||
shExpMatch(url, "secure.test.room.com")||
shExpMatch(url, "*.internal.test.room.com"))
return "DIRECT";
if (shExpMatch(url, "https:*")) return "PROXY spbsrvprx-wsa1.test.room.local:3128; PROXY spbsrvprx-wsa2.test.room.local:3128";
else
switch (URLHash (url) %2) {
case 1: return "PROXY spbsrvprx-wsa2.test.room.local:3128";
default: return "PROXY spbsrvprx-wsa1.test.room.local:3128";
}
}
function URLHash (url) {
server_name=url.split("/")[2]
if (!server_name) {return url.length;}
return server_name.length;
}
Пара ссылок, подмогнувших в написании:
http://en.wikipedia.org/wiki/Proxy_auto-config
http://www.findproxyforurl.com/pac_file_examples.html
воскресенье, 17 апреля 2011 г.
Запуск Cisco IOU под Windows в andLinux
Некоторое время назад, когда появились первые ссылки на цисковскую внутреннюю разработку IOS over UNIX (IOU), коллега протестивший, естественно в целях обучения, этот симулятор (пусть так называется), попросил проверить, существуют ли методы запуска этой полезняшки на Windows машинах. По-первости, я смотрел в сторону Sygwin'а, но достаточно быстро понял, что это не то. Насколько я понимаю, sygwin - это взятые линуховые исходники, поправлен синтаксис и скомпилированы виндовыми компиляторами, то есть портация приложений (утилит и пр.). В процессе изучения вопроса, натолкнулся на проект coLinux, от которого отпочковался проект andLinux, построенный на дистрибутиве Ubuntu. Текущая стабильная версия 0.7.4 доступна в двух вариантах (минимальная XFCE и "большая" KDE) - http://www.andlinux.org/downloads.php. Однако проект не обновлялся с мая 2009 года! Текущее ядро базируется на Ubuntu 9.04 (логично для мая 2009го). Я решил поставить вариант с кедами. Сам процесс установки достаточно прозрачен, мастер задает вопросы о том, куда поставить это богатство, логин / пароль для доступа к общей шаре, как запускать приложение (можно автоматически процессом винды), сколько памяти выдать - максимально - 1 Гб.
после установки (я выбрал авто-старт с гигом оперативы), обнаружились первые грабли: запуск производится под системной учетной записью, а терминал стартует с авто входом судоера cobuntu, если не читать мануал, то не очень понятно, какой у этого пользователя пароль. Ругнувшись, зачем тогда спрашивали логин / пасс при установке, выясняем:
логин - cobuntu
пароль - rescue
пароля root - нет (логично для Ubuntu)
Создаем своего пользователя:
$ sudo useradd -m mik17
$ passwd mik17
$ sudo visudo
добавляем
mik17 ALL=(ALL) ALL
Теперь поправим запись старта от имени нового пользователя:
$ sudo vim /etc/andlinux/xsession_cmd
меняем запись на
sux - mik17 /usr/local/sbin/launcher.pl
все сохраняем выходим, перезапускаем сервис самого andLinux.
Теперь при вызове терминала наблюдаем в качестве шелла sh, что за позапрошлый век! Меняем на привычный bash:
$ sudo chsh
/bin/bash
теперь при входе от имени mik17, будет привычное окружение.
Настало время разобраться с сетью. Сам сервис создает в винде интерфейс TAP-Colinux с адресацией 192.168.11.0/24 (непосредственно со стороны Windows адрес 192.168.11.1). На стороне andLinux доступ в эмулятор проходит по адресу 192.168.11.150. Внутри линуха настроены интерфейсы /etc/network/interfaces
iface eth0 inet static
address 10.0.2.15
netmask 255.255.255.0
gateway 10.0.2.2
iface eth1 inet static
address 192.168.11.150
netmask 255.255.255.0
такой хоккей нам не нужен - комментируем шлюз 10й подсети и добавляем на eth1
gateway 192.168.11.1
Разрешение имен тоже нужно поправить, добавим Гугловый ДНС:
/etc/resolv.conf
nameserver 8.8.8.8
nameserver 10.0.2.3
Со стороны эмулятора теперь с сетью должно быть все ОК, настраиваем винду поработать маршрутизатором с NAT'ом:
- включаем службу "Маршрутизация и удаленный доступ",
- на интерфейсе "Подключение по локальной сети" (если явно не переименовывать подключение - скорее всего оно так и называется) в Свойствах / Дополнительно разрешаем общий доступ подключения к Интернету. Смотрим предупреждение, что "внутренней сети" будет присвоена адресация подсети 192.168.0.0/24, соглашаемся, а потом меняем TAP-Colinux адрес обратно на 192.168.11.1.
Теперь эмулятор получил доступ во внешний мир.
Пришла очередь запуска IOU.
Где получить - микроквест для самостоятельного решения.
закидываем бинарник в /home/mik17 и пробуем стартануть... Ругается на несоответствие библиотеки, смотрим у себя в /lib/ библиотечку со схожим именем и делаем на нее ссылку:
$ sudo ln -s /lib/libcrypto.so.0.9.8 /lib/libcrypto.so.4
теперь идет ругань на файл с лицензией. Вопрос решается скриптом:
$ vim iou-lic.py
#! /usr/bin/python
print "*********************************************************************"
print "Cisco IOU License Generator - Kal 2011, python port of 2006 C version"
import os
import socket
import hashlib
import struct
# get the host id and host name to calculate the hostkey
hostid=os.popen("hostid").read().strip()
hostname = socket.gethostname()
ioukey=int(hostid,16)
for x in hostname:
ioukey = ioukey + ord(x)
print "hostid=" + hostid +", hostname="+ hostname + ", ioukey=" + hex(ioukey)[2:]
# create the license using md5sum
iouPad1='\x4B\x58\x21\x81\x56\x7B\x0D\xF3\x21\x43\x9B\x7E\xAC\x1D\xE6\x8A'
iouPad2='\x80' + 39*'\0'
md5input=iouPad1 + iouPad2 + struct.pack('!i', ioukey) + iouPad1
iouLicense=hashlib.md5(md5input).hexdigest()[:16]
print "\nAdd the following text to ~/.iourc:"
print "[license]\n" + hostname + " = " + iouLicense + ";\n"
print "You can disable the phone home feature with something like:"
print " echo '127.0.0.127 xml.cisco.com' >> /etc/hosts\n"
если скопировать этот скрипт напрямую, нужно убрать все стартовые пробелы, а отступ ioukey = ioukey + ord(x) сделать табуляцией.
в результате работы будет сформирован вывод (его можно направить в файл) с нужными параметрами. Если файл /etc/hostname не менялся, то нужный файл будет:
$ vim .iourc
[license]
andLinux = e5439a28afd220f1;
Теперь будет ругань на карту сети - файл NETMAP. По адресу http://evilrouters.net/2011/01/09/creating-a-netmap-file-for-iou/ есть неплохое объяснение, как рассчитывать интерфейсы для этой карты, у меня для теста получился простенький:
$ vim NETMAP
101:0
101:1 102:1
102:0
Теперь открываем терминальные окошки для старта рутеров:
$ ./i86bi_linux-ipbase-ms 101
и
$ ./i86bi_linux-ipbase-ms 102
в выводе sh cdp neigh можно увидеть, что у этих рутеров есть коннект на порту eth1/0.
Чтож, сама возможность запуска симулятора доказана, позднее проверю фичи - wrapper и IOUlive.
после установки (я выбрал авто-старт с гигом оперативы), обнаружились первые грабли: запуск производится под системной учетной записью, а терминал стартует с авто входом судоера cobuntu, если не читать мануал, то не очень понятно, какой у этого пользователя пароль. Ругнувшись, зачем тогда спрашивали логин / пасс при установке, выясняем:
логин - cobuntu
пароль - rescue
пароля root - нет (логично для Ubuntu)
Создаем своего пользователя:
$ sudo useradd -m mik17
$ passwd mik17
$ sudo visudo
добавляем
mik17 ALL=(ALL) ALL
Теперь поправим запись старта от имени нового пользователя:
$ sudo vim /etc/andlinux/xsession_cmd
меняем запись на
sux - mik17 /usr/local/sbin/launcher.pl
все сохраняем выходим, перезапускаем сервис самого andLinux.
Теперь при вызове терминала наблюдаем в качестве шелла sh, что за позапрошлый век! Меняем на привычный bash:
$ sudo chsh
/bin/bash
теперь при входе от имени mik17, будет привычное окружение.
Настало время разобраться с сетью. Сам сервис создает в винде интерфейс TAP-Colinux с адресацией 192.168.11.0/24 (непосредственно со стороны Windows адрес 192.168.11.1). На стороне andLinux доступ в эмулятор проходит по адресу 192.168.11.150. Внутри линуха настроены интерфейсы /etc/network/interfaces
iface eth0 inet static
address 10.0.2.15
netmask 255.255.255.0
gateway 10.0.2.2
iface eth1 inet static
address 192.168.11.150
netmask 255.255.255.0
такой хоккей нам не нужен - комментируем шлюз 10й подсети и добавляем на eth1
gateway 192.168.11.1
Разрешение имен тоже нужно поправить, добавим Гугловый ДНС:
/etc/resolv.conf
nameserver 8.8.8.8
nameserver 10.0.2.3
Со стороны эмулятора теперь с сетью должно быть все ОК, настраиваем винду поработать маршрутизатором с NAT'ом:
- включаем службу "Маршрутизация и удаленный доступ",
- на интерфейсе "Подключение по локальной сети" (если явно не переименовывать подключение - скорее всего оно так и называется) в Свойствах / Дополнительно разрешаем общий доступ подключения к Интернету. Смотрим предупреждение, что "внутренней сети" будет присвоена адресация подсети 192.168.0.0/24, соглашаемся, а потом меняем TAP-Colinux адрес обратно на 192.168.11.1.
Теперь эмулятор получил доступ во внешний мир.
Пришла очередь запуска IOU.
Где получить - микроквест для самостоятельного решения.
закидываем бинарник в /home/mik17 и пробуем стартануть... Ругается на несоответствие библиотеки, смотрим у себя в /lib/ библиотечку со схожим именем и делаем на нее ссылку:
$ sudo ln -s /lib/libcrypto.so.0.9.8 /lib/libcrypto.so.4
теперь идет ругань на файл с лицензией. Вопрос решается скриптом:
$ vim iou-lic.py
#! /usr/bin/python
print "*********************************************************************"
print "Cisco IOU License Generator - Kal 2011, python port of 2006 C version"
import os
import socket
import hashlib
import struct
# get the host id and host name to calculate the hostkey
hostid=os.popen("hostid").read().strip()
hostname = socket.gethostname()
ioukey=int(hostid,16)
for x in hostname:
ioukey = ioukey + ord(x)
print "hostid=" + hostid +", hostname="+ hostname + ", ioukey=" + hex(ioukey)[2:]
# create the license using md5sum
iouPad1='\x4B\x58\x21\x81\x56\x7B\x0D\xF3\x21\x43\x9B\x7E\xAC\x1D\xE6\x8A'
iouPad2='\x80' + 39*'\0'
md5input=iouPad1 + iouPad2 + struct.pack('!i', ioukey) + iouPad1
iouLicense=hashlib.md5(md5input).hexdigest()[:16]
print "\nAdd the following text to ~/.iourc:"
print "[license]\n" + hostname + " = " + iouLicense + ";\n"
print "You can disable the phone home feature with something like:"
print " echo '127.0.0.127 xml.cisco.com' >> /etc/hosts\n"
если скопировать этот скрипт напрямую, нужно убрать все стартовые пробелы, а отступ ioukey = ioukey + ord(x) сделать табуляцией.
в результате работы будет сформирован вывод (его можно направить в файл) с нужными параметрами. Если файл /etc/hostname не менялся, то нужный файл будет:
$ vim .iourc
[license]
andLinux = e5439a28afd220f1;
Теперь будет ругань на карту сети - файл NETMAP. По адресу http://evilrouters.net/2011/01/09/creating-a-netmap-file-for-iou/ есть неплохое объяснение, как рассчитывать интерфейсы для этой карты, у меня для теста получился простенький:
$ vim NETMAP
101:0
101:1 102:1
102:0
Теперь открываем терминальные окошки для старта рутеров:
$ ./i86bi_linux-ipbase-ms 101
и
$ ./i86bi_linux-ipbase-ms 102
в выводе sh cdp neigh можно увидеть, что у этих рутеров есть коннект на порту eth1/0.
Чтож, сама возможность запуска симулятора доказана, позднее проверю фичи - wrapper и IOUlive.
вторник, 29 марта 2011 г.
Ubuntu подключение PPTP на MS VPN шлюз.
Долгое время не залезал ВПНом в одну старенькую сеть, а тут понадобилось буквально на пару минут глянуть тамошние свичи. По привычке стартанул PPTP подключение туда, ан фигушки... Отбой. В логе интересности всякие:
NetworkManager[1000]: Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
...
pptp[3108]: nm-pptp-service-3102 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
pptp[3122]: nm-pptp-service-3102 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
pptp[3122]: nm-pptp-service-3102 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 42673).
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 0
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is 00000000, recv_accm is FFFFFFFF
pptp[3122]: nm-pptp-service-3102 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are not supported!
pppd[3104]: CHAP authentication succeeded
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 0
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is FFFFFFFF, recv_accm is FFFFFFFF
pptp[3122]: nm-pptp-service-3102 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are not supported!
pppd[3104]: LCP terminated by peer (jdL!!)
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:912]: Received Call Clear Request.
pppd[3104]: Connection terminated.
NetworkManager[1000]: VPN plugin failed: 1
...
pppd[3104]: Exit.
В процессе разбора дебага, пришел к выводу, что проблемы лежат в двух плоскостях:
1. критичность MTU для всего, что опирается на GRE - поменял на интерфейсах значения с авто (1500) на 1408,
2. включил "плюшки" для соединения VPN
убрал все типы аутентификации, кроме ms-chapv2,
использование MPPE,
stateful encryption
BSD data compression
Deflate data compression
для долгих сессий, можно пропускать пинги в PPP интерфейс, сжатие tcp заголовков не включал (хоть и p-t-p линк).
В результате соединение поднялось.
NetworkManager[1000]:
...
pptp[3108]: nm-pptp-service-3102 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
pptp[3122]: nm-pptp-service-3102 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
pptp[3122]: nm-pptp-service-3102 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 42673).
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 0
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is 00000000, recv_accm is FFFFFFFF
pptp[3122]: nm-pptp-service-3102 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are not supported!
pppd[3104]: CHAP authentication succeeded
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 0
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is FFFFFFFF, recv_accm is FFFFFFFF
pptp[3122]: nm-pptp-service-3102 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are not supported!
pppd[3104]: LCP terminated by peer (jdL!!)
pptp[3122]: nm-pptp-service-3102 log[ctrlp_disp:pptp_ctrl.c:912]: Received Call Clear Request.
pppd[3104]: Connection terminated.
NetworkManager[1000]:
...
pppd[3104]: Exit.
В процессе разбора дебага, пришел к выводу, что проблемы лежат в двух плоскостях:
1. критичность MTU для всего, что опирается на GRE - поменял на интерфейсах значения с авто (1500) на 1408,
2. включил "плюшки" для соединения VPN
убрал все типы аутентификации, кроме ms-chapv2,
использование MPPE,
stateful encryption
BSD data compression
Deflate data compression
для долгих сессий, можно пропускать пинги в PPP интерфейс, сжатие tcp заголовков не включал (хоть и p-t-p линк).
В результате соединение поднялось.
четверг, 24 марта 2011 г.
Грабли. Разрыв и переаутентификация isakmp, (deleting SA reason "Recevied fatal informational")
Столкнулся тут с весьма мозголомной баго-фичей, когда первая фаза установки тоннеля успешно проходит, это видно по sh cry isa sa, но если по этому тоннелю пытаться соединиться с удаленным хостом, то этот ентри затирается, а в дебаге видится причина:
Mar 24 14:14:30.342: ISAKMP:(1077):deleting SA reason "Recevied fatal informational" state (I) QM_IDLE (peer x.x.x.x)
Собственно, первичные настройки тоннеля опущу, так как по нему достаточно давно люди ходили куда требуется и все шло ОК, пока не потребовалось добавить доступ для нескольких наших хостов к нескольким клиентским. Переслали письмо примерно такого содержания:
с нашей стороны созданы такие листы для туннеля №х
access-list Partner1 extended permit tcp host 10.66.10.186 192.168.215.0 255.255.255.0
access-list Partner1 extended permit tcp host 10.66.1.133 192.168.215.0 255.255.255.0
запросил у нашего подразделения точные адреса хостов, которые туда должны ходить и по какому протоколу (не очень хорошо сразу всю подсеть пускать к уважаемым людям).
После того, как прислали адреса, завел запрет NAT'ить их и включил в crypto-ACL:
ip access-list extended NAT
71 deny ip host 192.168.215.40 host 10.66.10.186
72 deny ip host 192.168.215.40 host 10.66.1.133
73 deny ip host 192.168.215.136 host 10.66.10.186
74 deny ip host 192.168.215.136 host 10.66.1.133
!
ip access-list extended Crypto_Partner1
permit ip host 192.168.215.40 host 10.66.10.186
permit ip host 192.168.215.40 host 10.66.1.133
permit ip host 192.168.215.136 host 10.66.10.186
permit ip host 192.168.215.136 host 10.66.1.133
!
известно было, что доступ на эти хосты по RDP, однако добраться туда оказалось не просто...
Собственно, решением проблемы со стиранием isakmp sa при начале хождения трафика, стала замена крипто-листа с разрешения ip на разрешение tcp:
ip access-list extended Crypto_Partner1
permit tcp host 192.168.215.40 host 10.66.10.186
permit tcp host 192.168.215.40 host 10.66.1.133
permit tcp host 192.168.215.136 host 10.66.10.186
permit tcp host 192.168.215.136 host 10.66.1.133
!
по такому непонятному попробую поспрашать одного знакомого ЦиЦиЯ, может просветит, а то гугление явным образом решения не дало.
Mar 24 14:14:30.342: ISAKMP:(1077):deleting SA reason "Recevied fatal informational" state (I) QM_IDLE (peer x.x.x.x)
Собственно, первичные настройки тоннеля опущу, так как по нему достаточно давно люди ходили куда требуется и все шло ОК, пока не потребовалось добавить доступ для нескольких наших хостов к нескольким клиентским. Переслали письмо примерно такого содержания:
с нашей стороны созданы такие листы для туннеля №х
access-list Partner1 extended permit tcp host 10.66.10.186 192.168.215.0 255.255.255.0
access-list Partner1 extended permit tcp host 10.66.1.133 192.168.215.0 255.255.255.0
запросил у нашего подразделения точные адреса хостов, которые туда должны ходить и по какому протоколу (не очень хорошо сразу всю подсеть пускать к уважаемым людям).
После того, как прислали адреса, завел запрет NAT'ить их и включил в crypto-ACL:
ip access-list extended NAT
71 deny ip host 192.168.215.40 host 10.66.10.186
72 deny ip host 192.168.215.40 host 10.66.1.133
73 deny ip host 192.168.215.136 host 10.66.10.186
74 deny ip host 192.168.215.136 host 10.66.1.133
!
ip access-list extended Crypto_Partner1
permit ip host 192.168.215.40 host 10.66.10.186
permit ip host 192.168.215.40 host 10.66.1.133
permit ip host 192.168.215.136 host 10.66.10.186
permit ip host 192.168.215.136 host 10.66.1.133
!
известно было, что доступ на эти хосты по RDP, однако добраться туда оказалось не просто...
Собственно, решением проблемы со стиранием isakmp sa при начале хождения трафика, стала замена крипто-листа с разрешения ip на разрешение tcp:
ip access-list extended Crypto_Partner1
permit tcp host 192.168.215.40 host 10.66.10.186
permit tcp host 192.168.215.40 host 10.66.1.133
permit tcp host 192.168.215.136 host 10.66.10.186
permit tcp host 192.168.215.136 host 10.66.1.133
!
по такому непонятному попробую поспрашать одного знакомого ЦиЦиЯ, может просветит, а то гугление явным образом решения не дало.
Подписаться на:
Сообщения (Atom)