[Abram]

./ISG.pl show_services Virtual15
User IP-address NAT IP-address  Port number   Uniq. Identifier Durat.  Octets-in  Octets-out Rate-in    Rate-out   Service name     Flags

показывает только заголовки, хотя без параметров ISG.pl показывает сессии

Я ответил уже в личку, но для полноты картину отпишусь и сюда.

Это нормально. Такой вывод значит, что для сессии Virtual15 не применен ни один сервис.

[Dimka88]

Сколько записей 1-to-1 NAT? Покажите вывод iptables-save. Что говорит top, когда сервер тормозит?

до 10 записей падало. Данная проблема решилась отказом от Debian в сторону Gentoo (по срокам стояло починить скорее.) Немного дописал код, для задания 1-to-1 NAT и добавил маршрутизацию по OSPF. Работает на малых объёмах без нареканий. Пока 50 активных.

[Cramac]

Я ответил уже в личку, но для полноты картину отпишусь и сюда.

Это нормально. Такой вывод значит, что для сессии Virtual15 не применен ни один сервис.

Все заработало, метка эта срабатывает только в том случае, если радиус отвечает rejected user (в биллинге аккаунт есть, пароль левый, денег нет)

В остальных случаях, когда логин в базе есть, пароль=IP абонента, хоть есть деньги, хоть нет денег, сессия не метится как неавторизированная.

 

Это где то мой косяк, или что то надо подправить?

Биллинг UTM радиус их же.

 

Вот в таком варианте метит:

?Debug : Jul 31 17:13:12 AuthServer: User <10.10.10.33> connecting
?Debug : Jul 31 17:13:12 AuthServer: Session for sessionid <10.10.10.33> not found in <10.10.10.10> cache
?Debug : Jul 31 17:13:12 RADIUS DBA: Info for login <10.10.10.33> found. type <1>
?Debug : Jul 31 17:13:12 AuthServer: Auth scheme: PAP
?Debug : Jul 31 17:13:12 AuthServer: PAP: <79bcae> vs <10.10.10.33>
?Debug : Jul 31 17:13:12 AuthServer: PAP: Rejected user <10.10.10.33>
Notice: Jul 31 17:13:12 AuthServer: Login incorrect <10.10.10.33> from NAS <10.10.10.10> CLID <127.0.0.1> Calling-station <10.10.10.33>
Notice: Jul 31 17:13:12 AuthServer: Authorization failed for user <10.10.10.33>

 

в таком варианте, уже не метит:

?Debug : Jul 31 17:32:37 AuthServer: User <10.10.10.33> connecting
?Debug : Jul 31 17:32:37 AuthServer: Session for sessionid <10.10.10.33> not found in <10.10.10.10> cache
?Debug : Jul 31 17:32:37 RADIUS DBA: Info for login <10.10.10.33> found. type <1>
?Debug : Jul 31 17:32:37 AuthServer: Auth scheme: PAP
?Debug : Jul 31 17:32:37 AuthServer: PAP: <10.10.10.33> vs <10.10.10.33>
?Debug : Jul 31 17:32:37 AuthServer: PAP: Authorized user <10.10.10.33>
?Debug : Jul 31 17:32:37 AuthServer: Blocked user is going to login...
?Debug : Jul 31 17:32:37 AuthServer: Calling fill radius attributes for NAS. Attr storage size <0>
Notice: Jul 31 17:32:37 AuthServer: Login incorrect <10.10.10.33> from NAS <10.10.10.10> CLID <127.0.0.1> Calling-station <10.10.10.33>
Notice: Jul 31 17:32:37 AuthServer: Authorization failed for user <10.10.10.33>

[Abram]

Cramac,

Значит, отвечает Access-Accept. Посмотри raddump-ом, какая разница между двумя ответами.

[Cramac]

что то raddump ничего мне не показывает....посмотрел tcpdump

отвечает всегда Code: Access-Reject (3)

 

П.С. повставлял по больше выводов в код, смотрю не срабатывает условие. При приходе отказа, срабатывает условие

if ($rp->vsattributes($rad_dict->vendor_num("Cisco"))) {

у меня возвращает h323-return-code

и дальше не идет.

 

если убрать это значение из циско словаря радбазы, то все обрабатывается как положено. Все сразу метится...

 

П.С. А как вы боретесь с теми кто подменяет свой ИП на чужой, который уже прошел авторизацию?

П.С.С. и как можно обработать скорость передаваемую через радиус атрибуты? В данный момент у нас передается два атрибута (230 и 231) в виде строки.

[Abram]

П.С. А как вы боретесь с теми кто подменяет свой ИП на чужой, который уже прошел авторизацию?

П.С.С. и как можно обработать скорость передаваемую через радиус атрибуты? В данный момент у нас передается два атрибута (230 и 231) в виде строки.

1. DHCP Option 82 + DHCP Snooping.

2. Ну либо передавайте так, как хочет lISG, либо пилите его код - пусть обрабатывает так, как хотите вы. =)

