Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

В продолжении статьи PPPoE сервер на встроенном в FreeBSD демоне pppoed рассмотрим ситуацию с LCP и LQR.

Немного теории:

LCP — сокращение от Link Control Protocol — протокол управления соединением.

LCP является частью протокола Point-to-Point.
При установлении соединения PPP передающее и принимающее устройство обмениваются пакетами LCP для уточнения специфической информации, которая потребуется при передаче данных.
Согласование параметров соединения проводится в форме переговоров.
LCP протокол осуществляет:

• проверку идентификации соединяемых устройств и, вследствие этого разрешает или отклоняет установку соединения
• определение приемлемого размера кадров для передачи MTU и приёма — MRU
• ограничение по ширине канала
• шифрование аутентификации соединения
• сжатие данных
• обнаружение петель маршрутизации
• проверку синтаксиса и поиск ошибок в конфигурации
• разрыв соединения, если какое-либо значение превышает заданный параметр

Устройства не могут передавать данные друг другу по сети прежде чем LCP пакеты не определят доступность устанавливаемого соединения.

LQR — Link Quality Report так же является частью протокола Point-to-Point и нужен для оценки состояния и качества связи PPP.

Если вы используете демон pppoed под FreeBSD, то в логах /var/log/ppp.log вам могут встречаться такие строки:

Apr 5 12:16:41 vpn-01 ppp[3951]: tun1: Warning: lqr_RecvEcho: Got sig 0x22c61241, not 0x594e4f54 !

 .... 

Apr 5 12:17:01 vpn-01 ppp[3951]: tun1: Phase: deflink: ** Too many LCP ECHO packets lost **

Первая строка говорит о том что lqr.magic в полученном пакете не верен.

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

Затем юзер реконнектнется и все повторится с начала…. и так до бесконечности.

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

 

Что же с этим делать ?

Вариантов несколько:

1. отключить LQR совсем
2. позвонить пользователю и сказать что его роутер не годен для работы в вашей сети
3. ковырять и править исходники ppp

Отключать LQR совсем не вариант, т.к. тогда зависший туннель точно никогда не отвалится, а это не есть гуд. Предлагать пользователю сменить роутер равнозначно предложить ему сменить провайдера.

Получается что остается один вариант —  ковырять исходники ppp и нужно сделать так, чтобы  не было реагирования на состав меджика.

Для FreeBSD 8.2 это будет происходить так:

Идем в сорцы /usr/src/usr.sbin/ppp/ и находим в этой папке файл lqr.c.
Правим его, diff можно увидеть тут. А именно просто комментарим тот IF, который проверяет меджик, выводит нам сообщение и не увеличивает каунтер полученных LCP пакетов.

Затем делаем make и после чего в /usr/obj/usr/src/usr.sbin/ppp появится вновь собранный файл ppp.
Теперь наша задача плавно перевести пользователей на вновь собранный демон, т.к. тупо заменить им текущий может и не получится в виду того, что на каждый PPPoE туннель создается отдельный процесс:

97011 ?? Ss 0:03,33 /usr/sbin/ppp -direct pppoe

и фря может отказать вам в замене файла.

То у нас три варианта:

• перезапустить сервер
• убить все процессы ppp
• вызывать новый ppp только при новых подключениях

Действуем по последнему варианту, т.к. это позволит плавно перевести пользователй, ведь рано или поздно все переподключатся и мы сможем заменить старый /usr/sbin/ppp.

Берем новый ppp и копируем в /usr/sbin/ppp.new.

Не забудьте выставить владельца и права на новый файл так же как это было у старого:

-r-sr-x---  1 root  network  412608 26 Apr 13:14 /usr/sbin/ppp

# chmod 4550 /usr/sbin/ppp.new
# chgrp network /usr/sbin/ppp.new

Затем убиваем все процессы pppoed и стартуем их снова, но чуть изменив строку запуска:

