LINUX.ORG.RU
ФорумAdmin

Настройка Iptables для внутрених адресов OpenVPN

 ,


1

2

Здравствуйте!

Поставлена задача скрыть от внешнего мира сервер с 1С, к которому подключаются по RDP из вне 10 клиентов. Сервер 1С скрыт за роутером с статическим IP-адресом и проброшенным портом 3389 наружу.

Перебрав кучу вариантов, мною было принято решение «спрятать» весь трафик, между клиентами и сервером, в VPN канал. Порывшись в Инете, я принял решение использовать OpenVPN.

И так, у нас есть «три точки», которые находятся в разных местах и в разных сетях. 1-я точка: OpenVPN сервер на базе Ubuntu 16.04 (в сети №1 с белым IP-адресом) 2-я точка: сервер 1С (в сети №2) . 3-я точка: пул клиентов в количестве 10 штук (в разных местах и в разных сетях) - точка-многоточка :-).

И так, OpenVPN сервер имеет на интерфейсе tun0 адрес 10.10.2.1, сервер 1С 10.10.2.202 и остальные клиенты от 10.10.2.6 до 10.10.2.42

После запуска всего этого дела, клиенты и сервер соединяются через OpenVPN сервер. Как бонус торчащий наружу порт 3389 был закрыт.

Но при таком раскладе сервер с 1С получается абсолютно «голый» перед всеми клиентами в VPN туннеле. Поэтому появилась новая задача - средствами iptables - закрыть все порты для адреса 10.10.2.202 оставив открытым лишь порт RDP 3389 для сервера 1С.

Прошу помощи в создании этого правила для iptables если это возможно, или предложите свой вариант для решения этой задачи.

tun+ src 10.10.2.202.

iptables -A INPUT -i tun+ -d 10.10.2.202/32 -p tcp -m tcp  -m conntrack --ctstate  NEW,ESTABLISHED --dport 3389 -j ACCEPT
iptables -A OUTPUT -o tun+ -m conntrack --ctstate ESTABLISHED --sport 3389 -j ACCEPT
-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT
все, только будет tcp траф. на tun по 3389 порту бегать. Если вам действительно это нужно и больше ничего не отвалится.

ving2 ()
Ответ на: комментарий от ving2
iptables -A OUTPUT -o tun+ -m conntrack --ctstate ESTABLISHED --sport 3389 -j ACCEPT 

iptables v1.6.0: unknown option "--sport" Ругается!!! Чем заменить? Да и на сервак бы както ходить через SSH хотелось бы.

vitaros ()
Ответ на: комментарий от vitaros

добавь после tun+ -p tcp . а ssh где висит на tun ? Вообщем по аналогии будет, только порт 22 или на каком он порту работает.

ving2 ()
Ответ на: комментарий от ving2

И если хочется ходить по ssh на внешний адрес. То и правило нужно соответствующее. И как бы по хорошему, нужно разрешить трафик на lo еще.

ving2 ()
Ответ на: комментарий от ving2

Спасибо за быстрый oтвет! Хочу объяснить без лишних слов что мне нужно: Нужно закрыть все порты, кроме tcp 3389, на адресе 10.10.2.202 не закрывая всего остального на интерфейсе tun0.

vitaros ()
Ответ на: комментарий от vitaros

у вас на этом хосте вообще какие интерфейсы есть, и что через них ходит? надо наверно с этого начинать. Если все порезать, и оставить 3389 порт на tun, то и сам tun отвалится. Ему тоже связь нужна.

ving2 ()
Ответ на: комментарий от ving2

Структура такая: 1. enp0s3 - физический интерфейс с адресом 192.168.1.9. На него с жилезного роутера прокинут порт 1194. 2. tun0 - виртуальный интерфейс OpenVPN. Ему выдан адрес 10.10.2.1 3. Клиенты и сервер 1С подключены к OpenVPN

vitaros ()
Ответ на: комментарий от vitaros