[Wingman]

А кто как делает 1-to-1 nat в новых версиях?

 

Почему-то старый способ со скелетонами (перенёс из старого ISG) на ядре 3.9 клал процы в полку (perf top показывает затык в ipt_do_table)

 

Пока сделал не слишком красиво :)

 

ipset create d_nat hash:ip
ipset create s_nat hash:ip

-A POSTROUTING -m set --match-set s_nat src -j s_nat
-A PREROUTING -m set --match-set d_nat dst -j d_nat

 

Ну и в isgd.pl

   if( $act eq "add" )
   {
       `iptables -t nat -A s_nat -s $local_ip -j SNAT --to-source $real_ip`;
       `iptables -t nat -A d_nat -d $real_ip -j DNAT --to-destination $local_ip`;
   } elsif ( $act eq "del" ) {
       `iptables -t nat -D s_nat -s $local_ip -j SNAT --to-source $real_ip`;
       `iptables -t nat -D d_nat -d $real_ip -j DNAT --to-destination $local_ip`;
   }
   `ipset $act s_nat $local_ip`;
   `ipset $act d_nat $real_ip`;

Изменено 11 августа, 2013 пользователем Wingman

[Abram]

Wingman,

Олег должен был выложить helper для новых версий.

Лично я просто использую старые.

[Wingman]

Старые под 3.9 не очень собираются)

[Abram]

Старые под 3.9 не очень собираются)

Так взять из нового ядрёный модуль и всё.

[Wingman]

Хм, и новый модуль + старый юзерспейс без проблем работают? Странно даже )

[Abram]

Хм, и новый модуль + старый юзерспейс без проблем работают? Странно даже )

Ну или сделать патч-наоборот из коммита, в котором Олег убрал NAT.

[Wingman]

Да нет, меня бы как раз больше устроил неизменённый интерфейс ISG/ISGd, если он работает с новым модулем

У вас таким макаром оно давно в продакшне?

[Wingman]

А Олег топик просматривает? Таки запустил последний модуль с последним софтом, возник вопрос: в новом ядерном модуле ничего с блокировками не перемудрили? Такая вот картина возникла по нагрузке на процы:

 

В топе лидирует raw_spin_lock_bh

На том проце, где нагрузка больше - входящий трафик в сторону абонентов, который попадает в `-A FORWARD -d _users_ -j ISG`

[Abram]

Да нет, меня бы как раз больше устроил неизменённый интерфейс ISG/ISGd, если он работает с новым модулем

У вас таким макаром оно давно в продакшне?

Нет, у меня старые ядра и старый модуль.

Просто я не вижу причины, по которой оно не должно работать.

[Wingman]

Например, таймаут неактивной сессии в старых версиях задавался и отслеживался в модуле, в новых задаётся в юзерспейсе

[Cramac]

немного не в тему, но, как вы резервируете сервера или просто распределяете нагрузку?

[Wingman]

Мы резервируем никак :) Ну то бишь аналогичной машинкой, которой можно за минуту заменить вышедшую из строя

Распределение:

Вариант 1: source-based routing на чём-нибуть вроде 6500

Вариант 2: одна какая-нибуть 3750 -> на один шлюз

 

Ну и сейчас у меня на одном тазике трафик перевалил за 4гбпс, процы загружены на 50%, только сейчас начинаю о распределении задумываться :)

[archim]

Ни у кого не случалось время от времени такого?

$ ISG.pl show_count

Approved sessions count:-4294965328

Unapproved sessions count:4294965328

$

 

Может как-то лечится?

[Abram]

Cramac,

У меня два сервера. Напомни, в понедельник расскажу.

[kayot]

Ни у кого не случалось время от времени такого?

$ ISG.pl show_count

Approved sessions count:-4294965328

Unapproved sessions count:4294965328

$

 

Может как-то лечится?

А почему вы считаете что ваши проблемы обязательно какие-то уникальные, не читаете readme и даже поиском не пробуете пользоваться?

Даже я, бесконечно далекий от данного проекта знаю что http://forum.nag.ru/forum/index.php?showtopic=53156&st=560&p=659458entry659458

