понедельник, 25 апреля 2011 г.

Пример PAC файла для балансировки проксей Cisco IronPort WSA.

Для клиентов, прикупивших пару Айронпортовских апплайнсов, на прошлой неделе помог составить файл автоконфигурирования (PAC - Proxy Auto-Configuration). Требования были, в принципе, простые и логичные:
- доступ к ресурсам локальной сети по IP адресам - без прокси,
- доступ к доменам, ресолвищимся в локальные адреса - без прокси,
- доступ к списку конкретных доменов - без прокси,
- балансировка обычных http запросов между проксями,
- для https запросов включен механизм (MIM - Man In the Middle) - передается основная прокся (условно №1), если она не доступна - вторая. То есть режим основной / резервный.
В результате получился такой скриптец:
function FindProxyForURL (url,host) {
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;
}
Проверку файлец выдержал, под IE и FF не встал колом.
Пара ссылок, подмогнувших в написании:
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.

вторник, 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 линк).
В результате соединение поднялось.

четверг, 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
!
по такому непонятному попробую поспрашать одного знакомого ЦиЦиЯ, может просветит, а то гугление явным образом решения не дало.

среда, 23 марта 2011 г.

Грабли. Ограничения на использование Cisco object-group.

Открыв для себя такую замечательную фичу, как object-group для составления сложных ACL'ей, с присущей восторженностью человека, поверхностно разобравшегося в теме, начал пихать использование групп куда ни попадя, во все конфиги, во все места. Расплата за это не заставила себя долго ждать - несколько часов дебага на предмет, почему "глохнет" интерфейс, если на нем применен crypto-map для VPN'ов, заставил меня вдумчиво вкурить доку: http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_object_group_acl.html, где аглицким по белому было указано, где нельзя применять группы:
Restrictions for Object Groups for ACLs
•You can use object groups only in extended named and numbered ACLs.
•Object group-based ACLs support only IPv4 addresses.
•Object group-based ACLs support only Layer 3 interfaces (such as routed interfaces and VLAN interfaces). Object group-based ACLs do not support Layer 2 features such as VLAN ACLs (VACLs) or port ACLs (PACLs).
•Object group-based ACLs are not supported with IPsec.
•The highest number of object group-based ACEs supported in an ACL is 2048.
Предпоследний пункт вправил мозг, однако осталось небольшое чувство неудовлетворенности от осознания несовершенства даже такой замечательной ОС как Cisco IOS...
К стыду разработчиков, при применении crypto ACL с группами, никаких информационных сообщений о том, что так делать нельзя, не появляется - веселье начинается чуть позже, когда пробуешь догадаться, какой дебаг включать.

воскресенье, 20 марта 2011 г.

Небольшое допиливание Ubuntu 10.10. Часть 2.

Решив на досуге засмотреть какое-нибудь кино, обнаружил еще один трабл, который, правда, присущ всем обновлениям - захотелось мне посмотреть фильм "Криминальное чтиво" в Гоблинском переводе. Фильма пошла, правда без звука. Для выяснения причин такого поведения плейера ушли некоторые усилия: понятно, что дело в кодеке, соответственно, встал вопрос, а как посмотреть, какой кодек нужен (про то, что это можно легко сделать штатными средствами, я пока не знал). Путем гугления был обнаружен тул mediainfo (http://mediainfo.sourceforge.net/ru/Download/Ubuntu) - графическая надстройка (впрочем кривого исполнения) для просмотра метаданных видео файлов. С помощью этой утилиты, выяснилось, что используется проприетарный звуковой кодек VoxWare, дальнейшие изыскания прояснили, что этот несвободный кодек можно получить из спец репозитория, но при обновлении из /etc/apt/sources.list убираются репозитории Medibuntu, в которых располагаются такие полезняшки, как w32codecs и non-free-codecs. Соответственно, подключаем репу и апдейтим список:
sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update
Теперь ставим кодеки:
sudo apt-get install w32codecs non-free-codecs
В результате - щасте от просмотра бодрого кина.
Чуть позже знающие люди сообщили, что ряд телодвижений, проделанных для определения кодека (установка графической тулзы), был излишним - при запуске mediaplayer'а из консоли, в ней замечательно рисуются нужные параметры (и кодеки, в том числе):
mik17@mik17-desktop:~/.gvfs/shara1 on mediaserv$ mplayer ./Films/'Криминальное чтиво - Pulp Fiction.avi'
MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team
...
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffdivx] vfm: ffmpeg (FFmpeg DivX ;-) (MSMPEG-4 v3))
==========================================================================
==========================================================================
Opening audio decoder: [dshow] Win32/DirectShow decoders
AUDIO: 44100 Hz, 2 ch, s16le, 96.1 kbit/6.81% (ratio: 12016->176400)
Selected audio codec: [voxware] afm: dshow (VoxWare)
==========================================================================
...

