Cisco ISR в качестве PPTP клиента не в сети провайдера

Один из клиентов для периодического мониторинга и помощи в настройке оборудования выдал два аккаунта pptp, но с маленькой оговоркой: не проходят 2 одновременных подключения с одного аккаунта (логично), не проходят 2 подключения с одного IP. Так как часто случается, что в чужой сетке должны одновременно ковыряться 2-3 инженегра, сначала извращались с NAT'ом через виндовую машину, подключенную по одному акку, потом решили настроить клиента на пограничной циске и изобразить периодичность работы - клиент коннектится с 9 по 21 по будним дням. Доступ в 4 подсети клиента (10.4.0.0/16, 10.5.0.0/16, 10.10.0.0/16, 10.11.100.0/24) требовался из 2х подсетей (192.168.215.0/24, 192.168.221.0/24). В результате получился такой конфиг:
ip access-list extended NAT
 73 deny ip 192.168.221.0 0.0.0.255 10.4.0.0 0.0.255.255
 74 deny ip 192.168.221.0 0.0.0.255 10.5.0.0 0.0.255.255
 75 deny ip 192.168.221.0 0.0.0.255 10.10.0.0 0.0.255.255
 76 deny ip 192.168.221.0 0.0.0.255 10.11.100.0 0.0.0.255
 77 deny ip 192.168.215.0 0.0.0.255 10.4.0.0 0.0.255.255
 78 deny ip 192.168.215.0 0.0.0.255 10.5.0.0 0.0.255.255
 79 deny ip 192.168.215.0 0.0.0.255 10.10.0.0 0.0.255.255
 69 deny ip 192.168.215.0 0.0.0.255 10.11.100.0 0.0.0.255
! убираем нужные подсети из общего NAT'а
Теперь включаем недокументированную функция IOS service internal и настраиваем параметры vpdn с Dialer интерфейсом:
service internal
no service pass
!
no ip gratuitous-arps
!
ip multicast-routing
!
vpdn enable
!
vpdn-group 2
  request-dialin
    protocol pptp
    rotary-group 1 ! указываем номер Dialer интерфейса
  initiate-to ip xxx.xxx.xx1.xxx ! адрес PPTP сервера
!
interface Dialer1
  dialer in-band ! ВАЖНО, чтобы этот параметр при настройке шел первым
  mtu 1450
  ip address negot ! получаем адрес от сервера
  ip nat out ! будем NAT'ить через полученный адрес наши подключения
  ip pim dense-mode
  encapsulation ppp
  dialer idle-timeout 0
  dialer string 123
  dialer vpdn
  dialer-group 2 ! указываем vpdn группу
  no cdp enable
  no peer neighbor-route ! не даем передать нам с PPTP сервера дефолтный маршрут
  ppp pfc local request
  ppp pfc remote apply
  ppp encrypt mppe auto
  ppp chap hostname USERNAME
  ppp chap password 0 PASSWORD
!
dialer-list 1 protocol ip permit
Проверяем. произошло ли подключение и получен ли адрес (sh ip int brie)
Теперь необходимо прописать маршруты в нужные подсети и NAT'ить наши обращения туда (так как с другой стороны железо не знает о маршрутах в наши подсети).
ip route 10.4.0.0 255.255.0.0 dial 1
ip route 10.5.0.0 255.255.0.0 dial 1
ip route 10.10.0.0 255.255.0.0 dial 1
ip route 10.11.100.0 255.255.255.0 dial 1
! сети доступны через интерфейс Dialer1
ip access ext FIRM_NAT_PPTP
 permit ip 192.168.221.0 0.0.0.255 10.4.0.0 0.0.255.255
 permit ip 192.168.221.0 0.0.0.255 10.5.0.0 0.0.255.255
 permit ip 192.168.221.0 0.0.0.255 10.10.0.0 0.0.255.255
 permit ip 192.168.221.0 0.0.0.255 10.11.100.0 0.0.0.255
 permit ip 192.168.215.0 0.0.0.255 10.4.0.0 0.0.255.255
 permit ip 192.168.215.0 0.0.0.255 10.5.0.0 0.0.255.255
 permit ip 192.168.215.0 0.0.0.255 10.10.0.0 0.0.255.255
 permit ip 192.168.215.0 0.0.0.255 10.11.100.0 0.0.0.255
