Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

29.04.2017

Google
WWW CITForum.ru
С Новым годом!
2003 г

Развертывание сети VPN

Павел Покровский
30.01.2003
LAN, #01/2003

В одной достаточно крупной компании, где имелась разветвленная сеть удаленных площадок, потребовалось развернуть виртуальную частную сеть (Virtual Private Network, VPN) и наладить шифрование информации между центральным и удаленными офисами, чтобы каждый филиал мог связываться с другим через защищенное соединение. Конкретное название используемой системы и точный алгоритм шифрования не имеют значения для целей статьи, так как одной из изюминок спроектированной схемы организации VPN была независимость решения от платформы и программного окружения. В общем случае шифратор является сквозным, т. е. шифрует все, что поступает в открытом виде на один из его интерфейсов, и передает в сеть уже зашифрованные данные через другой интерфейс.

Казалось бы, проще всего включить шифратор в «разрыв» локальной сети, т. е. установить его между коммутатором и маршрутизатором. Но одним из условий развертывания VPN было обеспечение бесперебойного функционирования сети в целом, независимо от того, включено шифрование или нет. Подключение шифратора вело к появлению узкого места в любом случае, однако при его установке на «горло» сети бесперебойность работы подвергалась серьезной опасности, так как, выйди шифратор из строя, данный офис потеряет связь с остальными. Для центрального офиса кратковременная потеря связи с удаленными площадками — небольшая трагедия, а вот последние удаленно работали с серверами, физически расположенными в центральном офисе компании, так что простои вследствие неполадок в работе шифрующего оборудования были недопустимы. Таким образом, функционирование локальной сети в целом должно было быть обеспечено независимо от работы шифраторов.

СХЕМА СЕТИ

Все рабочие станции центрального офиса и часть серверов подключались к одному коммутатору. Прочее серверное оборудование центрального офиса работало через другой коммутатор и относилось к демилитаризованной зоне. Оба коммутатора соединялись с маршрутизатором Cisco, который и связывал локальные сети центрального и удаленных офисов в единую корпоративную сеть. Топология удаленной локальной сети выглядела еще проще: коммутатор для подключения серверного оборудования отсутствовал, поэтому не было и демилитаризованной зоны, а единственный коммутатор присоединялся напрямую к маршрутизатору Cisco; тот, в свою очередь, связывался с маршрутизаторами центрального и удаленных офисов. Их взаимодействие осуществлялось по протоколу динамической маршрутизации EIGRP.

Идея подключения шифрующего устройства состояла в том, чтобы оно функционировало параллельно с коммутатором локальной сети. В центральном офисе шифратор подключался к коммутатору локальной сети, а не к коммутатору демилитаризованной зоны. В нашем случае шифратор представлял собой обычную i386-совместимую машину с двумя сетевыми интерфейсами и работал под управлением UNIX-подобной операционной системы. При желании подобная схема адаптируема к любой архитектуре и любой ОС, если она поддерживает маршрутизацию между интерфейсами.

Одному из интерфейсов шифратора был назначен IP-адрес той локальной сети, где он был установлен. Второму — IP-адрес виртуальной сети класса C. Для простоты первый интерфейс назовем «внутренним», а второй — «внешним». Открытый трафик поступал на внутренний интерфейс, а с внешнего отправлялся уже зашифрованный трафик, причем он был инкапсулирован таким образом, что IP-адресом отправителя пакета являлся IP-адрес внешнего интерфейса шифратора, а IP-адресом получателя — IP-адрес внешнего интерфейса шифратора того офиса компании, для которого предназначался изначальный открытый пакет. Сам шифратор не занимался никаким анализом проходящего через него трафика, т. е. был, как уже говорилось, сквозным.

ОРГАНИЗАЦИЯ ШИФРУЕМОГО СОЕДИНЕНИЯ

Для пояснения схемы мы рассмотрим пример работы по защищенному соединению между центральным офисом и одной из удаленных площадок. Трафик из локальной сети центрального офиса через коммутатор поступал на маршрутизатор Cisco. На маршрутизаторе были заданы правила условной маршрутизации (policy routing), согласно которым трафик, предназначавшийся для удаленного офиса компании, направлялся не в среду ATM, а на внутренний интерфейс установленного в локальной сети шифратора. Наглядно схема включения шифратора в сеть представлена на Рисунке 1. Маршрутизировать трафик — дело маршрутизатора, так что возлагать функции анализа трафика на шифрующие устройства не стоит. Шифратор «знал» только ключи шифрования для конкретных адресов получателей.


