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

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

Грабли. Ограничения на использование 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 с группами, никаких информационных сообщений о том, что так делать нельзя, не появляется - веселье начинается чуть позже, когда пробуешь догадаться, какой дебаг включать.

Небольшое допиливание 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)
==========================================================================
...

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).