Для начала нужно разрешить трафик, от роутера к серваку через enp0s3/DHCP если есть к примеру. потом нужно разрешить коннектиться на впн сервер, если конечно я правильно понял то вот так:

ipt -A INPUT -i enp0s3 -d 192.168.1.9 -s  0/0 -p proto_vpn -m conntrack --ctstate  NEW,ESTABLISHED  --dport 1194  -j ACCEPT
iptables -A OUTPUT -o enp0s3 -p proto_vpn -m conntrack --ctstate ESTABLISHED --sport 1194 -j ACCEPT
если 192.168.1.9 динамический, то укажите сеть. Ну а дальше по аналогии, ssh и все остальное.

ving2 ()

Поэтому появилась новая задача - средствами iptables - закрыть все порты для адреса 10.10.2.202 оставив открытым лишь порт RDP 3389 для сервера 1С.

Как-то так

-A forward -i tun[ваш-интерфейс] -d 10.10.2.202 -p tcp --dport 3389 -j ACCEPT
-A forward -i tun[ваш-интерфейс] -d 10.10.2.202 -j DROP

anc ★★★★★ ()
Ответ на: комментарий от anc

поделитесь инфой как научиться определять, что этот траф. будет транзитным. Если адрес назначения не принадлежит этой машине (в данном случе у tun0 инт. src 10.10.2.1), то траф. попадет в цепочку форвард... правильные мысли или вообще не туда?

ving2 ()
Ответ на: комментарий от anc

Без client-to-client ничего не видит . Подключение на по RDP 10.10.2.202:3389 нету вообще. С включёным client-to-client проскакивает всё! Т.е правила ника не влияют.

Куда копать?

vitaros ()
Ответ на: комментарий от vitaros

Если без client-to-client не работает скорее всего проблема в других правилах iptables, т.е. существующих до этого. Для пробы можите вместо -A -I написать, если заработает то потом в правилах разбираться.
В туже тему добавить

-A forward -i tun[ваш-интерфейс] -s 10.10.2.202 -p tcp --sport 3389 -j ACCEPT

anc ★★★★★ ()
Ответ на: комментарий от vitaros

На всякий случай поясню, при client-to-client ovpn обрабатывает все у себя внутри, т.е. до nf дело не доходит. Поэтому только при выключенном можно рулить еще и правилами iptables.

anc ★★★★★ ()
Ответ на: комментарий от anc

Спасибо за информацию

На всякий случай поясню, при client-to-client ovpn обрабатывает все у себя внутри

Очистил таблицу iptables.

На данный момент iptables таблица виглядит так:

Chain INPUT (policy ACCEPT 2642 packets, 300K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       44  2640 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 2003 packets, 586K bytes)
num   pkts bytes target     prot opt in     out     source               destination

т.е
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
 
Пингуется только 10.10.2.1. Клиенты друг друга не видят. Официальная документация тоже об этом молчит. Подскажите как допилить маршруты

vitaros ()
Ответ на: комментарий от vitaros

Предлагаю начать со схемы.
1. откуда пингуем и кого? С сервера на 10.10.2.202 ? Или с других клиентов 10.10.2.0/24? Если с клиентов что кажит тот же tcpdump ?
2. iptables-save в студию
Пока наверное все.
ЗЫ Если с client-to-client все работает, значит с маршрутами усе норм, осталось fw допилить.
ЗЫЫ Ну и еще пальцем в небо cat /proc/sys/net/ipv4/ip_forward

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от anc

Ну и еще пальцем в небо cat /proc/sys/net/ipv4/ip_forward

Тут стоит единица

Попробую начать с нуля. Думаю что гдето чегото наворотил.
Дойду до настройки iptables отпишусь.

vitaros ()
Ответ на: комментарий от anc

Да, точно оно. Уж простите запамятовал.
Из документации