вторник, 15 марта 2011 г.

Cisco DHCP сервер. Настройка статической выдачи по MAC'ам.

Пришлось тут копнуть поглубже настройки DHCP на цисковских рутерах. Задачка, вначале казавшаяся тривиальной в результате вылилась во вполне себе серьезное исследование с тестами разнообразного железа.
Собственно, задача: для подключения NAS'а хотят использовать static-DHCP вместо просто статического адреса. От предыдущего инженегра поступил кусок конфига:
ip dhcp pool NAS1
host 192.168.250.15
hardware-address 00xx.xxxx.xxxx
не заработало, железяка упорно не хотела забирать положенный адрес.
Перекинули на меня, решил тестить с имеющимися девайсами:
1. Бук по WinXP
2. Cisco Phone 7911
3. Бук с Убунтой (прошива на NAS'е - тоже какой-то Линь)
4. Бук с 7й.
В процессе исследования решил не использовать параметр hardware-address, вместо этого получилась такая конфига:
ip dhcp pool WinXP
host 172.16.1.238 255.255.255.0
client-identifier 0100.1cxx.xxxx.xx
default-router 172.16.1.1
dns-server 172.16.1.1
!
ip dhcp pool CP7911
host 172.16.1.241 255.255.255.0
client-identifier 0100.1dxx.xxxx.xx
default-router 172.16.1.1
dns-server 172.16.1.1
!
ip dhcp pool Ubuntu
host 172.16.1.225 255.255.255.0
client-identifier 0100.22xx.xxxx.xx
default-router 172.16.1.1
dns-server 172.16.1.1
!
ip dhcp pool Win7ka
host 172.16.1.213 255.255.255.0
client-identifier 0100.23xx.xxxx.xx
default-router 172.16.1.1
dns-server 172.16.1.1
!
Что здесь интересно, так это использование client-identifier с добавлением в начало htype параметра. Как показала практика - значение "01" (Ethernet) подходит во всех протестированных случаях, для вкуривания других значений - можно обратиться к доке:
http://www.iana.org/assignments/arp-parameters/
В дебаге сам успешный процесс получения адреса выглядит так (для Windows Seven):
*Oct 3 08:23:37.172: DHCPD: Sending notification of DISCOVER:
*Oct 3 08:23:37.172: DHCPD: htype 1 chaddr 0023.xxxx.xxxx
*Oct 3 08:23:37.172: DHCPD: remote id 020a0000ac100101ff000000
*Oct 3 08:23:37.172: DHCPD: circuit id 00000000
*Oct 3 08:23:37.176: DHCPD: htype 1 chaddr 0023.xxxx.xxxx
*Oct 3 08:23:37.176: DHCPD: remote id 020a0000ac100101ff000000
*Oct 3 08:23:37.176: DHCPD: circuit id 00000000
*Oct 3 08:23:37.196: DHCPD: Sending notification of DISCOVER:
*Oct 3 08:23:37.196: DHCPD: htype 1 chaddr 0023.xxxx.xxxx
*Oct 3 08:23:37.196: DHCPD: remote id 020a0000ac100101ff000000
*Oct 3 08:23:37.196: DHCPD: circuit id 00000000
*Oct 3 08:23:37.200: DHCPD: htype 1 chaddr 0023.xxxx.xxxx
*Oct 3 08:23:37.200: DHCPD: remote id 020a0000ac100101ff000000
*Oct 3 08:23:37.200: DHCPD: circuit id 00000000
*Oct 3 08:23:37.204: DHCPD: Sending notification of ASSIGNMENT:
*Oct 3 08:23:37.204: DHCPD: address 172.16.1.213 mask 255.255.255.0
*Oct 3 08:23:37.204: DHCPD: htype 1 chaddr 0023.xxxx.xxxx
*Oct 3 08:23:37.204: DHCPD: lease time remaining (secs) = 4294967295
Здесь виден заданный нами htype 1.
ГРАБЛИ!
С Убунтовой машиной пришлось допилить конфиг DHCP клиента:
$ sudo vim /etc/dhcp3/dhclient.conf
раскомментировать строку
send dhcp-client-identifier 1:0:22:xx:xx:xx:xx
вначале также указываем htype ("1"), потом идет MAC (первый 00 сокращено до 0).