[komander]

Применение NAT-а для ШПД априори бред сумашедшего.

Нахватает адресов закажи у регулятора.

Нет у регулятора, может пора рекомендации этого самого регулятора начать слушать и действовать, а не изобретать свой NAT-Интернет.

-100

Изменено 11 декабря, 2009 пользователем komander

[cmhungry]

конфигурацию и настройки сервера в студию! =)

Сегодня NAT+шейп+аккаунтинг+нетфлов+фильтр на Supermicro сервере + сетевушке всего за 1200$ в сумме, упирается только в скорость сетевой карты 1G.

 

Спасибо, очень полезно.

 

Применение NAT-а для ШПД априори бред сумашедшего.

Нахватает адресов закажи у регулятора.

Нет у регулятора, может пора рекомендации этого самого регулятора начать слушать и действовать, а не изобретать свой NAT-Интернет.

-100

RIPE, например, как раз очень и очень радеет за использование НАТа на ШПД.

[Nic]

Iva, а чем генерируете нетфлов? Я тут столкнулся с проблемой, что fprobe-ulog жрет очень много процессора на потоках около 200мбит/с

 

[Iva]

Iva, а чем генерируете нетфлов?

Например так:

 

>grep ULOG /etc/sysconfig/iptables
[0:0] -A world_host -m set --set ulog-world-host dst -j ULOG --ulog-nlgroup 3 --ulog-cprange 48 --ulog-qthreshold 10
[0:0] -A host_world -m set --set ulog-host-world src -j ULOG --ulog-nlgroup 2 --ulog-cprange 48 --ulog-qthreshold 10

>egrep -v ^# /etc/ipcad.conf
capture-ports enable;

interface ulog group 2, group 3 netflow-disable;

netflow export version 5;
netflow timeout active 30;
netflow timeout inactive 15;

rsh enable at 127.0.0.1;
rsh root@127.0.0.1 admin;
rsh ttl = 1;
rsh timeout = 30;

buffers = 128k;

memory_limit = 32m;

[Гость анти НАТ]

Чуть выше писали komander:#25 и я с этим соглашусь.

Написанное в данной статье актуально только на сегодняшний день.

 

А как же развивать сервисы: SIP, видеоконференции, телемедицину и.т.д. с NAT? да никак.

Господа когда там намечен переход на адресацию IPv.6 ??? вот он и будет ликвидатором NATa.

[Гость Juriy]

Считаю, что немного некорректное сравнение:

По поводу Циски ясно - там фиксированная конфигурация.

По поводу РС во что упирается? :

1. В количество памяти?

2. В производительность шины?

3. В производительность проца?

4. В производительность одного ядра проца?

5. В ограничение ОС? (какой размер буфера? какие тайминги? какие дрова?)

 

На мой взгляд если будет упираться в железо, то вначале задержка будет увеличиваться.

 

Р.S. все таки конфигурацию севака надо

[Гость Фауст]

Анализ конечно интересный, но насколько он применим к продакшену вопрос. Решения по организации межсетевого экранирования рассмотрены у вас в статье очень поверхностно, фактически только ASA, которая, к слову сказать, отнюдь не является лидером рынка, как бы циске этого не хотелось.

 

Ещё хотелось бы понять, каким образом устроен был стенд (схемы - логика + физика, функциональная), какие протоколы канального уровня использовались для организации доступа в сеть для пользователей, на каком уровне сети осуществлялось шейпирование, снятие статистики, натирование.

 

В общем по моему сугубо личному мнению, статься по факту является пиаром цискиных решений, и полезной информации, для разработки каких либо решений не несёт.

[Гость Сергей Николаевич]

Пример из собственной практики, исходные данные, 180 тыс абонентов, два бордера cisco12404 PRP2,

3 агрегатора PPPoE cisco 10008 pre4 2sip601 в каждом, 3 NAT box, linux gentoo, 8 ядер в каждом плюс по 8 интерфейсов в каждом серваке.

В пиковую нагрузку количество PPPoE сессий примерно по 25тыс на один Cisco10008, при этом на нем осуществляется полисинг абонов, загрузка процессора примерно 40-50%, далее абоны прилетают на бордеры, где при помощи PBR, отправляются на NAT box-ы, интерфесы NAT, собраны в etherchanel, и с агрегырованы на cisco 6500. NetFlow собирается естественно с бордеров версия 9., Сразу хочу заметить 12404 отрабатывают на ура, средняя загрузка 10%. Максимальный объем интернет трафика при таком количестве абонентов 7.3Gb/s. На внутренние ресурсы и ресурсы пиринговые, полисинг не осуществляется, политика партии. Основная проблема при такой схеме это загрузка именно NAT box-ов, сейчас она достигает 60-70%, искали промышленное решение от наших мега брендов Cisco juniper, у первых вообще что то подобное будет только в следующем году, а вот у Juniper, решение есть, но опять таки кто его трогал руками пока найти не удалось чтобы хотя бы поинтересоваться что да как. Плюс решение от Juniper, стоит, на ПОРЯДОК больше, чем решение с NAT-linux, даже с учетом масштабирования, т.е. добавления серверов.

Если есть интерес к схеме реализации подводных камнях и прочее с радостью расскажу.

 

З,Ы, решение от Juniper заказали, так что чувствую скоро будет реальные экспирианс.

Основная проблема с точки зрения NAT это быстрая обработка пакетиков, прилетающих на NAT, объем данных пакетиков напрямую зависит от скорости абонента, и количества TCP сессий, одновременно открытых, (ТОРРЕНТ-ЗЛО), сейчас у на 70% абонентов сидит на скорости 2мб/c.

[Гость Артем]

А какими биллингами переваривается такой объем статистики? И на каких серверах?

А то вот сейчас в компании внедряется новый биллинг, взамен UTM, так он уже на тестовой VPN-платформе на 4000 пользователей показывает отложенную на час тарификацию. UTM в аналогичном режиме тормозил минут на 15...

[Гость Сергей Николаевич]

Биллинг естественно, заказанный, внедряли примерно год. Пока еще полностью не перешли на него, так сказать в завершающей стадии.)))) Сервера все тот же HP 8 ядер, 8гб мозгов, плюс есть корзины для хранения сырых flow. Подробно именно о серверах биллинга могу выяснить, за них отвечает отдельная группа, я как вы наверное догадались больше сетевик.

[Гость Гость_Сергей Николаевич]

Но если честно NetFlow это не для биллинга, и сы уже начинаем упираться в то что железяки каких бы брендов они не были не смогут обработать растущий поток flow, поэтому либо sampled flow, либо анлимы.

[cmhungry]

Пример из собственной практики, исходные данные, 180 тыс абонентов

Основная проблема при такой схеме это загрузка именно NAT box-ов, сейчас она достигает 60-70%, искали промышленное решение от наших мега брендов Cisco juniper, у первых вообще что то подобное будет только в следующем году, а вот у Juniper, решение есть, но опять таки кто его трогал руками пока найти не удалось чтобы хотя бы поинтересоваться что да как. Плюс решение от Juniper, стоит, на ПОРЯДОК больше, чем решение с NAT-linux, даже с учетом масштабирования, т.е. добавления серверов.

Если есть интерес к схеме реализации подводных камнях и прочее с радостью расскажу.

Juniper MX MS-DPC был на тестах. 120К GPL... плюс сама коробка хотя бы 113,5 GPL в минималке.

 

Но вообще 180К хомячков - зачот. Уважаю.

 

Анализ конечно интересный, но насколько он применим к продакшену вопрос. Решения по организации межсетевого экранирования рассмотрены у вас в статье очень поверхностно, фактически только ASA, которая, к слову сказать, отнюдь не является лидером рынка, как бы циске этого не хотелось.

Juniper ISG2000 крутили. Не подошел.

Huawei Secpath 1000-F крутили. Не подошел.

 

А какими биллингами переваривается такой объем статистики? И на каких серверах?

А то вот сейчас в компании внедряется новый биллинг, взамен UTM, так он уже на тестовой VPN-платформе на 4000 пользователей показывает отложенную на час тарификацию. UTM в аналогичном режиме тормозил минут на 15...

Про нетфлоу еще будет статья. Но вкратце - абоненту в биллинг полный нетфлоу не нужен. Агрегировать его надо как можно раньше, желательно на самой железке, с которой эта инфа берется. Как вариант - можно брать аккаунтинг с брасов по определенным классам.

Полный нетфлоу нужен только органам или для детального разбора "а что я скачал" - но хранить его в биллинге не надо.

[Гость vadik]

Кирилл, а нельзя ли у вас получить более подробную консультацию по подбору оборудования для выше описанных вами целей, для меньшей сети конечно чем у вас. Естественно не за даром ))) Если не сложно напишите на мыло baibade@yandex.ru

[Гость Фауст]

Crossbeam, Checkpoint, StoneGate. Есть куча продуктов и решений, на вкус и цвет.

Те же стонгейты например собираются в отказоустойчивый кластер с балансировкой нагрузки между нодами, до 16 штук. Причём, есть взять эерлайнс Fw - 5100, то пропускная способность одного устройства, составит ~ 10Gbit/s. Умножите это число на 16, и получите суммарную производительности кластера.

[cmhungry]

Crossbeam, Checkpoint, StoneGate. Есть куча продуктов и решений, на вкус и цвет.

Те же стонгейты например собираются в отказоустойчивый кластер с балансировкой нагрузки между нодами, до 16 штук. Причём, есть взять эерлайнс Fw - 5100, то пропускная способность одного устройства, составит ~ 10Gbit/s. Умножите это число на 16, и получите суммарную производительности кластера.

Это очень специфичное оборудование... Мне не удалось даже краснозадых вытащить на тест. MS-DPC - тоже с большим трудом, тут спасибо большое Нетвеллу, помогли, в том числе с настройкой.

Про те же DPI - нашел случайно в сети Ipoque, нашел сайт ipoque.ru. Написал, ответили через 3 дня. Пообещали, что будут "вкуснее чем циска", выдали в итоге GPL на 3 gbit/s только софта (без железа) стоимостью выше GPL SCE2020.

 

Есть определенный разрыв между "желаемым" и "имеющимся" оборудованием на рынке. Знакомый захотел купить новый брокейд МЛХ. Выкатили ценник - на два новых 76х кота в аналогичной набивке хватит.

[vitalyb]

cmhungry

ЕМНИП, Cacti по умолчанию не "нормализует" проценты на загрузке CPU (для 100% четырехядерника Cacti отрисует как 400%), поэтому, скорее всего, в конфигурации "только NAT" 700МБит у Вас загрузка CPU на самом деле 10-20%, как у Iva. Но другой вопрос в том, что на двух сетевых интерфейсах, не поддерживающих очереди, "потолок" - 200.

 

Не знаю кому как, но 100 дропов в секунду на сетевом интерфейсе - это как-то многовато. Ситуацию в некоторых случаях можно полечить включением flow-control, только нужно аккуратно.

 

чем генерируете нетфлов?

Еще ipt_netflow посмотрите.

 

[cmhungry]

cmhungry

ЕМНИП, Cacti по умолчанию не "нормализует" проценты на загрузке CPU (для 100% четырехядерника Cacti отрисует как 400%), поэтому, скорее всего, в конфигурации "только NAT" 700МБит у Вас загрузка CPU на самом деле 10-20%, как у Iva. Но другой вопрос в том, что на двух сетевых интерфейсах, не поддерживающих очереди, "потолок" - 200.

 

Не знаю кому как, но 100 дропов в секунду на сетевом интерфейсе - это как-то многовато. Ситуацию в некоторых случаях можно полечить включением flow-control, только нужно аккуратно.

 

чем генерируете нетфлов?

Еще ipt_netflow посмотрите.

Микротик на своем cpu-meter тоже показывает 40-50. То, что дело может быть в сетевых картах - да, допускаю. Конфигурацию сервера тут писали, рекомендуемую сетевую карту показали. В принципе, можно протестировать.

[Iva]

То, что дело может быть в сетевых картах - да, допускаю. Конфигурацию сервера тут писали, рекомендуемую сетевую карту показали. В принципе, можно протестировать.

Да, сетевая карта с поддержкой MSI-X (Intel 82575 или 82576) и многоядерный процессор с большим кешем (Intel Xeon 55x0) залог успеха. Например, вот так с помощью smp_affinity прерывания от четырех RX-очередей и четырех TX-очередей на каждом порту разносятся по восьми виртуальным ядрам процессора:

 