[Abram]

Насчет резервирования.

Схема такова: есть N L3-свитчей на аггрегации и два lISG-сервера (больше пока не надо).

Каждый из серверов смотрит одним интерфейсом в VLAN, в котором торчат свитчи, другим - в мир.

IP серверов - 10.0.0.151/24 и 10.0.0.152/24 соответственно.

На обеих запущен keepalived, который ведает VRRP:

 

lisg1:

! Configuration File for keepalived

global_defs {
  router_id lisg1
}

vrrp_instance VI_1 {
   state MASTER
   interface bond0
   virtual_router_id 101
   priority 100
   advert_int 1
   virtual_ipaddress {
       10.0.0.101/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

vrrp_instance VI_2 {
   state BACKUP
   interface bond0
   virtual_router_id 102
   priority 50
   advert_int 1
   virtual_ipaddress {
10.0.0.102/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

 

lisg2:

! Configuration File for keepalived

global_defs {
  router_id lisg2
}

vrrp_instance VI_1 {
   state BACKUP
   interface bond0
   virtual_router_id 101
   priority 50
   advert_int 1
   virtual_ipaddress {
       10.0.0.101/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

vrrp_instance VI_2 {
   state MASTER
   interface bond0
   virtual_router_id 102
   priority 100
   advert_int 1
   virtual_ipaddress {
10.0.0.102/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

 

Первый сервер, таким образом, получает еще один IP - 10.0.0.101, второй, соответственно - 10.0.0.102. На эти же адреса указываются default route в L3-свитчах (балансируется экспериментально).

В случае отключения одного из серверов второй поднимет у себя его IP и трафик потечет через него.

 

Подводные камни:

1) L3-свитчи должны уметь и понимать gratious arp, иначе "не поймут" переключения серверов и будут лить на старый MAC. Все, что встречались мне, понимают, но вот у DGS-3612g/27g, например, по дефолту learning отключен. Второй вариант - использовать vmac, но в текущей реализации в keepalived есть баг, из-за которого получается mac flapping на порту коммутатора.

2) Биллинг должен корректно обрабатывать поднятие еще одной сессии у пользователя (он-то, скорее всего, не знает, что первая сессия сдохла из-за смерти сервера).

3) UDP-based сервисы очень любят отправлять ответ с src ip из таблицы маршрутизации. Поэтому если используете, например, PowerDNS и вешаете его на виртуальный IP - нужно озаботиться о том, чтобы он висел именно на виртуальном IP (а не на 0.0.0.0). В примере выше у меня это делает скрипт по notify. Возможно, можно как-то навесить сразу на все виртуальные адреса через non-local bind, но я не заморачивался :).

 

Со стороны lISG не делается ничего вообще.

[Wingman]

В этой схеме подразумевается, что L3 свитч априори молотит меньше трафика, чем прожуёт один lisg.

У меня наоборот: например, трафик одной-двух 6500 нужно раскидать на 2-4 lISG. Как руки дойдут, буду мучать PBR ;)

[Abram]

В этой схеме подразумевается, что L3 свитч априори молотит меньше трафика, чем прожуёт один lisg.

У меня наоборот: например, трафик одной-двух 6500 нужно раскидать на 2-4 lISG. Как руки дойдут, буду мучать PBR ;)

Сколько ж это онлайн? Если не секрет. Можно в личку. Интересно же :).

Да, вам маршрут выставлять PBR-ом, остальное всё то же самое.

Я бы вообще в вашем случае делил трафик на, допустим, 10-12 частей и лил их на, скажем, адреса x.x.x.101-x.x.x.112. Далее вешать на тазик по 5-6 адресов и в случае падения размазывать их на равномерно на остальные.

Изменено 9 сентября, 2013 пользователем Abram

[archim]

Ни у кого не случалось время от времени такого?

$ ISG.pl show_count

Approved sessions count:-4294965328

Unapproved sessions count:4294965328

$

 

Может как-то лечится?

А почему вы считаете что ваши проблемы обязательно какие-то уникальные, не читаете readme и даже поиском не пробуете пользоваться?

Даже я, бесконечно далекий от данного проекта знаю что http://forum.nag.ru/forum/index.php?showtopic=53156&st=560&p=659458entry659458

 

Если б всё было так просто

archim@router:~$ cat /proc/sys/net/core/rmem_max

1048576

archim@router:~$

 

И дефолтный поиск как-то не помог

http://db.tt/3kmfJuj4