# /usr/libexec/pppoed -a vpn-01 -p "*" -e "/usr/sbin/ppp.new -direct pppoe" em1

Что при подключении пользователя запустит уже не /usr/sbin/ppp, а /usr/sbin/ppp.new.

После того как все готово можно посмотреть как подключаются пользователи и убедиться в том, что Warning: lqr_RecvEcho более не появляется, а пользователи, которые из-за этого отваливались, более не отваливаются.

Как только процессов ppp не останется, мы сможем заменить старый новым и вернуть строку запуска pppoed к прежней.

Ещё одно полезное дополнение для pppoed это дополнить информацию в его логах.

По дефотлу подключение клиента в /var/log/pppoed.log выглядит так:

Apr 5 09:34:19 vpn-01 pppoed[58768]: Listening as provider * 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Offering to .:exec-58904 as access concentrator vpn-01 

Apr 5 09:34:19 vpn-01 pppoed[58904]: adding to .:exec-58904 as offered service vpn-01 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SESSIONID (hook "^C") 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SUCCESS (hook "exec-58904") 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Executing: exec /usr/sbin/ppp -direct pppoe

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

Apr 5 09:00:52 vpn-01 pppoed[73025]: Offering to .:exec-73025 as access concentrator vpn-01 at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: adding to .:exec-73025 as offered service vpn-01 at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SESSIONID (hook "ü ÿÿÿ^?") [40:4a:03:a8:e3:a0] at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SUCCESS (hook "exec-73025") [40:4a:03:a8:e3:a0] at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Executing: exec /usr/sbin/ppp -direct pppoe for .:exec-73025: [40:4a:03:a8:e3:a0] at [vlan65]

Так становится более понятнее о том к какому клиенту относятся строчки в логе и за каким интерфейсом сервера расположен клиент.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Авторы: Николаев Дмитрий (virus (at) subnets.ru) и Панфилов Алексей (lehis (at) subnets.ru)

Задача

Обеспечить функционирование второго канала (backup) в Интернет для офиса при использовании канала от Yota.