Рисунок 1. Схема сети с шифратором.

С внешнего интерфейса шифратора инкапсулированный защищенный трафик направлялся опять-таки на маршрутизатор, на интерфейсе Ethernet которого было задано два IP-адреса: один — соответствовал локальной сети центрального офиса; другой — принадлежал виртуальной сети шифратора и служил для него шлюзом по умолчанию. Далее зашифрованный пакет снова сверялся со списками доступа маршрутизатора, где описываются правила динамической маршрутизации EIGRP, и, согласно им, направлялся в то или иное подразделение компании. Маршрутизатор удаленного офиса имел схожую конфигурацию, но не хранил сложные списки доступа c описанием маршрутизации EIGRP, а все пакеты, в том числе предназначавшиеся для других удаленных площадок, пересылались в центральную сеть. На интерфейсе Ethernet маршрутизатора удаленного офиса также было задано два IP-адреса: один принадлежал локальной сети филиала, а второй — виртуальной сети установленного там шифратора и являлся для шифратора шлюзом по умолчанию.

Внешнему интерфейсу шифратора центрального офиса был назначен IP-адрес 192.168.0.2, внутреннему — 10.0.0.253. Все машины в локальной сети имели адрес из сети 10.0.0.0/24. Для интерфейса Ethernet на маршрутизаторе центрального офиса были определены адреса 10.0.0.1 и 192.168.0.1. На шифраторе в качестве шлюза по умолчанию был задан адрес 192.168.0.1. На всех рабочих станциях центрального офиса в качестве адреса шлюза по умолчанию был указан адрес 10.0.0.1.

Внешнему интерфейсу маршрутизатора удаленного офиса соответствовал IP-адрес 192.168.1.2, а внутреннему — 10.0.1.253; все машины локальной сети удаленного офиса имели адреса из сети 10.0.1.0/24. Интерфейсу Ethernet на маршрутизаторе были назначены адреса 10.0.1.1 и 192.168.1.1. На шифраторе в качестве шлюза по умолчанию был указан адрес 192.168.1.1. На всех рабочих станциях локальной сети удаленного офиса в качестве шлюза по умолчанию был задан адрес 10.0.1.1. В скобках отметим, что приведенные адреса не существуют реально и используются только для иллюстрации схемы.

Предположим, клиент из удаленной сети хочет установить защищенное соединение с сервером из центрального офиса по протоколу telnet. Его рабочая станция имеет IP-адрес 10.0.1.22, а сервер центрального офиса — 10.0.0.44. Таким образом, трафик от удаленного клиента имеет адрес отправителя 10.0.1.22 и адрес получателя 10.0.0.44, порт 23 (telnet). Поскольку шлюзу по умолчанию в удаленном офисе присвоен адрес 10.0.1.1, то все пакеты поступают на маршрутизатор Cisco. На маршрутизаторе настроены списки доступа, где описываются правила условной маршрутизации: в частности, пакеты, предназначающиеся сервису telnet (TCP-порт 23), должны маршрутизироваться не напрямую в центральный офис, а на внутренний интерфейс шифратора.

Пакет от маршрутизатора попадает на указанный интерфейс, затем производится шифрование и инкапсуляция пакета. В результате с внешнего интерфейса шифратора удаленного офиса отсылается пакет с адресом отправителя 192.168.1.2 (внешний интерфейс шифратора удаленного офиса), адресом получателя 192.168.0.2 (внешний интерфейс шифратора центрального офиса), TCP-портом получателя 23. Пакет следует на интерфейс Ethernet маршрутизатора удаленного офиса, где, в соответствии с правилами маршрутизации для сети 192.168.0.0/24, направляется в центральный офис, на маршрутизаторе которого настроен список доступа — согласно ему, пакет с адресом получателя из сети 192.168.0.0/24 передается на внешний интерфейс шифратора (192.168.0.1). Далее он декапсулируется, расшифровывается и с внутреннего интерфейса шифратора центрального офиса попадает в сеть с адресом отправителя 10.0.1.22, адресом получателя 10.0.0.44 и портом получателя 23 (telnet), т. е. с исходными данными. После поступления на маршрутизатор пакет передается далее в соответствии с обычными правилами маршрутизации в локальной сети. В обратном направлении диалог сервера 10.0.0.44 с клиентом 10.0.1.22 происходит в соответствии с аналогичной процедурой, за исключением того, что списки доступа условной маршрутизации создаются на основании TCP-порта отправителя, а не получателя.

