The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Проблема-автоматическое изменение default gateway в VM-KVM"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Виртуализация / Linux)
Изначальное сообщение [ Отслеживать ]

"Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от mr.yaky (ok) on 14-Окт-11, 18:06 
Прошу помощи однофорумчан :

Есть сервер с CentOS 6.0 на нем настроена и работает виртуализация KVM, виртуалки тоже CentOS 6.0

Поставили сервер на colocation в ДЦ, провайдер на выбранном нами тарифном плане,
как уже позже выяснилось, на порту делает ограничение - 1 mac адрес , хотя дает несколько белых IP адреса.

структура подключения сети у нас следующая :
ISP-eth  -->    eth0 -->    br0 -->    KVM_VM_eth0

подсеть - 203.0.113.0/23 - белые IP адреса (адресация изменена для примера)

203.0.113.2   (br0)  - шлюз провайдера
203.0.113.175 (br0) - шлюз - он же гипервизор
203.0.113.218 (KVM_VM_eth0) - виртуалка

так вот работает сеть только на 203.0.113.175 (br0),
когда запускаю на гипервизоре виртуальную машину, присвоив ей IP:203.0.113.218/23, GW:203.0.113.2 то трафик
не входит в мир и виртуальная машина также из вне не доступна! При выключенном
файрволе суть проблемы та же! Гипервизор - естественно из виртуалки пингуется.

связался с провайдером он сказал, что есть ограничение на порту 1 mac (от провайдера приходит один кабель) и предложил два варианта:
1. настроить свой основной сервер роутером для белых IP, чтобы виртуальные машины ходили через него.
2. сменить тарифный план, где нет таких ограничений, который стоит в два раза дороже.

Конечно же делаю первый вариант :

На гипервизоре выключаю файрвол (или добавляю -A FORWARD -d 203.0.113.0/23 -j ACCEPT , -A FORWARD -s 203.0.113.0/23 -j ACCEPT)

смотрю чтобы был разрешен роутинг пакетов:

[root@gateway ~]# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

в виртуальной машине, делаю следующие настройки  IP:203.0.113.218/23, GW:203.0.113.175

после делаю пинг с виртуалки:203.0.113.175

[root@virt-machine ~]#ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  From 203.0.113.175: icmp_seq=1 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=39.7 ms
  From 203.0.113.175: icmp_seq=2 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=39.2 ms

видно, что несколько пакетов  проходит и потом все залипает и  сеть не работает.

тут же:

[root@virt-machine ~]# ping 203.0.113.175
PING 203.0.113.175 (203.0.113.175) 56(84) bytes of data.
64 bytes from 203.0.113.175: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 203.0.113.175: icmp_seq=2 ttl=64 time=0.170 ms
64 bytes from 203.0.113.175: icmp_seq=3 ttl=64 time=0.206 ms
64 bytes from 203.0.113.175: icmp_seq=4 ttl=64 time=0.166 ms
--- 203.0.113.175 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3926ms
rtt min/avg/max/mdev = 0.166/0.186/0.206/0.018 ms

Если подождать некоторое время, то снова можно пропустить пару пакетов и
сеть снова залипнет. Через некоторое время опять.

делаю пинг из вне  на виртуальную машину:
$ ping 203.0.113.218
PING 203.0.113.218 (203.0.113.218): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10


пробовал отключать gso,tso,lro внутри виртуалки

# ethtool -K eth0 gso off
# ethtool -K eth0 tso off
# ethtool -K eth0 lro off

Попробовал сделать на шлюзе-гипервизоре NAT , и прописал соответствующие настройки в вируалке - все работает как часы !!! А с белыми IP адресами не пашет.

Также раньше настраивал виртуализацию на трех разных серверах в другом ДЦ - там нет ограничения на порту только для 1 mac'a
плюс стоит свой свич и все отлично работает.

На этом все не заканчивается  ! :

Пошел дальше - попросил провайдера снять на несколько часов органичнее 1 mac на порту - админам респект и уважуха,
потому как пошли на встречу и выполнили просьбу.

Тестирую :

Тест 1. настраиваю сеть в виртуалке - IP:203.0.113.218/23, GW:203.0.113.2(шлюз провайдера) - трафик ходит все работает :

[root@virt-machine ~]# ip route ls
62.149.12.0/23 dev eth0  proto kernel  scope link  src 203.0.113.218
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 203.0.113.2 dev eth0