--server network netmask ['nopool']
A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.
For example, --server 10.8.0.0 255.255.255.0 expands as follows:

 mode server
 tls-server
 push "topology [topology]"

 if dev tun AND (topology == net30 OR topology == p2p):
   ifconfig 10.8.0.1 10.8.0.2
   if !nopool:
     ifconfig-pool 10.8.0.4 10.8.0.251
   route 10.8.0.0 255.255.255.0
   if client-to-client:
     push "route 10.8.0.0 255.255.255.0"
   else if topology == net30:
     push "route 10.8.0.1"

 if dev tap OR (dev tun AND topology == subnet):
   ifconfig 10.8.0.1 255.255.255.0
   if !nopool:
     ifconfig-pool 10.8.0.2 10.8.0.253 255.255.255.0
   push "route-gateway 10.8.0.1"
   if route-gateway unset:
     route-gateway 10.8.0.2

anc ★★★★★ ()
Ответ на: комментарий от anc

Огромеееееенная благодарность за помощь!!!

Видимо с виндой были проблемы. После перезагрузки интерфейса всё начало работать «по логике».

Думаю можна сделать итог:
1. Для того что бы правила фаервола срабатывали в vpn сети OpenVPN сервера, в конфигурации этого сервера исключаем опцию client-to-client.
2. В конфигурацию сервера добавляем маршрут из двух записей:
route 10.10.2.0 255.255.255.0 - маршрут для сервера.
push «route 10.10.2.0 255.255.255.0» - маршрут для клиента.
3. Пишем правила для фаервола

-A forward -i tun[ваш-интерфейс] -d 10.10.2.202 -p tcp --dport 3389 -j ACCEPT
-A forward -i tun[ваш-интерфейс] -d 10.10.2.202 -j DROP

vitaros ()
Ответ на: комментарий от vitaros

Насколько я понял вашу конфигурацию. Вот это не нужно route 10.10.2.0 255.255.255.0 - маршрут для сервера. опция server его сама добавит.

anc ★★★★★ ()
Ответ на: комментарий от anc

Решил кое-что допилить

Решил кое-что допилить

Ещё раз спасибо! Маршрут на сервере действительно лишний

Хочу реализовать такую схему:

1. Все видят сервер 1C на порту 3389

2. Администраторы видят всех пользователей ну и сервер 1C на порту 3389

3. Простые пользователи - видят только сервер1C на порту 3389 и больше не видят никого

Что я сделал?! 1. Поделил клиентов OpenVpn сервера на 3 группы (три подсети): А). Сервер 1C (10.10.2.0/24)

Б). Администраторы (10.10.1.0/24)

В). Простые пользователи (10.10.0.0/24)

2. Прописал маршруты на сервере и клиентах CCD-файлах

С первым пунктом (Все видят сервер 1C на порту 3389) решено!

Со вторым и третьим проблема. Пока прописал такие правила:

# Разрешаем порт 3389 для сервера 10.10.2.202
-A FORWARD -p tcp -m tcp -d 10.10.2.202/32 -i tun0 --dport 3396 -j ACCEPT
# Запрещаем всё для сервера 10.10.2.202
-A FORWARD -d 10.10.2.202/32 -i tun0 -j DROP
#Разрешаем ходить пакетам между подсетью 10.10.0.0 и сервером 1С
-A FORWARD -i tun0 -s 10.10.0.0/24 -d 10.10.2.202 -j ACCEPT
#Разрешаем ходить пакетам между сетью админов и простых пользователей
-A FORWARD -i tun0 -s 10.10.0.0/24 -d 10.10.1.0/24 -j ACCEPT
#Запрещаем всё для подсети простых пользователей
-A FORWARD -s 10.10.0.0/24 -i tun0 -j DROP



И вот возникает вопрос как сделать, чтоб админы видели пользователей а пользователи админов нет?
vitaros ()
Ответ на: Решил кое-что допилить от vitaros

1. Вопрос: как вы реализовали три подсети в ovpn ?
2.

-A FORWARD -i tun0 -s 10.10.0.0/24 -d 10.10.2.202 -j ACCEPT
уже не имеет смысла, так как выше
-A FORWARD -d 10.10.2.202/32 -i tun0 -j DROP

3.

И вот возникает вопрос как сделать, чтоб админы видели пользователей а пользователи админов нет?

А в целом все также как и на «подиванном» роутере
От юзверов к админам
-A FORWARD ..... -m state --state ESTABLISHED,RELATED -j ACCEPT
От админов к юзверам
-A FORWARD .... -j ACCEPT

anc ★★★★★ ()
Ответ на: комментарий от anc

Отвечаю на первый вопрс.

Возможно это моё буйное воображение, но:

Сервер имеет адрес и маску - 10.10.3.0 255.255.255.0
Сервер 1С - 10.10.2.0 255.255.255.0
Админы - 10.10.1.0 255.255.255.0
Простые пользователи  - 10.10.0.0 255.255.255.0
Прописал маршруты:
В конфигурации сервера:
route 10.10.2.0 255.255.255.0
route 10.10.1.0 255.255.255.0
route 10.10.0.0 255.255.255.0

В файле CCD конфигурации сервера1С
ifconfig-push 10.10.2.202 10.10.2.203
push "route 10.10.1.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0" 

В файле CCD конфигурации администратора
ifconfig-push 10.10.1.9 10.10.1.10
push "route 10.10.2.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0" 

В файле CCD конфигурации простого пользователя
ifconfig-push 10.10.0.13 10.10.0.14
push "route 10.10.2.0 255.255.255.0"
push "route 10.10.1.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0" (можно и не прописывать)
Для клиента можно не прописывать - push «route 10.10.0.0 255.255.255.0». Если не прописать этот маршрут, то пользователи подсети 10.10.0.0 255.255.255.0 не видят друг-друга. Но если прописать, в конфигурационном файле, на стороне клиента route 10.10.0.0 255.255.255.0, то клиенты прекрасно видят друг-друга (не вариант!).

На второй вопрос.

-A FORWARD -i tun0 -s 10.10.0.0/24 -d 10.10.2.202 -j ACCEPT – разрешает видеть сервер 1С
-A FORWARD -s 10.10.0.0/24 -i tun0 -j DROP - запрещает всё.
Если убрать первое правило то думаю, пользователи к серверу 1С потеряют доступ.

3.

Извините, но я не совсем понял Ваш ответ.

Можете ли Вы в несколько предложений набросать алгоритм?

vitaros ()
Ответ на: комментарий от vitaros

По первому пункту
ip r s
ip a s
Полный конфиг сервера

Второй
Правило c DROP прописано раньше, поэтому дальнейшее правило с ACCEPT уже не имеет смысла, до него не дойдет.

Третий
Да уже вроде набросал. Вместо многоточий(....) правила для сетей прописываем, от кого и куда.

anc ★★★★★ ()
Ответ на: комментарий от anc

По первому пункту

ip r s ? ip a s ?

Конфиг сервера (это тестовый вариант, без TLS-а,буду допиливать)