Для обеспечения NAT`а возьмем ng_nat.

Железо

• USB-модем Samsung SWC-U200
• Сервер FreeBSD 8.2-STABLE

Реализация

Для USB-модемов Samsung SWC-U200 и Samsung SWC-E100 в портах появились userland-драйвер, находящийся в /usr/ports/net/lvwimax.

Инсталлируем их обычным способом:

# cd /usr/ports/net/lvwimax/
# make install clean

Перезапускаем демон отслеживания изменения состояния устройств:

# /etc/rc.d/devd restart

Для автостарта драйвера при загрузке системы добавим в /etc/rc.conf:

lvwimax_mac_address=»60:D0:A9:XX:YY:ZZ»

lvwimax_enable=»YES»

где 60:D0:A9:XX:YY:ZZ — MAC адрес USB-модема (его можно посмотреть либо на коробочке либо в личном кабинете).

 

Для логгирования отладочной инфы в отдельные файлы в начало /etc/syslog.conf следует добавить:

local6.err              /var/log/lvwimax_err.log

local6.info             /var/log/lvwimax_info.log

local6.debug            /var/log/lvwimax_debug.log

Создать файлы лога:

# touch /var/log/lvwimax_err.log

# touch /var/log/lvwimax_info.log

# touch /var/log/lvwimax_debug.log

и перезапустить syslogd:

# /etc/rc.d/syslogd restart

Загружаем модули ядра для работы NAT:

# kldload ng_ipfw

# kldload ng_nat

Для загрузки модулей при старте системы добавим в /boot/loader.conf:

ng_ipfw_load=»YES»

ng_nat_load=»YES»

 

dhclient вызывает скрипт конфигурации сетевых параметров — dhclient-script, который после конфигурирования сетевого интерфейса смотрит, есть ли файл с именем /etc/dhclient-exit-hooks. Если файл находится, то он запускается на исполнение.

Этим мы и воспользуемся для изменения конфигурации NAT после получения IP-адреса по DHCP от провайдера.

Создадим файл /etc/dhclient-exit-hooks с содержанием:

#!/bin/sh

if [ "$reason" = "REBOOT" -o "$reason" = "BOUND" -o "$reason" = "RENEW" -o "$reason" = "REBIND" ]; then

ipfw -q delete 410

ipfw -q delete 420

ipfw -q delete 430

if ngctl show Yota_nat: >/dev/null 2>&1; then

/usr/sbin/ngctl shutdown Yota_nat:

echo "Destroy old nat config was complete" >>/var/log/dhc.log

fi

/usr/sbin/ngctl mkpeer ipfw: nat 70 out

/usr/sbin/ngctl name ipfw:70 Yota_nat

/usr/sbin/ngctl connect ipfw: Yota_nat: 80 in

/usr/sbin/ngctl msg Yota_nat: setaliasaddr $new_ip_address

echo "Create nat config was complete" >>/var/log/dhc.log

 ipfw -q add 410 netgraph 80 ip from any to $new_ip_address via tap0 in

ipfw -q add 420 netgraph 70 ip from table"(99)" to any via vlan10 in

ipfw -q add 430 fwd $new_routers ip from $new_ip_address to any

echo "Apply ipfw rules for nat was complete" >>/var/log/dhc.log

 fi

Сделаем скрипт исполняемым:

# chmod a+x /etc/dhclient-exit-hooks

В нем вся «магия» по управлению конфигурацией NAT при изменении адреса после работы dhclient’a:

удаление старых правил ipfw, удаление старой конфигурации NAT, создание новой конфигурации NAT, применение новых правил ipfw.

При этом маршрут по умолчанию не изменяется.

 

Вставляем USB-модем в сервер и в путь:

# /usr/local/etc/rc.d/lvwimax start

Смотрим в ifconfig для проверки наличия интерфейса и полученного по DHCP IP-адреса:

tap0: flags=8843 metric 0 mtu 1386
        options=80000
        ether 60:d0:a9:f9:4a:74
        inet6 fe80::62d0:a9ff:fef9:4a74%tap0 prefixlen 64 scopeid 0x12
        inet 10.184.244.147 netmask 0xfffffc00 broadcast 10.184.247.255
        nd6 options=3
        Opened by PID 63322

Осталось в table(99)  поместить хосты или подсети для доступа в интернет через Yota.

Ссылки

• man 8 dhclient-script

P.S. Естественно, что данный способ будет работать с любым провайдером, для подключения к которому используется dhclient.

P.S.S. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru

 

Задача

Необходимо создать внутри одного физического роутера отдельную роутинг таблицу для одного клиента и двух его апстримов.

Иными словами нужно что бы эти три пира «жили» в своей таблице маршрутизации и не имели отношения к основной таблице маршрутизации.
Каждая таблица будет «жить» по своим законам и трафик будет ходить по своим маршрутам.

Имеем

• Juniper M10i
• JUNOS 10.1R1.8

Решение

Решить эту задачу нам поможет  routing-instances.

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

Читаем доку: Configuring Routing Instances

Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:

• forwarding—Provide support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See Configuring Filter-Based Forwarding.
• l2vpn—Provide support for Layer 2 VPNs. For more detailed information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
• layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. For more detailed information about configuring RSTP and MSTP, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide
• no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance.
• virtual-router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.
• virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detailed information about configuring a virtual switch, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide and the JUNOS MX Series Ethernet Services Routers Solutions Guide.
• vpls—Virtual private local-area network (LAN) service. Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. For more information about configuring VPLS, see the JUNOS VPNs Configuration Guide.
• vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where interface routes for each instance go into the corresponding forwarding table only. For more information about configuring VPNs, see the JUNOS VPNs Configuration Guide.

To configure a routing instance type, include the instance-type statement:

routing-instances {
     routing-instance-name {
           interface interface-name;
           instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
     }
}

Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).

В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.

Приступим

Исходные данные для нашего VRF:
VRF апстрим #1:

• подключен к физическому интерфейсу: ge-0/0/1.0
• ASN: 100
• IP-адрес: 1.1.1.1/30

VRF апстрим #2:

• подключен к физическому интерфейсу: ge-0/0/2.0
• ASN: 200
• IP-адрес: 2.2.2.1/30

VRF клиент #1:

• подключен к физическому интерфейсу: ge-0/1/0.0
• ASN: 300
• IP-адрес: 3.3.3.2/30

Назовем наш VRF именем test, а наш номер AS будет 400.

Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.

Заходим в режим конфигурирования:

root@juniper> configure

Затем перейдем в уровень routing-instances:

root@juniper# edit routing-instances

После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.

[edit routing-instances]
root@juniper# set test description «test routing table»

Зададим тип  routing-instance:

[edit routing-instances]
root@juniper# set test instance-type virtual-router

Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):

[edit routing-instances]
root@juniper# set test  interface ge-0/0/1.0
root@juniper# set test  interface ge-0/0/2.0
root@juniper# set test  interface ge-0/1/0.0

Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper# show routing-instances test

test {
    description "test routing table";
    instance-type virtual-router;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    interface ge-0/1/0.0;
    routing-options {
        router-id 1.1.1.2;
        autonomous-system 400;
    }

    protocols {
        bgp {
            path-selection always-compare-med;
            traceoptions {
                file bgp_vrf.log size 1m files 10;
            }
            log-updown;
            remove-private;
            local-as 400;
            group upstreams {
                type external;
                no-advertise-peer-as;
                neighbor 1.1.1.1 {
                    description VRF_Upstream_1;
                    import vrf-upstream-1-in;
                    export vrf-customer;
                    remove-private;
                    peer-as 100;
                }
                neighbor 2.2.2.1 {
                    description VRF_Upstream_2;
                    import vrf-upstream-2-in;
                    export vrf-customer;
                    peer-as 200;
                }
            }
            group customers {
                neighbor 3.3.3.2 {
                    description VRF_client_1;
                    import vrf-client-in;
                    export vrf-client-out;
                    peer-as 300;
                }
            }
        }
    }
}

Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.

Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).

Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.

Что мы должны увидеть после коммита данного конфига ?

По команде:

[edit]
root@juniper# run show bgp summary

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

Так же можно посмотреть что там с маршрутами в нашей routing-instance test:

[edit]
root@juniper# run show route table test.inet.0

Несколько заметок, например запустив пинг до нашего VRF клиента командой:

[edit]
root@juniper# run ping 3.3.3.2

не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.

Меняем команду на:

[edit]
root@juniper# run ping 3.3.3.2 routing-instance test
и вот он наш пинг:

PING 3.3.3.2 (3.3.3.2): 56 data bytes
64 bytes from 3.3.3.2: icmp_seq=0 ttl=255 time=0.660 ms
64 bytes from 3.3.3.2: icmp_seq=1 ttl=255 time=0.647 ms
^C
--- 3.3.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.647/0.653/0.660/0.007 ms

т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Думаю многим из вас знаком сайт http://www.robtex.com на котором много полезных вещей и одна из них это графическое отображение связей заданной AS.

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

Но есть вещи которых нет в графическом отображении  www.robtex.com. Например он не показывает даунстримов (клиентов) для заданной AS. Соответственно нет инфы, которая нужна админу транзитного оператора, который настраивает фильтры под клиентов. Инфа бы помогла увидеть «кольца» в маршрутизации его клиентов через другие связанные с ним AS.

Так же что-то непонятное творится с кешированием. Много раз замечал на AS`ках, которых обслуживаю, что инфа на www.robtex.com не соответствует текущей ситуации иногда даже через месяц после изменений. Т.е. ты что-то поменял, но измений не видно… и долго не видно.

На просторах «тырнета» была обнаружена либа «JavaScript Graph Library» -> Dracula Graph Library, которая отображает связности между объектами.

Dracula Graph Library работает на векторной библиотеке Raphaël, разработанной  Дмитрием  Барановским.

То что нам и надо. Большое спасибо разработчикам данных либ, очень сильно помогли и сэкономили кучу времени.

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

Итак, готовы вам представить первую версию собственного скрипта отображающий инфу по AS в графическом виде —>  «Построение графа связанности AS по ее номеру«.

Где можно указать номер AS, а так же:

• тип выводимой информации: апстримы/даунстримы
• выбрать глубину рекурсии

Вся информация берется из БД RIPE, которая доступна в выводе информации по номеру AS: http://www.db.ripe.net/whois?ASXXXXX (где XXXXX номер AS).

Пример вывода скрипта по нашей AS:

• Красные стрелочки -> Апстримы
• Зеленые стрелочки -> Даунстримы

Как вы понимаете автономка автономке рознь, т.е. кол-во апстримов и даунстримов у крупного оператора может быть большим, поэтому во избежание зависания вашего браузера выставлен лимит по кол-ву отображаемых на экране объектов, в 200 шт.

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

Посему кеш у нашей тулзы тоже есть, но он не такой «жестокий» и составляет не более 3-х суток.