[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=38.9 ms

--- 8.8.8.8 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6672ms
rtt min/avg/max/mdev = 38.882/39.059/39.335/0.276 ms

root@dvk ~]# traceroute yandex.ru
traceroute to yandex.ru (77.88.21.11), 30 hops max, 60 byte packets
1  gw2.isp.net (203.0.113.2)  0.514 ms  0.488 ms  0.510 ms
2  hobbit.isp.net (203.19.2.99)  0.841 ms  0.814 ms  0.814 ms
3  yandex-10G-gw.ix.net.ua (195.35.65.88)  0.547 ms  0.524 ms  0.507 ms
4  panas-vlan601.yandex.net (87.250.233.69)  7.953 ms  7.949 ms  7.913 ms
5  213.180.213.118 (213.180.213.118)  20.035 ms  20.009 ms  20.009 ms
6  l3-s900-dante.yandex.net (213.180.213.70)  20.328 ms  20.332 ms  20.411 ms
7  s600-s900.yandex.net (213.180.213.54)  23.734 ms  20.694 ms  20.659 ms
8  yandex.ru (77.88.21.11)  20.867 ms  20.586 ms  20.557 ms


Тест 2. настраиваю сеть в виртуалке - IP:203.0.113.218/23, GW:203.0.113.175(мой шлюз) - трафик также ходит все работает ,
но в глаза бросаются сразу следующие моменты - первые пакеты идут через мой шлюз, а потом каким-то образом виртуалка
переключает маршрут и пытается использовать по умолчанию шлюз провайдера, хотя в ip route строго задан мой шлюз пот умолчанию. Примеры ниже:

[root@virt-machine ~]# ip route ls
62.149.12.0/23 dev eth0  proto kernel  scope link  src 203.0.113.218
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 203.0.113.175 dev eth0

[root@virt-machine ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * 209.85.249.22 (209.85.249.22)  39.068 ms  39.071 ms
6  72.14.239.60 (72.14.239.60)  39.525 ms  41.753 ms  41.711 ms
7  209.85.254.114 (209.85.254.114)  41.518 ms 209.85.254.118 (209.85.254.118)  38.617 ms  38.578 ms
8  google-public-dns-a.google.com (8.8.8.8)  38.764 ms  38.908 ms  38.865 ms

еще раз - будет уже по другому :

[root@virt-machine ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  gw2.isp.net (203.0.113.2)  0.909 ms  0.872 ms  0.897 ms
2  * * *
3  google-gw.itsinternet.net (213.133.164.166)  1.075 ms  1.108 ms  1.645 ms
4  209.85.249.22 (209.85.249.22)  38.533 ms  38.507 ms 209.85.241.54 (209.85.241.54)  65.360 ms
5  72.14.239.60 (72.14.239.60)  39.010 ms  38.989 ms  38.949 ms
6  209.85.254.118 (209.85.254.118)  38.690 ms 209.85.254.112 (209.85.254.112)  39.108 ms 209.85.254.114 (209.85.254.114)  39.078 ms
7  216.239.46.183 (216.239.46.183)  39.314 ms * *
8  google-public-dns-a.google.com (8.8.8.8)  38.972 ms  38.812 ms  38.770 ms

дальше все работает то есть, как то переключаются маршруты и сразу используется шлюз провайдера,
когда не было разрешено больше 1 mac адреса, то не работало, потому как маршруты переключатся и по умолчанию используется шлюз провайдера ,
а он не доступен потому, как действует ограничение на 1 mac и трафик со вторым mac'ом просто зарезается на порту свича.

проверяю еще раз :

рестартую сеть

[root@virt-machine ~]# service network restart
Shutting down interface eth0:  [  OK  ]
Shutting down loopback interface:  [  OK  ]
Bringing up loopback interface:  lo: Disabled Privacy Extensions
[  OK  ]
Bringing up interface eth0:  [  OK  ]

[root@virt-machine ~]# ip route
62.149.12.0/23 dev eth0  proto kernel  scope link  src 203.0.113.218
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 203.0.113.175 dev eth0

[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 203.0.113.175: icmp_seq=1 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=39.0 ms
From 203.0.113.175: icmp_seq=2 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=57 time=39.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=38.8 ms

--- 8.8.8.8 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8871ms
rtt min/avg/max/mdev = 38.811/39.023/39.629/0.280 ms

[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=39.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=38.9 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4221ms
rtt min/avg/max/mdev = 38.864/39.066/39.477/0.328 ms


[root@virt-machine ~]# traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  gw2.isp.net (203.0.113.2)  0.526 ms  0.478 ms  0.492 ms
2  * * *
3  google-gw.itsinternet.net (213.133.164.166)  1.000 ms  1.039 ms  1.112 ms
4  209.85.241.54 (209.85.241.54)  1.376 ms 209.85.249.22 (209.85.249.22)  38.755 ms  38.734 ms
5  72.14.239.60 (72.14.239.60)  38.694 ms 72.14.239.14 (72.14.239.14)  25.191 ms 72.14.239.60 (72.14.239.60)  38.650 ms
6  209.85.254.112 (209.85.254.112)  38.474 ms 209.85.254.118 (209.85.254.118)  38.688 ms 209.85.250.231 (209.85.250.231)  30.608 ms
7  * * *
8  72.14.236.68 (72.14.236.68)  53.332 ms google-public-dns-a.google.com (8.8.8.8)  40.639 ms  39.771 ms

пройдет время, маршрут удалится - и можно повторить ситуацию еще раз


[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 203.0.113.175: icmp_seq=1 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=39.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=38.7 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4755ms
rtt min/avg/max/mdev = 38.718/39.139/39.635/0.395 ms
[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=38.9 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2760ms
rtt min/avg/max/mdev = 38.922/39.031/39.199/0.120 ms


ИТОГ:

Что это за такое магическое переопределение шлюза по умолчанию? И как с этим боротся, что бы всегда использовался мой шлюз.
Подскажите пожалуйста кто-то , а то фантазия уже закончилась.

Наперед огромное спасибо.


Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от JohnProfic (ok) on 14-Окт-11, 21:03 
sysctl -w net.ipv4.conf.all.accept_redirects=0
?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от iro_zirk (ok) on 15-Окт-11, 11:07 
как решить эту проблему?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от JohnProfic (ok) on 15-Окт-11, 16:31 
> как решить эту проблему?

Какую? Комманду выше нужно выполнить и посмотреть что будет. По идее все должно быть хорошо.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

2. "Проблема-автоматическое изменение default gateway в VM-KVM"  +1 +/–
Сообщение от PavelR (??) on 15-Окт-11, 10:24 
Ниасилил, многабукав.


На Xen я делаю через proxy_arp.


net.ipv4.conf.eth0.proxy_arp = 1

VM:

net.ipv4.conf.vif1/0.proxy_arp = 1

ifconfig eth0 - стандартно (HOSTIP)

ifconfig vif1.0 - при поднятии в скриптах выставляется адрес eth0 (HOSTIP) с маской /32

Линуксовые виртуалки (дебиан) конфигурятся потом так:

auto eth0
iface eth0 inet static
address IP
pointopoint HOSTIP
gateway HOSTIP
netmask 255.255.255.255
post-up ethtool -K eth0 tx off


Виндовые виртуалки тоже работают. Маску там я ставил /24 потому что такая маска на основном физ интерфейсе HOSTIP. Помоему можно ставить любую меньшую маску =) Дальше всё  работает из-за включенного proxy-arp.

а, да. При поднятии виртуалки я также прописываю в хост-системе маршрут к ней:

ip route add ${addr} dev ${vif} src ${hostip}

------------------


Существует также второй вариант, без использования proxy_arp.

Это арп-публикация:


Делается так:

/usr/sbin/arp -i eth0 -d $IP pub


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

ip route add ${addr} dev ${vif} src ${hostip}

Этот вариант может не очень корректно сработать с Win, которая никак не поймет что Ethernet бывает point-to-point.


В обеих случаях снаружи все адреса видятся привязанными к мак-адресу физ сервера.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от mr.yaky (ok) on 16-Окт-11, 11:48 
Изменение переменной  net.ipv4.conf.all.accept_redirects=0 ничего не решило.

А вот за подсказку с proxy_arp огромное спасибо! Не знал раньше о таком.
Теперь все работает, как часы и кому интересно, как именно обошел проблему - по порядку:

читаем, что это за технология - http://xgu.ru/wiki/Proxy_ARP
также четвертая ссылка в гугле ведет на отличную статью http://habrahabr.ru/blogs/linux/70512/
но я не хотел сильно глобально переделывать структуру сети и использовать tap интерфейсы, потому сделал приблизительно, как
написано здесь https://www.opennet.ru/tips/info/923.shtml

Пришлось немного перестроить структуру сети.
Сейчас она выглядит вот так :

ISP-eth  -->   eth0 -->  eth1 -->  br1 -->   KVM_VM_eth0

203.0.113.175/23 (eth0), GW:203.0.113.2
203.0.113.175/23 (br1)

интерфейс br1 используем для наших KVM виртуалок

в /etc/rc.local добавляем переопределении маршрутов :

ip route del 203.0.113.0/23 dev eth0
ip route add 203.0.113.2 dev eth0

и не забываем включить proxy_arp в /etc/sysctl.conf:

net.ipv4.conf.eth0.proxy_arp = 1
net.ipv4.conf.br1.proxy_arp = 1

! Уточнение : Ethernet link есть только на интерфейсе eth0, но это нам не мешает использовать eth1 для
наших целей, который мы просто поднимаем и создаем поверх него br1.

теперь все работает, как и задумывалось - все виртуалки ходят через собственный шлюз,
а в traceroute из vm есть честный промежуточный хоп - наш шлюз :

[root@virt-machine ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  server1.isp.com (203.0.113.175)  0.198 ms  0.141 ms  0.125 ms
2  gw2.isp.net (203.0.113.2)  0.493 ms  0.524 ms  0.514 ms
3  * * *
4  google-gw.itsinternet.net (213.133.164.166)  0.830 ms  0.956 ms  0.929 ms
5  209.85.249.22 (209.85.249.22)  53.853 ms  53.812 ms  53.684 ms
6  72.14.239.60 (72.14.239.60)  38.750 ms  38.867 ms  38.848 ms
7  209.85.254.118 (209.85.254.118)  38.543 ms 209.85.254.112 (209.85.254.112)  38.820 ms  38.735 ms
8  google-public-dns-a.google.com (8.8.8.8)  39.097 ms  38.863 ms  39.113 ms

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от mr.yaky (ok) on 29-Окт-11, 21:20 
!Дополнение!

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

в дополнение нужно удалить созданные маршруты по умолчанию на br1 и создать новые -
добавляем в /etc/rc.local еще следующие :

ip route del 203.0.113.0/23 dev br1
ip route add 203.0.113.218 dev br1
ip route add 203.0.113.219 dev br1

в итоге у вас должно быть так:

[root@gateway ~]# ip route ls
203.0.113.219 dev br1  scope link
203.0.113.218 dev br1  scope link
203.0.113.2 dev eth0  scope link
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev br1  scope link  metric 1006
default via 203.0.113.2 dev eth0

а также в iptables форвардинг лучше разрешить только на те IP, которые есть у вас дополнительно кроме шлюзового IP - к примеру, у нас 203.0.113.218, 203.0.113.219, значит соответственно:

удаляем ->
-A FORWARD -d 203.0.113.0/23 -j ACCEPT
-A FORWARD -s 203.0.113.0/23 -j ACCEPT

добавляем ->
-A FORWARD -d 203.0.113.218/32 -j ACCEPT
-A FORWARD -s 203.0.113.218/32 -j ACCEPT
-A FORWARD -d 203.0.113.219/32 -j ACCEPT
-A FORWARD -s 203.0.113.219/32 -j ACCEPT

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

Спасибо еще раз PavelR за подсказку - смотреть в сторону proxy_arp.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Проблема-автоматическое изменение default gateway в VM-KVM"  +/–
Сообщение от Andrey Mitrofanov on 29-Окт-11, 22:21 
> Есть сервер с CentOS 6.0 на нем настроена и работает виртуализация KVM,
> виртуалки тоже CentOS 6.0

[...]
> Что это за такое магическое переопределение шлюза по умолчанию? И как с
> этим боротся, что бы всегда использовался мой шлюз.
> Подскажите пожалуйста кто-то , а то фантазия уже закончилась.

И я тоже "многа букаф и ниасилил". :-S

Не знаю, поможет ли, но напомнило -- вот здесь http://zaitcev.livejournal.com/211321.html человек решает проблемы с какими-то неработающими статическими роутами, используя zebra routed на хосте и в KVM-ах. На Fedora.

+++Отдельное спасибо http://planet.kernel.org/

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру