В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритетзацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:
- Более подробная настройка Shorewall
- Страшный и не понятный QoS
- Балансировка нагрузки и резервирование
А в предыдущей части были рассмотрены:
- Простейшая настройка Shorewall
- Ужасно сложная настройка dnsmasq
- Не менее сложная настройка OpenVPN
- И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF
Все описанное ниже справедливо для CentOS 7.1 (и выше, 6 серия тоже подойдет, но с небольшими особенностями)
В прошлый раз мы настроили довольно доверчивый и примитивный режим работы, сейчас мы включим немного здравой паранойи.
Это сделать не сложно, давайте внесем правки в файл:
policy
#
# Shorewall -- /etc/shorewall/policy
#
# For information about entries in this file, type "man shorewall-policy"
#
# The manpage is also online at
# http://ift.tt/1JAPAke
#
###############################################################################
#SOURCE DEST POLICY LOG LIMIT: CONNLIMIT:
# LEVEL BURST MASK
$FW all REJECT
grn all REJECT
tun all REJECT
red all DROP
Новая конфигурация стала проще, но радоваться рано, файл rules значительно распухнет:
/etc/shorewall/rules
#
# Shorewall -- /etc/shorewall/rules
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://ift.tt/1mMAg9J
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
INCLUDE rules.fw
INCLUDE rules.grn
INCLUDE rules.red
INCLUDE rules.red-dnat
INCLUDE rules.tun
И воспользуемся директивой INCLUDE для разнесения правил по нескольким файлам:
rules.fw
#
# Shorewall -- /etc/shorewall/rules.fw
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://ift.tt/1mMAg9J
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
DNS(ACCEPT) $FW red
Web(ACCEPT) $FW red
FTP(ACCEPT) $FW red
OpenVPN(ACCEPT) $FW red
Ping(ACCEPT) $FW all
OSPF(ACCEPT) $FW tun
SSH(ACCEPT) $FW all
rules.grn
#
# Shorewall -- /etc/shorewall/rules.grn
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://ift.tt/1mMAg9J
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
DNS(ACCEPT) grn $FW
Web(ACCEPT) grn red
FTP(ACCEPT) grn red
Ping(ACCEPT) grn all
SSH(ACCEPT) grn all - - - - s:3/min
rules.red
#
# Shorewall -- /etc/shorewall/rules.red
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://ift.tt/1mMAg9J
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
OpenVPN(ACCEPT) red $FW
SSH(ACCEPT) red $FW - - - - s:3/min
rules.tun
#
# Shorewall -- /etc/shorewall/rules.tun
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://ift.tt/1mMAg9J
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
Ping(ACCEPT) tun $FW
OSPF(ACCEPT) tun $FW
SSH(ACCEPT) tun $FW - - - - s:3/min
SSH(ACCEPT) tun grn - - - - s:3/min
Теперь весь трафик под нашим контролем, пускаем только те протоколы, что хотим. Обратите внимание на правила для SSH, мы ограничили частоту соединений до 3-х в минуту, с каждого ip источника. Но надо быть очень осторожным с этим параметром, неверно указав ключ s: или d:, можно сделать ваш сервис легко поддающимся DDoS атаке. А для Web трафика (да и вообще любого), надо учитывать, что много потенциальных клиентов может сидеть за NAT, и тогда один IP, источник соединений, может генерировать значительное число подключений.
Если нам нужно пробросить порты к внутренним серверам, сделать это не сложно:
rules.red-dnat
#
# Shorewall -- /etc/shorewall/rules.red-dnat
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://ift.tt/1mMAg9J
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
Web(DNAT) red grn:172.16.0.2
#Вариант, если у нас несколько внешних адресов, а мы хотим DNAT только с одного из них:
#Web(DNAT) red grn:172.16.0.2 - - - 192.168.10.37
#Варианты, все руками:
#DNAT red grn:172.16.0.2 tcp 80,443
#DNAT red grn:172.16.0.2 tcp 80,443 - 192.168.10.37
#Вариант с нестандартными портами:
#DNAT red grn:172.16.0.2:80 tcp 8080
Скажу сразу, и балансировка и резервирование, только лишь настраиваются с помощью Shorewall, сам он не предоставляет никакого функционала по обнаружению пропажи канала или равномерному распределения реальной нагрузки.
Вся настройка сводится к редактированию одного файла:
providers
#
# Shorewall -- /etc/shorewall/providers
#
# For information about entries in this file, type "man shorewall-providers"
#
# For additional information, see http://ift.tt/1JAPB7G
#
############################################################################################
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
pr1 1 0x10000 - $IF_RED1 $GW_RED1 fallback=1
pr2 2 0x20000 - $IF_RED2 $GW_RED2 fallback=4
Если кто помнит, в прошлой статье была секция из «Shorewall.conf». Она нужна как раз для настройки маркировки пакетов и работе с провайдерами. Там мы задали, какие биты из метки пакета, задают идентификатор провайдера, какие просто метки (я такие пока нигде не использую, но Shorewall сам их задействует, для своих нужд), а какие для отслеживания соединений.
Тут мы описали двух провайдеров, задали как маркировать пакеты для них, на каком интерфейсе каждый сидит и какой у кого шлюз.
Вот столбец OPTIONS, надо пояснить немного. Тут ключ fallbaсk заставляет сгенерировать дополнительные правила маршрутизации, на случай если балансировочные не смогут обработать пакет (интерфейс прилег к примеру), а циферка задает вес интерфейса. Чем вес больше, тем чаще в интерфейс будут поступать новые соединения (используется в итоге относительный вес, у кого в пропорции вес выше, туда и трафик чаще, задавать большое значение веса не рекомендуется). Балансировка происходит по принципу roundrobin уже самим ядром и базируется на факте установления соединения по маршруту клиент-сервер (в качестве клиента ваш маршрутизатор, а сервер соответственно, удаленный сервер). При этом маршруты кэшируются на некоторое время, и получается такой эффект: кто-то в локалке, полез к примеру на некий сайт (у которого один IP), трафик пошел через провайдера 1, затем кто-то еще полез туда же, и трафик побежит опять через провайдера 1 (если кэш не успел сбросится). Еще может получится, что у вас не симметричные провайдеры, как в примере, и так повезет, каждое четвертое соединение, попадающие на первого провайдера, окажется и самым «тяжелым», а мы хотели этого избежать… Тут уже простых решений нет, и эта статья вам никак не поможет.
Дав команду:
shorewall show routing
Можно увидеть построенную схему маршрутизации:
Пример маршрутизации
Shorewall 5.0.2.1 Routing at cent1.domain.local - Пт янв 8 23:41:30 MSK 2016
Routing Rules
0: from all lookup local
999: from all lookup main
10000: from all fwmark 0x10000/0xff0000 lookup pr1
10001: from all fwmark 0x20000/0xff0000 lookup pr2
20000: from 192.168.10.37 lookup pr1
20000: from 192.168.10.36 lookup pr2
32765: from all lookup balance
32767: from all lookup default
Table balance:
Table default:
default nexthop via 192.168.10.1 dev eth0 weight 1 nexthop via 192.168.10.1 dev eth2 weight 1
Table local:
local 192.168.10.37 dev eth0 proto kernel scope host src 192.168.10.37
local 192.168.10.36 dev eth2 proto kernel scope host src 192.168.10.36
local 172.16.3.1 dev tap0 proto kernel scope host src 172.16.3.1
local 172.16.3.129 dev tap1 proto kernel scope host src 172.16.3.129
local 172.16.248.1 dev lo proto kernel scope host src 172.16.248.1
local 172.16.0.1 dev eth1 proto kernel scope host src 172.16.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 192.168.10.255 dev eth2 proto kernel scope link src 192.168.10.36
broadcast 192.168.10.255 dev eth0 proto kernel scope link src 192.168.10.37
broadcast 192.168.10.0 dev eth2 proto kernel scope link src 192.168.10.36
broadcast 192.168.10.0 dev eth0 proto kernel scope link src 192.168.10.37
broadcast 172.16.3.255 dev tap1 proto kernel scope link src 172.16.3.129
broadcast 172.16.3.128 dev tap1 proto kernel scope link src 172.16.3.129
broadcast 172.16.3.127 dev tap0 proto kernel scope link src 172.16.3.1
broadcast 172.16.3.0 dev tap0 proto kernel scope link src 172.16.3.1
broadcast 172.16.248.1 dev lo proto kernel scope link src 172.16.248.1
broadcast 172.16.1.255 dev eth1 proto kernel scope link src 172.16.0.1
broadcast 172.16.0.0 dev eth1 proto kernel scope link src 172.16.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Table main:
192.168.10.1 dev eth2 scope link src 192.168.10.36
172.16.3.1 dev tap0 proto zebra
172.16.3.129 dev tap1 proto zebra
172.16.248.2 via 172.16.3.2 dev tap0 proto zebra metric 13
172.16.12.129 via 172.16.3.2 dev tap0 proto zebra metric 3
172.16.11.1 via 172.16.3.2 dev tap0 proto zebra metric 3
172.16.3.128/25 dev tap1 proto kernel scope link src 172.16.3.129
172.16.3.0/25 dev tap0 proto kernel scope link src 172.16.3.1
192.168.10.0/24 dev eth2 proto kernel scope link src 192.168.10.36 metric 101
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.37 metric 100
172.16.8.0/23 via 172.16.3.2 dev tap0 proto zebra metric 13
172.16.0.0/23 dev eth1 proto kernel scope link src 172.16.0.1 metric 100
Table pr1:
192.168.10.1 dev eth0 scope link src 192.168.10.37
default via 192.168.10.1 dev eth0 src 192.168.10.37
Table pr2:
192.168.10.1 dev eth2 scope link src 192.168.10.36
default via 192.168.10.1 dev eth2 src 192.168.10.36
Но, не все так плохо, и даже так оно работает достойно (к слову сказать, так оно работает у большинства решений, для «честной» балансировки используются весьма не простые решения, которые часто без поддержки на стороне провайдеров (обоих) не работают).
Дополненный файл переменных:
params
#
# Shorewall -- /etc/shorewall/params
#
# Assign any variables that you need here.
#
# It is suggested that variable names begin with an upper case letter
# to distinguish them from variables used internally within the
# Shorewall programs
#
# Example:
#
# NET_IF=eth0
# NET_BCAST=130.252.100.255
# NET_OPTIONS=routefilter,norfc1918
#
# Example (/etc/shorewall/interfaces record):
#
# net $NET_IF $NET_BCAST $NET_OPTIONS
#
# The result will be the same as if the record had been written
#
# net eth0 130.252.100.255 routefilter,norfc1918
#
###############################################################################
IF_RED1=eth0
GW_RED1=192.168.10.1
IF_RED2=eth2
GW_RED2=detect
IF_GRN=eth1
NET_GRN=172.16.0.0/23
IF_TUN=tap+
#LAST LINE -- DO NOT REMOVE
Можно заметить, что у второго провайдера шлюз указан как ключевое слово «detect», которое работает на соединениях с динамической адресацией. Для некоторый случаев (к примеру PPtP), сам Shorewall не может корректно определить шлюз, для чего используется файл с вспомогательным скриптом:
findgw
#
# Shorewall version 4 - Findgw File
#
# /etc/shorewall/findgw
#
# The code in this file is executed when Shorewall is trying to detect the
# gateway through an interface in /etc/shorewall/providers that has GATEWAY
# specified as 'detect'.
#
# The function should echo the IP address of the gateway if it knows what
# it is; the name of the interface is in $1.
#
# See http://ift.tt/1P4Oejr for additional
# information.
#
###############################################################################
LANG='C' nmcli --terse --fields IP6.GATEWAY device show ${1} | cut -f2- -d':' #IPv6
LANG='C' nmcli --terse --fields IP4.GATEWAY device show ${1} | cut -f2- -d':' #IPv4
И дополнит все это скрипт для NetworkManager (более простая версия была в прошлой статье, и она не учитывала, что после поднятия интерфейса, Shorewall не всегда корректно строит политику маршрутизации, поэтому мы для таких интерфейсов просто его перезапускаем).
/etc/NetworkManager/dispatcher.d/30-shorewall.sh
#!/bin/bash
IF=$1 # имя сетевого интерфейса, с которым связано событие
STATUS=$2 # новое состояние сетевого интерфейса
function check_prov() {
PARAM=$(grep -v '^#' /etc/shorewall/params | grep $1 | cut -d '=' -f 1)
if [ -z "$PARAM" ]; then
grep -v '^#' /etc/shorewall/providers | grep -q $1
[[ $? == 0 ]] && shorewall restart
else
grep -v '^#' /etc/shorewall/providers | grep -q $PARAM
[[ $? == 0 ]] && shorewall restart
fi
}
case $STATUS in
up)
# команды выполняемые после установления соединения
shorewall enable $IF
shorewall6 enable $IF
check_prov $IF
;;
down)
# команды выполняемые после разрыва соединения
shorewall disable $IF
shorewall6 disable $IF
check_prov $IF
;;
esac
Но, можно ли направить какой либо трафик по конкретному провайдеру? Ответ Да!
mangle
#
# Shorewall -- /etc/shorewall/mangle
#
# For information about entries in this file, type "man shorewall-mangle"
#
# See http://ift.tt/1JAPAkk for additional information.
# For usage in selecting among multiple ISPs, see
# http://ift.tt/1JAPB7G
#
# See http://ift.tt/1mMAgGT for a detailed description of
# the Netfilter/Shorewall packet marking mechanism.
#
####################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP
# PORT(S) PORT(S)
MARK(0x20000):P 172.16.0.4 0.0.0.0/0!172.16.0.0/12
Тут мы пометили весь трафик от 172.16.0.4 в любую сеть, кроме 172.16.0.0/12, меткой второго провайдера. Условия могут быть и хитрее, надо только учитывать, для трафика сгенерированного на нашем шлюзе, из правила нужно убрать ":P".
Сразу надо пояснить вот что: по настоящему регулировать скорость мы можем только при отправке. Входящий трафик, уже дошел до нашего интерфейса минуя все узкие места, и толкаясь в очередях, за право оказаться у нас на пороге.
Но отчаиваться рано, и есть механизмы, не столь изящные и надежные, как хотелось бы, но решающие эту проблему. В сетях на базе протоколов семейства IP, это решается таким образом:
Источник плавно наращивает скорость отправки, пока ответы о доставке (пакеты ACK в протоколе TCP) вообще приходят или приходят с нормальной задержкой. Если есть потери или растет задержка ACK, скорость снижается. Потом, спустя некоторый промежуток времени, скорость пытаются вновь поднять. И так происходит до окончания передачи.
А как же UDP? А с ним все просто, нет контроля доставки, нет головной боли. Отправил и ОК (это пусть получатель мучается).
Конечно, в чистом виде UDP обычно не используют в сложных задачах по передаче данных. Этот протокол обычно используют как основу, при реализации своего варианта контроля доставки (можно сказать, своих реализаций TCP, в случаях, когда стандартный не устраивает). Поэтому во многих протоколах работающих поверх UDP, контроль доставки тоже есть. Что не отменяет возможности слать непрерывный поток UDP во всю мощь, забивая канал связи цели (тот самый вариант DDoS).
Как же мы можем организовать приоритезацию трафика и выделения полосы пропускания входящего трафика? Ответ есть выше: создать задержку в получении на своей стороне (как следствие, задержку в генерации ACK) или если задержка неприлично высока, пакет отбросить.
В Linux это реализуется созданием псевдо-интерфейса IFB, который как бы встает между физическим интерфейсом и самим шлюзом, пропуская через себя входящий трафик. Трафик входит в физический интерфейс (мы его уже приняли на нем), и тут же отправляется в IFB, который уже регулирует, с какой скоростью, и в каком порядке пропустить этот трафик (или вообще отбросить).
В настройке нам поможет Shorewall (хотя можно и в /etc/modprobe.d прописать):
/etc/shorewall/init
#
# Shorewall -- /etc/shorewall/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall start", "shorewall-reload" or "shorewall restart" command.
#
# For additional information, see
# http://ift.tt/1P4Oejr
#
###############################################################################
modprobe ifb numifbs=3
ip link set ifb0 up
ip link set ifb1 up
ip link set ifb2 up
Тут тривиально, создали три псевдо-интерфейса IFB и их подняли.
Далее опишем интерфейсы, на которых мы будем регулировать трафик:
tcdevices
#
# Shorewall -- /etc/shorewall/tcdevices
#
# For information about entries in this file, type "man shorewall-tcdevices"
#
# See http://ift.tt/1JAPAkk for additional information.
#
###############################################################################
#NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED
#INTERFACE INTERFACES
1:$NET_GRN - 1000mbit hfsc,classify
2:ifb1 - 1000mbit hfsc,classify $NET_GRN
3:$NET_RED1 - 10mbit hfsc,classify
4:ifb0 - 10mbit hfsc,classify $NET_RED1
5:$NET_RED2 - 10mbit hfsc,classify
6:ifb2 - 10mbit hfsc,classify $NET_RED2
Тут мы в явном виде, задаем номера используемых интерфейсов (если не задать, Shorewall пронумерует их в порядке объявления файле), ассоциировали IFB с реальными интерфейсами, задали максимальную исходящую скорость (помним, только её мы и регулируем, и интерфейс ifb по сути это входящая линия) и задали дисциплины классификации и что трафик мы будем именно классифицировать.
Опишем те самые классы:
tcclasses
#
# Shorewall -- /etc/shorewall/tcclasses
#
# For information about entries in this file, type "man shorewall-tcclasses"
#
# See http://ift.tt/1JAPAkk for additional information.
#
###############################################################################
#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
1:1:2 - 1mbit 3mbit 2 default
1:1:3 - 256kbit full 1
2:1:2 - 1mbit 3mbit 2 default
2:1:3 - 256kbit full 1
3:1:2 - 1mbit 3mbit 2 default
4:1:3 - 256kbit full 1
5:1:2 - 1mbit 3mbit 2 default
5:1:3 - 256kbit full 1
6:1:2 - 1mbit 3mbit 2 default
6:1:3 - 256kbit full 1
Пока не будем делать ничего сложного (и оттого интересного и полезного), пока привяжем к каждому интерфейсу (включая IFB) по два класса.
В первом столбце мы ассоциируем интерфейс с классами. ::.
На интерфейсе всегда есть класс 1, который мы по сути, описали в tcdevices.
Далее, пакеты мы не маркировали (при классификации этого и нельзя сделать), и потому столбец использовать не будем, дальше идет самое интересное, минимально гарантированная полоса пропускания, и максимально возможная (не больше чем таковая у класса родителя), для данного класса. Приоритет задаст порядок разрешения спорной ситуации (у кого меньше, тот и пойдет первым, если вышел за приделы гарантированной полосы, и она уже кем-то другим занята полностью). В заключении идут опции, default говорит о том, что если фильтрами ничего не найдено (пакеты не отнесены к классам), то присвоить им класс по умолчанию).
Дальше, так исторически сложилось, что правила классификации реальных интерфейсов, находятся в файле:
mangle
#
# Shorewall -- /etc/shorewall/mangle
#
# For information about entries in this file, type "man shorewall-mangle"
#
# See http://ift.tt/1JAPAkk for additional information.
# For usage in selecting among multiple ISPs, see
# http://ift.tt/1JAPB7G
#
# See http://ift.tt/1mMAgGT for a detailed description of
# the Netfilter/Shorewall packet marking mechanism.
#
####################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP
# PORT(S) PORT(S)
CLASSIFY(1:3) 0.0.0.0/0 0.0.0.0/0 tcp - 80,443
CLASSIFY(3:3) 0.0.0.0/0 0.0.0.0/0 tcp 80,443
А для виртуальных IFB в:
tcfilters
#
# Shorewall -- /etc/shorewall/tcfilters
#
# For information about entries in this file, type "man shorewall-tcfilters"
#
# See http://ift.tt/1JAPAkk for additional information.
#
########################################################################################################
#INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH PRIORITY
#CLASS PORT(S) PORT(S)
2:3 0.0.0.0/0 0.0.0.0/0 tcp - 80,443
4:3 0.0.0.0/0 0.0.0.0/0 tcp 80,443
В примере выше, я поместил входящий трафик от HTTP(S) сервера в класс с номером 3 на физическом интерфейсе, и на виртуальный, ассоциированный с ним, и исходящий я сделал аналогично, но «развернув порты». Очень внимательно отнеситесь к тому, что соединения часто двунаправленны, и расписывать их классификацию надо отдельно для каждого направления, не зависимо от того, кто инициировал, клиент или сервер.
Именно тут, и начинает трещать крыша. Для понимания поможет картинка (прошу ногами особо не бить, в Visio работать толком не умею).
Резать трафик в итоге можно на разных участках, не применяя IFB, если у вас один провайдер, а сам шлюз, трафик не принимает (не является его получателем). Если провайдеров больше, а шлюз сам активно принимает трафик (он к примеру обслуживает VPN), тогда без IFB выкручиваться не легко.
P.S.
В следующей статье я планирую подробнее остановится на QoS, особенно в свете распространения VoIP технологий. Тема большая, и нужно все хорошенько спланировать. Если вас интересует некий аспект более подробно, пишите запрос в комментарии, я учту пожелания в следующей статье.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий