17.04.2012 07:26:44

Эраст Костюк

По следам одного из проектов......

Многие из нас помнят время, когда для объединения удаленных офисов было необходимо коммутировать выделенные линии, или прокладывать оптику между площадками, и такие проекты были под силу только нефтяникам и банкам.

Сейчас - с развитием интернета и появлением технологии VPN (Виртуальные частные сети)  - объединить офисы может позволить себе практически любая компания.

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

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

Не вдаваясь в технические детали, я нарисую несколько сценариев такого объединения. От того, какой выбран сценарий, нужно будет выбрать ту или иную технологическую платформу (или так называемые технологические компоненты). Собственно сами эти технологические компоненты останутся за рамками данной статьи.  А вот выбор заказчиком  того или иного сценария позволит более внятно сформулировать задачу и подобрать необходимое оборудование.

Сценарий 1.

У нас есть головной офис, а так же несколько площадок, на которых работает от одного до трех сотрудников. Эти сотрудники работают с некой информационной системой (например 1С торговля), читают электронную почту, а так же работают с документами Word,  Excel.

Другими словами - все ресурсы, необходимые удаленным пользователям, находятся в центральном офисе.  Удаленные площадки являются лишь потребителями этих ресурсов.

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

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

С позиции руководителя мне бы хотелось централизовать всю информацию в головном офисе и не выпускать ее за пределы периметра. Поэтому первые три минуса для меня существенные.

При таком сценарии я бы рекомендовал заказчику установить у себя в головном офисе так называемый терминальный сервер. Некий сервер, на котором одновременно будут работать все удаленно подключаемые сотрудники. Именно на этом сервере будет происходить обработка всех данных. Удаленные сотрудники будут подключаться, работать на терминальном сервере каждый в своем сеансе. А после отключения вся информация останется в центральном офисе.

В этом случае можно организовать работу без канала VPN в принципе.  Канал VPN здесь является не более чем дополнительным средством защиты. При этом не обязательно организовывать постоянно действующий канал VPN. Можно обойтись установлением сеансовых VPN по необходимости, что удешевляет проект.

Сценарий 2.

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

Другими словами - удаленная площадка использует ресурсы головного офиса, а головной офис регулярно использует ресурсы удаленной площадки.

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

Будет ли при этом использоваться решение с терминальным сервером, или прямой доступ к данным, это уже вторично. Решение принимается в зависимости от конкретной ситуации. Но VPN канал как элемент инфраструктуры при таком сценарии - является необходимым элементом.

Сценарий 3.

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

Другими словами - удаленной площадки нет как таковой. Есть удаленные сотрудники, которые используют ресурсы головного офиса, и при этом могут это делать из совершенно произвольных мест.

В этой ситуации, если сотрудники ездят с корпоративными ноутбуками или планшетами, так же можно (а может иногда и нужно) организовать индивидуальные аппаратные или программные VPN каналы к центральному офису.

Но прежде чем это делать необходимо ответить на два вопроса

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

2. Если перечень закрытый, есть ли возможность предоставить доступ к этим ресурсам через WEB интерфейс?

Например, если сотруднику нужна почта - можно применить сервер, позволяющий подключение к нему через WEB интерфейс.  Если это 1С торговля - можно использовать последние версии 1С, имеющие WEB интерфейс. Если это файлы Word и Excel, можно использовать SharePoint.  В этом случае вообще снимается вопрос с применением каких то специальных средств для подключения к головному офису удаленных сотрудников. А так же достигается определенная универсальность, так как работать с WEB интерфейсом можно даже со смартфона.

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

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

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

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

Э.В.Костюк.  Руководитель компании.

каналы связи | удаленные площадки | Объединение офисов | VPN