!
ip nat inside source list FIRM_NAT_PPTP int Dial 1 over
Теперь обращения из наших подсетей успешно доходят до нужных хостов и есть возвратный трафик.
Чтобы подключение не висело постоянно, через Embeded Event Manager (EEM) настроим включение/выключение интерфейса по таймеру:
event manager applet FIRM_PPTP_START
 event timer cron name FIRM_STRT cron-entry "0 9 * * 1-5"
 action 1.0 cli command "enable"
 action 2.0 cli command "conf t"
 action 3.0 cli command "int dial 1"
 action 4.0 cli command "no shu"
!
event manager applet FIRM_PPTP_STOP
 event timer cron name FIRM_STOP cron-entry "0 21 * * 1-5"
 action 1.0 cli command "enable"
 action 2.0 cli command "conf t"
 action 3.0 cli command "int dial 1"
 action 4.0 cli command "shu"
Небольшая ремарка по синтаксису условия (event timer cron): параметр cron-entry записывается в кавычках (в документации на cisco.com эта особенность была упущена). Обозначение параметра "0 9 * * 1-5" - 0 минут 9 часов * любой день * любой месяц 1-5 день недели с понедельника по пятницу (нумерация с 0 до 6, где 0 - воскресение, а 6 - суббота).

Несколько IPSec туннелей с crypto-map и NAT'ом внутри туннеля

Некоторое время назад возникла необходимость туннелировать трафик к одному из партнеров, используя внутри туннеля внешнюю адресацию. В результате получился весьма любопытный конфиг, где вместе присутствуют три варианта L2L туннелей: классический с частными подсетями на концах, второй с внешними маршрутизируемыми адресами и третий между частной подсетью и внешним адресом, про него и комментарий:
базовая настройка, вкратце, такова - int fas 0/1 - WAN (IP xxx.xx1.xxx.xxx/27) на нем криптокарта PART_VPN, int fas 0/0 - LAN (IP 192.168.221.0/24), требование, чтобы в сеть партнера 10.201.20.48/28 было обращение с внешнего(их) адреса(ов), требование, конечно, необычное, но нежелание админа с другой стороны маяться с пересекающимися адресными диапазонами (если такие появятся), было понятно. Скорее всего, можно было бы просто взять "левый" адрес, типа 1.253.23.200, но нашлась "честная" подсеть, из которой "одолжили" адресок для поNATить (xxx.xx2.xxx.xxx/26). Получилось неплохо:
int fas 0/1
 ip addr xxx.xx1.xxx.xxx 255.255.255.224
 ip nat out
 crypto-map PART_VPN
 ...
!настройка WAN интерфейса
ip access-list extended NAT
 71 deny   ip 192.168.221.0 0.0.0.255 10.201.20.48 0.0.0.15
! убираем из общего NAT'а туннельный трафик
crypto isakmp policy 60
 encr 3des
 authentication pre-share
 group 2
 lifetime 28800
crypto ipsec transform-set PARTNER_VPN6 esp-3des esp-sha-hmac
! определяем параметры фаз
crypto isakmp key *** address yyy.yy1.yyy.yyy no-xauth
! ключ для пира на стороне партнера
ip nat pool IP_FOR_NAT xxx.xx2.xxx.xxx xxx.xx2.xxx.xxx prefix-length 26
ip access-list extended FROM_221_TO_NAT
 permit ip 192.168.221.0 0.0.0.255 10.201.20.48 0.0.0.15
! фильтр для пакетов в подсеть партнера для последующего NAT'а
ip nat inside source list FROM_221_TO_NAT pool IP_FOR_NAT overload
! собственно сама трансляция адресов по фильтру
ip access-list extended VPN6-ACL
 permit ip host xxx.xx2.xxx.xxx 10.201.20.48 0.0.0.15
! так как адрес теперь заNATчен, то его гоним в туннель, как interesting трафик
crypto map PART_VPN 60 ipsec-isakmp
 set peer yyy.yy1.yyy.yyy
 set transform-set PARTNER_VPN6
 set pfs group2
 match address VPN6-ACL