ПЛЮСЫ И МИНУСЫ

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

У данного подхода есть еще одно неоспоримое преимущество — это бо’льшая устойчивость сети в целом по сравнению с подключением шифратора на «горло» локальной сети. В частности, протоколы динамической маршрутизации позволяют определить доступность интерфейсов шифратора и автоматически перестроить таблицу маршрутизации в случае выхода из строя одного из интерфейсов либо шифратора в целом. Никакой инкапсуляции проводиться не будет, так что офисы компании станут доступны друг другу по сети. Но подобное решение имеет одну очень неприятную особенность: если администратор не узнает об изменении таблиц маршрутизации, то передаваемый в открытом виде трафик может оказаться скомпрометированным. На такой случай нужно предусмотреть схему оповещения администратора.

Может показаться, что при статической маршрутизации схема параллельного включения шифратора в сеть ничем не отличается от схемы его подключения на «горло» сети, так как связь все равно пропадет, но это не так. Откат конфигурации маршрутизатора (хотя бы даже удаленно) осуществить гораздо проще, чем физически перекоммутировать оборудование на непосредственную маршрутизацию. У такого подхода есть свои плюсы — о защите трафика несложно позаботиться еще до того, как он попадет в среду передачи данных, где может произойти его компрометация.

Мы намеренно не использовали встроенные возможности маршрутизатора Cisco по созданию VPN, так как уверены в следующем:

  1. маршрутизатор должен заниматься только маршрутизацией, а шифрованием - отдельное устройство;
  2. налицо значительная разница в стоимости IOS с поддержкой шифрования и IOS без таковой; кроме того, нельзя не учитывать существующие экспортные/импортные ограничения на криптографическое оборудование и алгоритмы;
  3. алгоритм шифрования DES, характерный для Cisco IOS, не считается устойчивым, и его применение не рекомендуется;
  4. процессор Cisco оптимизирован на выполнение простых логических функций и работу с маршрутизацией; сложные математические операции шифрования создают непропорциональную нагрузку.
УСЛОВНАЯ МАРШРУТИЗАЦИЯ

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

В настройках Cisco рекомендуется отключить IP Redirect на интерфейсах Ethernet посредством команды no ip redirects в конфигурации интерфейса Ethernet, поскольку при создании условного маршрута маршрутизатор с настройками по умолчанию рассылает широковещательное ICMP-сообщение Network Redirect. при его получении машины из подсети меняют статический маршрут для сети, для которой задан условный маршрут Cisco, со шлюза по умолчанию на криптошлюз. Естественно, в ситуации, когда необходимо восстановить изначальную конфигурацию сети (без криптошлюзов), откат не ограничивается восстановлением конфигурации Cisco — помимо этого, изменение маршрутов необходимо произвести вручную на рабочих станциях и серверах защищенной сети.

ДОВЕРЯЙ, НО ПРОВЕРЯЙ

Работа шифраторов контролировалась очень просто: в том же сегменте сети, где был установлен шифратор, была размещена машина под управлением Linux с установленной на ней программой tcpdump. На порту коммутатора, к которому подключен шифратор, была включена функция мониторинга. Трафик дублировался на порт коммутатора, к которому была подключена машина под управлением Linux с программой tcpdump. Сетевой интерфейс машины перевели в режим приема всех пакетов (promiscuous mode). Tcpdump настроили так, чтобы отслеживать только пакеты, у которых адреса источника и получателя принадлежали к виртуальным сетям шифраторов. Таким образом, было видно, что пакеты инкапсулируются, а их содержимое зашифровано.

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

Автор выражает благодарность Мяснянкину Владиславу (hugevlad@yahoo.com) и Карфидову Игорю (karfidoff@rambler.ru), с чьей помощью была развернута вышеописанная сеть VPN.

Павел Покровский — специалист по информационной безопасности. С ним можно связаться по адресу: underling@yandex.ru.

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...