port 1194
proto udp
dev tun0
ca keys/cornecert/ca.crt
cert keys/cornecert/keyovpn1.crt
key keys/cornecert/keyovpn1.key
dh keys/cornecert/dh1024.pem
server 10.10.3.0 255.255.255.0
crl-verify keys/cornecert/crl.pem
cipher AES-256-CBC
user nobody
group nogroup
status servers/Servovpn1/logs/openvpn-status.log
log-append servers/Servovpn1/logs/openvpn.log
verb 2
mute 20
max-clients 100
management 127.0.0.1 5555
keepalive 10 120
client-config-dir /etc/openvpn/servers/Servovpn1/ccd
comp-lzo
persist-key
persist-tun
ccd-exclusive
route 10.10.2.0 255.255.255.0 #Сервера
route 10.10.1.0 255.255.255.0 #Админы
route 10.10.0.0 255.255.255.0 #Пользователи
В файле CCD конфигурации сервера1С
ifconfig-push 10.10.2.202 10.10.2.203
push "route 10.10.1.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0" 
В файле CCD конфигурации администратора
ifconfig-push 10.10.1.9 10.10.1.10
push "route 10.10.2.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0" 
В файле CCD конфигурации простого пользователя
ifconfig-push 10.10.0.13 10.10.0.14
push "route 10.10.2.0 255.255.255.0"
push "route 10.10.1.0 255.255.255.0"
Конфиг файл админа или пользователя (похожи, но разные ключи и сертификаты)
client
proto udp
dev tun
ca ca.crt
dh dh1024.pem
cert keyclient1ovpn1.crt
key keyclient1ovpn1.key
remote xxx.xxx.xxx.xxx 1194
cipher AES-256-CBC
verb 2
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind

По второму пункту

И снова Вы абсолютно правы!!!

По третьему пункту

Набросал очередную «кашу».

#Типа разрешил отвечать на запросы
-A FORWARD -s 10.10.2.202/32 -i tun0 -j ACCEPT
#Разрешаем админам ходить на сервер 1С
-A FORWARD -p tcp -m tcp -s 10.10.1.0/24 -d 10.10.201.1/32 -i tun0 --dport 3396 -j ACCEPT
#Разрешаем пользователям ходить на сервер 1С
-A FORWARD -p tcp -m tcp -s 10.10.0.0/24 -d 10.10.201.1/32 -i tun0 --dport 3396 -j ACCEPT
#Запрещаем всё для сервера 1С
-A FORWARD -d 10.10.2.202/32 -i tun0 -j DROP
# Разрешаем связанные и установленые соединения для пользователей и админов
-A FORWARD -m state -s 10.10.0.0/24 -d 10.10.1.0/24 --state ESTABLISHED,RELATED -j ACCEPT
# Разрешаем всё для админов
-A FORWARD -s 10.10.1.0/24 -i tun0 -j ACCEPT
#Запрещаем всё проходящие пакеты на интерфейсе tun0
-A FORWARD -i tun0 -j DROP #Не совсем уверен правильно ли это
Вроде всё работает как мне нужно. Но прошу Вас подправить (указать на ошибку), что неправильно.

vitaros ()
Ответ на: комментарий от vitaros

Не знаю что у вас висит на 1с на порту 3396, но предположим все тот же rdp. Тогда возникает проблема, пользователь соединяется к 10.10.2.202 и уже с него может получить доступ к любому адресу согласно первому правилу "-A FORWARD -s 10.10.2.202/32 -i tun0 -j ACCEPT" Если с него не надо исходящих соединений в тунель, то тут также ESTABLISHED,RELATED
В остальном все правильно, но лично я упростил бы, что-то типа -i tun0 ESTABLISHED,RELATED т.е. оно будет по любому работать для всех, потом ACCEPT для разрешенных, ну и последним все правильно DROP

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

ну и последним все правильно DROP

Это полная ерунда. Такое правило не надо писать, а указывать в политике. Ибо вставлять дополнительно правила и не удобно и для ядра - накладно. Кто не верит, может влезть в исходники iptables и ужаснуться, как оно на самом деле общается с ядром.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

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

К дальней поездке.
А вообще «Это полная ерунда» - не зная всей остальной логики «рубить с плеча». Вот послушает вас ТС фиганет -P DROP и у него после это «внезапно» перестанет работать овер дофига чего. Ваша фамилия не Остер?

и для ядра - накладно.

На калькуляторе работаете?

Кто не верит, может влезть в исходники iptables и ужаснуться, как оно на самом деле общается с ядром.

iptables это интерфейс к netfilter который какбэ в ядре. ваш КО

anc ★★★★★ ()
Ответ на: комментарий от anc