! добавляем запись в криптомап для данного туннеля
Для удобства и понимания, конечно, стоило бы прописать description'ы, особенно, когда в большом конфиге эти настройки разбросаны по разным углам...

Ошибка апдейта .ICEauthority при входе в Ubuntu

После недавнего апгрейда стала появляться ошибка:
Cannot update /home/mik17/.ICEauthority
для борьбы с ошибкой:
sudo chown mik17:mik17 /home/mik17/.ICEauthority
sudo chmod 644 /home/mik17/.ICEauthority
sudo reboot

Добавление интерфейса в kismet.conf

Сразу после установки Kismet:
sudo apt-get install kismet
при попытке его запуска появится сообщение об ошибке - не настроены источники (интерфейсы) в файле /etc/kismet/kismet.conf
для определения, какие парамтры вводить воспользуемся такими командами:
iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11bg Mode:Monitor Frequency:2.462 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
  Power Management:off
pan0 no wireless extensions.
vboxnet0 no wireless extensions.
теперь определим какой драйвер (модуль) управляет интерфейсом:
lsmod | grep 80211
mac80211 205146 1 ath5k
cfg80211 126517 3 ath5k,mac80211,ath
Итак, в конфигурационный файл вписываем параметры:
source=ath5k,wlan0,laptop card
теперь проблем с запуском нет
sudo kismet

Репозиторий Яндекса для Debian Lenny

С какого-то времени перестал отвечать официальный репозиторий по адресу http://ftp.ru.debian.org/debian/, для продолжения "извращений" с NSLU2 (Debian под ARM процессоры) подключил в качестве основного репозиторий с зеркала Яндекса:
в /etc/apt/sources.list добавлено:
deb http://mirror.yandex.ru/debian/ lenny main
deb-src http://mirror.yandex.ru/debian/ lenny main
после сохранения - apt-get update!

Расчет параметров rate-limit для QoS'а на Cisco

Для ограничения полосы на интерфейсе, если использование policy-map по каким-то причинам не желательно, используется rate-limit:
int fas0/0.15
rate-limit output 'rate' 'burst_norm' 'burst_max' conform-action transmit exceed-action drop
для определения параметров 'burst_norm' и 'burst_max' можно воспользоваться рекомендацией:
Burst-normal = configured rate * 1/8 * 1.5 seconds
Burst-max = Burst-normal * 2
Таким образом для ограничения полосы, например, 128k получим:
rate-limit output 128000 24000 48000 conform-action transmit exceed-action drop

Включение группового чата (конференции) в Я.Онлайн

В клиенте Я.Онлайн такая функциональность заложена, но отключена. Для ее активации необходимо поправить сроку в файле /home/-user-/.yachat/profiles/default/options.xml
в теге Enable multi-user chat functionality заменим false на true, сохраняемся и при запуске клиента в настройках будет доступен пункт "Конференция" (самый верхний, жирный...).
Дальше можно подключаться к группвому чату  - да хотябы по вечерам субботы к online@conference.radio-t.com

Проблемы с вводом кирилического (русского) текста в Opera 10.60 в Ubuntu

После выхода новой Opera 10.60 в некоторых дистрибутивах, включая Ubuntu 10.04 был выявлен баг: невозможность ввода текста в кириллической раскладке (например, в строке поиска, что критично). В качестве временной меры до исправления бага (он был признан и уже поправлен) можно было воспользоваться скриптом запуска Opera:
$ vim opera-1.sh
#!/bin/bash
LANG=ru_RU.UTF-8
GTK_IM_MODULE=none
XMODIFIERS=@im=none
opera
$ sudo chmod +x opera-1.sh
После запуска Оперы этим скриптом проблема исчезала.
По информации от разработчиков данный баг был связан с тем, что в версии 10.60 некоторые компоненты были переписаны для использования Юникода в формате UTF-8, в то время, как отдельные (пострадавшие) дистрибутивы используют локаль в формате utf8 (даже при настроенных алиасах этих форматов в файле /usr/share/X11/locale/locales.alias).

Ubuntu 8.04.4 как обычный маршрутизатор (не шлюз).

Недавно возникла необходимость в виртуальном маршрутизаторе с 3мя интерфейсами, глядящими в три разные подсети. Первоначально решение вопроса казалось легким и непринужденным - прописать статические маршруты, но в процессе работы стало очевидно, что интерфесы пытаются отдать трафик через тот же интерфейс, с которого они его получили. То есть маршрутизатор не маршрутизировал.
Были сделаны такие сетевые настройки:
/etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.221.17
        netmask 255.255.255.0
        network 192.168.221.0
        broadcast 192.168.221.255
        gateway 192.168.221.253
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.221.105
        #dns-search citrix.demo
auto eth1
iface eth1 inet static
        address 192.168.223.1
        netmask 255.255.255.128
        network 192.168.221.0
        broadcast 192.168.221.127
        up route add -net 192.168.222.0/24 gw 192.168.223.10 dev eth1
auto eth2
iface eth2 inet static
        address 192.168.223.129
        netmask 255.255.255.128
        network 192.168.221.128
        broadcast 192.168.221.255
дополнительно же было необходимо раскоментировать строчку в
/etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
После этого виртуальный роутер заработал.

Базовые настройки Linksys SPA 3102/2102 с аналогового телефона (кусок мануала).

Иногда приходится сталкиваться с ситуациями, когда неизвестно, какой адрес назначен голосовому шлюзу, или его нужно оперативно сбросить к заводским настройкам, а диска с мануалом под рукой нет.
Итак - выдержки из мануала для сервисного меню:
**** - вход в режим голосового интерфейса (эти 4 "звездочки", астериска набираются в тональном режиме, поэтому для телефонов, имеющих по умолчанию настройку импульсного набора нужно будет набрать еще одну - первая переведет в тональник, остальные 4 в меню).
Женским голосом на нагицком наречии будут даваться краткие инструкции, типа, после ввода кода подтвердите "решеткой" - шарпом, также сохранение настроек - 1, иногда за основным кодом, предоставляющим выбор настройки будет следовать субкод (одноциферный).
100 - Узнать тип WAN подключения (скажут DHCP / Static / PPPoE), вообще 1хх для WAN'а
110 - проговаривается WAN IP адрес
120 - маска
130 - шлюз по умолчанию
140 - узнать mac адрес
150 - версия прошивки
160 - адрес первичного DNS
170 - номер порта для веб-морды
101 - выставить тип подключения (0 - DHCP, 1 - Static IP, 2 - PPPoE)
111 - выставить статический адрес (точки в адресе - астериском *)
121 - выставить маску
131 - выставить шлюз
161 - выставить DNS
210 - прослушать локальный адрес (2хх - для LAN сегмента)
201 - установить режим работы (0 - c NAT'ом, как маршрутизатор, 1 - мостовое соединение bridge)
7932 - доступ к настройкам извне (0 - разрешить, 1 - запретить)
732668 - ручная перезагрузка
73738 - сброс к заводским настройкам (1 - подтверждение, * - отмена)
877778 - User Factory Reset (его половой функции так и не понял - вроде бы сделать текущие настройки заводскими он не позволяет)
При выборе внешненго подключения по PPPoE - нужно быть готовым к сексу с набором имени пользователя и пароля с телефонной клавиатуры...
В качестве примера быстрая настройка шлюза для доступа на него с телефона с импульсным набором (выставляем статический адрес и даем доступ на веб интерфейс с WAN):
*****101#1#1 111#192*168*0*11#1 121#255*255*255*0#1 7932#1#1

Удаление Cisco VPN Client из Windows XP после неудачной установки.

В очередной раз убедился, что программисты в Циске не слишком внимательно относятся к разного рода апдейтам в Винде, что недавно привело к сбою в процессе установки VPN клиента на ХРюшу. Результатом был покоцанный IP стек, что решалось отключением Deterministic Network Enhancer'а. Собственно сам клиент и не думал работать - просто забивал блок памяти, а выкуривался завершением процесса. Штатным образом из Установки/Удаления программ также снести клиента не выходило - ведь установка не завершилась до конца, так этот надоедливый гад и висел в системе, через некоторое время даже сделавшись привычным. Однако, когда потребовалась переустановка Cisco Communicator'а, встала срочная необходимость прибить все Цисковкие компоненты, так как новые просто не могли установиться. Поэтому вычищаем VPN клиента из системы:
Для начала удаляем ключи реестра:
HKEY_LOCAL_MACHINE \ SOFTWARE \ Cisco Systems \ VPN Client
HKEY_LOCAL_MACHINE \ SOFTWARE \ Deterministic Networks
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Uninstall \ {5624c000-b109-11d4-9db4-00e0290fcac5}
также проверяем другие ключи на предмет упоминания о VPN Client
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ RunOnce \ CISCOREBOOTFLAG
Теперь удаляем некоторые каталоги и файлы (часть может оказаться заблокированной - для их удаления можно воспользоваться FAR'ом или удалить все незаблокированные, а потом прибить остальных после перезагрузки) .
?С\Program Files\Cisco Systems\VPN Client
?С\Program Files\Common Files\Deterministic Networks
?Windows\system32\drivers\dne2000.sys
?Windows\inf\dne2000m.inf и dne2000m.pnf
 ?Windows\system32\dneinobj.dll
 ?Windows\system32\drivers\cvpndrv.sys или cvpndrva.sys
переименуем файл ?Windows\system32\CSGina.dll в CSGina.old
теперь можно перезагрузиться и убедиться, что в системе больше нет Cisco VPN интерфейса.




   

Жонглирование LACP транками и Vlan на HP ProCurve.

Две модульные железки 5348XL и 5304XL, первая уже давно нагружена под завязку, а вторая до недавнего времени прохлаждалась почем зря. Итак, вводные: на 5348 несколько vlan'ов (нас интересуют vlan 6 и vlan 2 с адресами 192.168.215.110 и 192.168.221.253 соответственно), включена маршрутизация, от портов C15, C16 два шланга уходят на 5304 в порты A15, A16, есть vlan 1 с адресом 192.168.215.201 (это выянилось по CDP). Задача - составить транк для подсети 192.168.221.0/24 и присвоить 5304 адрес 192.168.221.203.
Основная проблема - сами железки далеко, а отрубить себя от второго девайса - дело одной ошибки (а тогда коммандировка неизбежна). Очевидно, что нам надо перетащить второй девайс в vlan 2.
Пока у нас нет доступа на 5304 - он виден только как CDP neighbour, перетянем порты на 5348 в 6 влан:
vlan 6
   untagged C15-C16
   ip address 192.168.215.110 255.255.255.0
теперь можем коннектиться на 5304 для настройки,
добавляем на дефолтный влан второй адрес:
vlan 1
   name "DEFAULT_VLAN"
   untagged A15-A16
   ip address 192.168.215.201 255.255.255.0
   ip address 192.168.221.203 255.255.255.0
убираем ненужный адрес (приведет к дисконнекту):
    no ip address 192.168.215.201 255.255.255.0
перекидываем на 5348 порты в vlan 2
vlan 2
   untagged С15-С16
   ip address 192.168.221.253 255.255.255.0
проверяем доступность 5304, заходим для настройки транков, основная проблема в том, что транк будет привязываться к vlan'у не как порты, а как trk# интерфейс, то есть нам сначала надо объединить порты в транк, а потом вязать с vlan. Но выянилась небольшая деталь - такую явную привязку нужно делать только для портов в активном режиме (используется LACP), а пассивные порты явным образом в trk# не вяжутся, поэтому сначала настраиваем доступный 5348:
trunk C15-C16 Trk2 LACP
vlan 2
   untagged Trk2
проверяем доступность второго девайса и заходим для настройки:
trunk А15-А16 Trk2 LACP
vlan 1
   untagged Trk2
должны (и будут) выдаваться ошибки о том, что порты уже находятся в динмической группе, но это нам и надо - это подтверждение правильности действий. Дополнительно просматриваем состояние каналов show lacp:
на 5348
   C15    Active    Trk2      Up        Yes       Success
   C16    Active    Trk2      Up        Yes       Success
на 5304
   A15    Passive   Dyn1      Up        Yes       Success
   A16    Passive   Dyn1      Up        Yes       Success