Не всегда расположение объектов на странице вывода является оптимальным, для этого в конце страницы есть кнопка «перерисовать», либо вы сами можете  таскать любой объект (круг с номером AS) на экране и расставить их так, как нравится вам.

Информация заносимая админами в описание их AS в БД RIPE может различаться, т.к. способов написания import/export несколько. Мы постарались учесть самые распространенные из них, но мы предполагаем, что вы, уважаемые посетители, можете найти AS, картинка по которой может отображаться не совсем правильно. Если это так, то просим Вас сообщить нам о такой через форму «обратной связи» у нас на сайте.

И опережая вопросы: ДА, мы думали над тем, что бы брать информацию не из БД RIPE, а непосредственно из таблицы маршрутизации (full-view) BGP роутеров. Возможно, мы сделаем это в следующих версиях скрипта когда руки дойдут 🙂

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

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

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Как всегда начнем статью со слов благодарности тем, кто на нее откликнется, оставит комментарии и свои взгляды на решение проблемы. ))

Проблема или задача: мониторинг трафика провайдера на наличие ddos атак как со стороны своих абонентов и так и на них. Статья носит теоретический характер, практическая реализация зависит от каждого конкретного провайдера.

Немного теории здесь и здесь.

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

Учет трафика в сети провайдера в основном работает по следующей схеме — данные с оборудования о трафике абонента попадают на коллектор (в нашем случае используется netflow), где эти данные и обрабатываются.  Наша задача как раз и состоит в анализе этого трафика. Предлагаются следующие характеристики для анализа трафика:

— ip адрес;

— протокол;

— количество пакетов в потоке;

— количество байт в потоке.

Дальше просто анализируем количество потоков для одного ip адреса. Порог срабатывания в каждой сети и для каждого абонента может быть разный, опытным путем установили следующие значения: если из 1000000 потоков содержится более 10000 одинаковых записей, то скорее всего у клиента сетевая проблема (вероятно компьютер абонента заражен вирусом и участвует в атаке). Далее действия могут быть разными, пишем, звоним абоненту или сразу блокируем, все зависит от правил во взаимоотношении с клиентами. При количестве одинаковых потоков более 100000 проблема на сети провайдера будет видна невооруженным взглядом (конечно это будет зависеть от производительности оборудования).

Статья основана на собственном опыте, если у кого-то есть свои «выкладки», то будет интересно на них посмотреть.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор:  zaikini