Вот послушает вас ТС фиганет -P DROP и у него после это «внезапно» перестанет работать овер дофига чего. Ваша фамилия не Остер?

Можно подумать последним правилом с DROP он это руками не эмулирует. Ага. С простреливанием в ногу с трахом по открыванием чего-то дополнительного. Кто тут ещё рубит с плеча ещё надо посмотреть.

iptables это интерфейс к netfilter который какбэ в ядре. ваш КО

Вот именно, что КО. Но я добрый. Объясняю. Формируется бинарное дерево из правил в памяти, потом ядру говорится сбрось имеющееся и всоси новое. Вот так происходит редактирование правил, в отличии от добавления, где просто добавляется оттранслированная строчка.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Можно подумать последним правилом с DROP он это руками не эмулирует.

Конкретно у ТС - нет, там интерфейс указан.

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

Вы каждую секунду исправляете правила?

ЗЫ А вот про «дальнюю поездку» вы чего-то промолчали

anc ★★★★★ ()
Ответ на: комментарий от anc

Конкретно у ТС - нет, там интерфейс указан.

Это мало что меняет. Для полноценного файрвола такая политика тоже полезна.

Вы каждую секунду исправляете правила?

О, пошли стандартные лор-овкие аргументы. Не задумывались, почему редактирования правил долгое время не было вообще? И не только в iptables. Попробуйте удобно поредактировать кошковские acl-и.

А вот про «дальнюю поездку» вы чего-то промолчали

Так вы уже второй раз не объяснили о чём речь. В треде «поезд*» встречается только в в двух ваших последних комментариях.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Это мало что меняет.

Нет, меняет. Может у ТС там еще n-цать интерфейсов с полным ACCEPT. А задача только в части ограничения через tun0

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

Мимо.

Так вы уже второй раз не объяснили о чём речь. В треде «поезд*» встречается только в в двух ваших последних комментариях.

Хорошо, объясняю. Первым пишем -P DROP, на этот момент уже идем на север, что там нафигачили дальше и как отработает хз. Но самое простое, надо очистить правила (да, надо и все тут) iptables -F - собираемся в дорогу.

anc ★★★★★ ()
Ответ на: комментарий от anc

Может у ТС там еще n-цать интерфейсов с полным ACCEPT.

Да наздоровье. Политика удобна тем, что добавлять ACCEPT никто не мешает, при полном accept нужна всего-лишь одна строчка на интерфейс.

А задача только в части ограничения через tun0

Мы в одинаковой позиции: «только» это такое же додумывание на невысказанное.

Мимо.

Не хотите думать — ваше право, что не отменяет того, что аргумент на подумать приведен.

на этот момент уже идем ... собираемся в дорогу

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

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Да наздоровье. Политика удобна тем, что добавлять ACCEPT никто не мешает, при полном accept нужна всего-лишь одна строчка на интерфейс.

И в чем разница между одной DROP и одной ACCEPT ? Ведь один фиг цепочка дойдет до конца и только после этого, если правил не попадется, будет применена политика. Т.е. в любом случае или строка с DROP или строка с ACCEPT. Но при дэфолтной политике DROP шансов выстрелить в ногу больше. Вот лично я в ногу уже стрелял, больше не хочу, больно.

anc ★★★★★ ()
Ответ на: комментарий от anc

И в чем разница между одной DROP и одной ACCEPT ?

Ключевое слово «добавлять».

Но при дэфолтной политике DROP шансов выстрелить в ногу больше

Это когда вы только пишите файрвол. Но на то оно и процесс, нужно думать и пробовать. А вот когда в продакшене, то политика - надёжнее.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Ключевое слово «добавлять».

И там и там «Ключевое слово «добавлять».»

то политика - надёжнее.

С этим спорить крайне сложно. Для этого и создано было. Но вот «поездки» никто не отменял. Вообще спор явно зашел в тупик, каждый остается при своем мнении.

anc ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.