>cat /proc/interrupts | grep x-
 33:    1685279          0          3          0          0          0          0          0   PCI-MSI-edge      eth0-tx-0
 34:          0    1785855         30          0          0          0          0          0   PCI-MSI-edge      eth0-tx-1
 35:          0          0    1802979          5          0          0          0          0   PCI-MSI-edge      eth0-tx-2
 36:          0          0          0 2309869956          0          0          0          0   PCI-MSI-edge      eth0-tx-3
 37: 3881218762          0          0          0        447          0          0          0   PCI-MSI-edge      eth0-rx-0
 38:          0 3849047959          0          0        500          0          0          0   PCI-MSI-edge      eth0-rx-1
 39:          0          0 3833090350          0          0        457          0          0   PCI-MSI-edge      eth0-rx-2
 40:          0          0          0 3888983966          0        431          0          0   PCI-MSI-edge      eth0-rx-3
 45:          0          0          0          0 1030197823          0       1529          0   PCI-MSI-edge      eth1-tx-0
 46:          0          0          0          0          0 1036755212       1472          0   PCI-MSI-edge      eth1-tx-1
 47:          0          0          0          0          0          0 1005676377       1534   PCI-MSI-edge      eth1-tx-2
 48:          0          0          0          0          0          0          0 1049775722   PCI-MSI-edge      eth1-tx-3
 49:       5010          0          0          0 1178060627          0          0          0   PCI-MSI-edge      eth1-rx-0
 50:       5115          0          0          0          0 1198557612          0          0   PCI-MSI-edge      eth1-rx-1
 51:          0       4793          0          0          0          0 1222757403          0   PCI-MSI-edge      eth1-rx-2
 52:          0       4791          0          0          0          0          0 1190893532   PCI-MSI-edge      eth1-rx-3

Думаю, если брать 4х-процессорный сервер с 2х-портовой 10G сетевой картой на чипе Intel 82598 (CX4, XFP), то и десятку можно загрузить всеми упоминаемыми задачами.

[Гость Гога]

Статья зачетная

[bitbucket]

А вот к графикам загрузки интерфейсов интересно бы график дропов на этих интерфейсах еще. Плюс интересен размер таблицы маршрутизации и кол-во правил в фаерволе.

 

Да и пакеты какие-то странные у автора - average по 970байт... Я уже как 3 года вижу числа в районе 600байт.

[Iva]

Да и пакеты какие-то странные у автора - average по 970байт... Я уже как 3 года вижу числа в районе 600байт.

Хм, скорее это у вас аномально низкий средний размер пакета. Например, у нас меньше 1000 байт практически не опускается.

 

 

[DemYaN]

У нас 720-820байт

[bitbucket]

Хм, скорее это у вас аномально низкий средний размер пакета. Например, у нас меньше 1000 байт практически не опускается.

Средний считается по всем пакетам, прошедшим через рутер. Про 1000 на входящем только трафике еще поверю, и то он меньше становится...

 

Про дропы, фаервол и маршруты лучше расскажите...

 

[Iva]

Про дропы, фаервол и маршруты лучше расскажите...

Извиняюсь, думал вопрос был адресован автору статьи.

 

Дропов нет смысла допускать. Достаточно проследить за параметрами статистики интерфейса и в случае ошибок (rx_no_buffer_count, rx_missed_errors) увеличить Ring parameters:

 

>ethtool -S eth0
NIC statistics:
    rx_packets: 62073338124
    tx_packets: 51327408018
    rx_bytes: 64654913689424
    tx_bytes: 31039760607836
    rx_broadcast: 3587538
    tx_broadcast: 3767
    rx_multicast: 3
    tx_multicast: 4
    rx_errors: 36
    tx_errors: 0
    tx_dropped: 0
    multicast: 3
    collisions: 0
    rx_length_errors: 0
    rx_over_errors: 0
    rx_crc_errors: 22
    rx_frame_errors: 0
    rx_no_buffer_count: 187
    rx_missed_errors: 81
    tx_aborted_errors: 0
    tx_carrier_errors: 0
    tx_fifo_errors: 0
    tx_heartbeat_errors: 0
    tx_window_errors: 0
    tx_abort_late_coll: 0
    tx_deferred_ok: 0
    tx_single_coll_ok: 0
    tx_multi_coll_ok: 0
    tx_timeout_count: 0
    tx_restart_queue: 0
    rx_long_length_errors: 0
    rx_short_length_errors: 0
    rx_align_errors: 0
    tx_tcp_seg_good: 3519052
    tx_tcp_seg_failed: 0
    rx_flow_control_xon: 0
    rx_flow_control_xoff: 0
    tx_flow_control_xon: 0
    tx_flow_control_xoff: 0
    rx_long_byte_count: 64654913689424
    rx_csum_offload_good: 62019195396
    rx_csum_offload_errors: 876202
    tx_dma_out_of_sync: 0
    alloc_rx_buff_failed: 0
    tx_smbus: 0
    rx_smbus: 0
    dropped_smbus: 0
    tx_queue_0_packets: 51311490384
    tx_queue_0_bytes: 30693986683670
    tx_queue_1_packets: 1931574
    tx_queue_1_bytes: 630914901
    tx_queue_2_packets: 1722205
    tx_queue_2_bytes: 556098712
    tx_queue_3_packets: 12263850
    tx_queue_3_bytes: 15387016988
    rx_queue_0_packets: 15417127940
    rx_queue_0_bytes: 15954925692220
    rx_queue_1_packets: 15552881003
    rx_queue_1_bytes: 16172568075893
    rx_queue_2_packets: 15456729503
    rx_queue_2_bytes: 15892001474168
    rx_queue_3_packets: 15646599679
    rx_queue_3_bytes: 16387162976168

>ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             1024
RX Mini:        0
RX Jumbo:       0
TX:             256

Из маршрутов, только дефолт в "реальный" интерфейс и 10.0.0.0/8 в "локальный". Дополнительно увеличены кешы:

 

>grep "ipv4.route" /etc/sysctl.conf
net.ipv4.route.max_size = 4194304
net.ipv4.route.secret_interval = 300

IPTables максимально оптимизирован для уменьшения времени прохождения пакета по правилам. Для массовых однотипных проверок используется IPSet, для учёта трафика используется ipt_ACCOUNT, для netflow ipt_ULOG+IPCad.

 

>ipset -L | grep "\." | wc -l
11142

>cat /etc/sysconfig/iptables
*mangle
:PREROUTING ACCEPT [0:0]
:FORWARD ACCEPT [0:0]

#
# Shaper marking
#
#
# host -> ua
#
[0:0] -A PREROUTING     -i eth1 -m set --set ua dst -m comment --comment "UA Out"       -j MARK --set-mark 201
[0:0] -A PREROUTING     -m mark --mark 201                                              -j IMQ --todev 0
[0:0] -A PREROUTING     -m mark --mark 201                                              -j RETURN
#
# host -> world
#
[0:0] -A PREROUTING     -i eth1 -m comment --comment "World Out"                        -j MARK --set-mark 202
[0:0] -A PREROUTING     -m mark --mark 202                                              -j IMQ --todev 0

#
# Billing marking
#
#
# ua -> host
#
[0:0] -A FORWARD        -i eth0 -m set --set ua src -m comment --comment "UA In"        -j MARK --set-mark 11
[0:0] -A FORWARD        -m mark --mark 11                                               -j RETURN
#
# host -> ua
#
[0:0] -A FORWARD        -m mark --mark 201                                              -j MARK --set-mark 12
[0:0] -A FORWARD        -m mark --mark 12                                               -j RETURN
#
# world -> host
#
[0:0] -A FORWARD        -i eth0 -m comment --comment "World In"                         -j MARK --set-mark 1
[0:0] -A FORWARD        -m mark --mark 1                                                -j RETURN
#
# host -> world
#
[0:0] -A FORWARD        -m mark --mark 202                                              -j MARK --set-mark 2

COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

#
# Billing redir
#
[0:0] -N redir
[0:0] -A redir          -m set --set bil_10_4 src                                       -j RETURN
[0:0] -A redir          -m set --set bil_10_5 src                                       -j RETURN
[0:0] -A redir          -m set --set bil_10_1 src                                       -j RETURN
[0:0] -A redir                                                                          -j REDIRECT

#
# Billing redirecting
#
[0:0] -A PREROUTING     -i eth1 -p tcp --dport 80                                                       -j redir
[0:0] -A PREROUTING     -m mark --mark 201 -m set --set block-1-host-ua src -p tcp --dport 80           -j REDIRECT
[0:0] -A PREROUTING     -m mark --mark 202 -m set --set block-1-host-world src -p tcp --dport 80        -j REDIRECT

#
# Billing nating
#
[0:0] -A POSTROUTING    -o eth0 -s 10.0.0.0/8 -p icmp                                   -j SNAT --to-source x.x.x.x
[0:0] -A POSTROUTING    -o eth0 -s 10.0.0.0/8                                           -j SNAT --to-source y.y.y.1-y.y.y.254 --persistent

COMMIT

*filter
:FORWARD ACCEPT [0:0]

#
# Billing access
#
[0:0] -N access
[0:0] -A access         -m set --set bil_10_4 src                                       -j RETURN
[0:0] -A access         -m set --set bil_10_5 src                                       -j RETURN
[0:0] -A access         -m set --set bil_10_1 src                                       -j RETURN
[0:0] -A access                                                                         -j REJECT --reject-with icmp-admin-prohibited

#
# Billing accounting
#
#
# ua -> host
#
[0:0] -N ua_host
[0:0] -A ua_host        -m set --set block-1-ua-host dst                                -j DROP
[0:0] -A ua_host                                                                        -j ACCOUNT --addr 10.0.0.0/8 --tname ua-host
[0:0] -A ua_host                                                                        -j ACCEPT
[0:0] -A FORWARD        -m mark --mark 11                                               -j ua_host
#
# host -> ua
#
[0:0] -N host_ua
[0:0] -A host_ua                                                                        -j access
[0:0] -A host_ua        -m set --set block-1-host-ua src                                -j REJECT --reject-with icmp-admin-prohibited
[0:0] -A host_ua        -p tcp --syn --dport 1025: -m connlimit --connlimit-above 255   -j REJECT --reject-with tcp-reset
[0:0] -A host_ua                                                                        -j ACCOUNT --addr 10.0.0.0/8 --tname host-ua
[0:0] -A host_ua                                                                        -j ACCEPT
[0:0] -A FORWARD        -m mark --mark 12                                               -j host_ua
#
# world -> host
#
[0:0] -N world_host
[0:0] -A world_host     -m set --set block-1-world-host dst                             -j DROP
[0:0] -A world_host                                                                     -j ACCOUNT --addr 10.0.0.0/8 --tname world-host
[0:0] -A world_host     -m set --set ulog-world-host dst                                -j ULOG --ulog-nlgroup 3 --ulog-cprange 48 --ulog-qthreshold 10
[0:0] -A world_host                                                                     -j ACCEPT
[0:0] -A FORWARD        -m mark --mark 1                                                -j world_host
#
# host -> world
#
[0:0] -N host_world
[0:0] -A host_world                                                                     -j access
[0:0] -A host_world     -m set --set block-1-host-world src                             -j REJECT --reject-with icmp-admin-prohibited
[0:0] -A host_world     -p tcp --syn --dport 1025: -m connlimit --connlimit-above 255   -j REJECT --reject-with tcp-reset
[0:0] -A host_world                                                                     -j ACCOUNT --addr 10.0.0.0/8 --tname host-world
[0:0] -A host_world     -m set --set ulog-host-world src                                -j ULOG --ulog-nlgroup 2 --ulog-cprange 48 --ulog-qthreshold 10
[0:0] -A FORWARD        -m mark --mark 2                                                -j host_world

COMMIT

[Dyr]

А какими биллингами переваривается такой объем статистики? И на каких серверах?

А то вот сейчас в компании внедряется новый биллинг, взамен UTM, так он уже на тестовой VPN-платформе на 4000 пользователей показывает отложенную на час тарификацию. UTM в аналогичном режиме тормозил минут на 15...

UTM жуткое г..., единственный вариант переписывать perl'овый UTM4 под себя (что в общем-то, сродни написанию своего биллинга). На 20k абонентах отрабатывал меньше чем за 3 минуты.

 

Статья интересная, но комментарии, пожалуй, ещё интереснее.

И есть большущее подозрение, что за 110k$ стоимости SCE можно нанять всю FreeBSD'шную команду разработчиков доделать нормальный шейпинг ;)

Изменено 15 декабря, 2009 пользователем Dyr