информационный обмен с удаленными филиалами по FTP

редакционное предисловие

Кто-то из «стрелянных волков» IT, начав читать статью, воскликнет: «О, боже мой, какой наив! Мы тут циски килограммами закупаем, тянем волокно, оракл там всякий... А вы нам – детский лепет на лужайке: диалап, FTP...»

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

Опытные – и честные – админы всегда придерживаются правила: наилучшее решение проблемы – оно же самое простое решение. А коли бесплатное или малобюджетное – так лучше вдвойне.
И вот еще что. Некоторые вещи в статье, возможно, разжеваны сверх всякой меры. Сначала мы думали это подсократить, но передумали – в таком виде статья будет полезна и начинающим админам в зарождающихся IT-хозяйствах, и как раз для них предложенное решение особенно актуально.

вступление

В нашей стране /* для наших заграничных читателей поясняю, что здесь и далее под нашей страной подразумевается Республика Беларусь – прим. ред. */ все больше организаций выстраивают филиальные и дилерские сети, открывают региональные представительства. Чтобы успешно вести бизнес в современных условиях, своевременно готовить финансовую отчетность и, в конечном счете, побеждать в конкурентной борьбе, важно построить надежную систему информационного обмена. Это значит, что головной офис и филиалы должны быть объединены в единую корпоративную вычислительную сеть. Построение такой сети требует серьезного планирования. Необходимо определиться с регламентом обмена информацией. Требуется ли обеспечить постоянное подключение филиала к вычислительной сети головного офиса или достаточно реализовать сеансовый обмен файлами? От ответа на этот вопрос во многом зависит выбор программного обеспечения и технических средств, используемых для реализации проекта.

варианты

Несмотря на очевидный прогресс в области телекоммуникаций, реализация первого варианта (постоянное подключение) для удаленного региона может быть сопряжена с большими трудностями технического плана (технологии xDSL пока что еще в диковинку за пределами столицы и областных центров, а качество и стоимость беспроводной связи, предлагаемой сотовыми операторами, оставляют желать лучшего) и дорога в финансовом отношении (как на этапе внедрения, так и в процессе эксплуатации).
Этот вариант не предполагает большого выбора в использовании сетевых протоколов, так как, скорее всего СУБД будет работать поверх одного из широко распространенных протоколов транспортного уровня — TCP/IP или IPX.

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

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

В свое время широкое распространение получил протокол Z-modem, который, как следует из его названия, предназначен для работы на коммутируемых каналах связи посредством модемного соединения. Его очевидным преимуществом перед протоколами того же класса (X-modem, Y-modem) является возможность продолжения пересылки файла после восстановления разорванного соединения. Таким образом, файл удастся передать даже при самой плохой связи, пусть и за несколько сеансов. Для передачи файлов по протоколу Z-modem существуют программы как для DOS (например, пакет Telemax из Norton Commander), так и для Windows (например, HyperTerminal).

Однако лучшим подходом представляется использование современных стандартных протоколов обмена информацией. Дело в том, что между двумя точками (филиалом и головным офисом) можно установить модемное соединение на основе протокола канального уровня PPP (Point-to-Point Protocol), поверх которого пустить пакеты TCP/IP. Такая схема хорошо отработана на различных платформах (Windows/Unix/Linux) и дает возможность использовать широко распространенные протоколы прикладного уровня — FTP, SMTP/POP3 и даже HTTP. Собственно, становятся доступными все возможности, которые можно увидеть в Интернет. Корпоративная сеть, построенная на базе транспортного протокола TCP/IP, называется «интранет» — внутренняя сеть (в отличие от «Интернет» — глобальная сеть).

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

Все дальнейшие рассуждения будут строиться в предположении, что в качестве транспорта будет использован протокол TCP/IP. Какой же протокол передачи файлов предпочесть? Рассмотрим два уже упомянутых типа протоколов, подходящих для наших целей: SMTP/POP3 и FTP.

Протоколы SMTP/POP3 получили широкое распространение благодаря системе электронной почты Интернет. Для их использования необходимо организовать почтовый сервер, то есть установить на один из компьютеров вычислительной сети специальное программное обеспечение, которое позволяет принимать сообщения и, в зависимости от указанного в них адреса получателя, либо переправлять на другие почтовые серверы, либо сохранять их до обращения за ними адресата. Для обмена сообщениями с почтовыми серверами используются программы-клиенты. Они дают возможность пользователю подготовить письмо, отправить его с помощью протокола SMTP на почтовый сервер, а также проверить наличие на почтовом сервере корреспонденции, адресованной пользователю, получить ее по протоколу POP3 и предоставить для просмотра.

Как следует из описания схемы работы электронной почты, ее использование для передачи файлов является не самым удобным вариантом. Сервис электронной почты SMTP/POP3 изначально предназначался для обмена электронными письмами, а понятие письма включает в себя файл лишь как составную часть, что предъявляет к программному обеспечению требования по формированию конверта сообщения, прикреплению к нему файлов и совершению других, не всегда оправданных действий. Можно отметить его преимущества при необходимости построить систему передачи информации между группой равноправных абонентов электронной почты, однако в ситуации, когда информационный обмен должен осуществляться между двумя точками по схеме «филиал — головной офис», предлагаемые этим сервисом возможности не всегда окажутся востребованными, а его реализация — излишне трудоемкой.

FTP

Другую картину можно наблюдать при использовании протокола передачи файлов FTP. Так же, как и протоколы электронной почты, он завоевал популярность в сети Интернет, и точно так же, как SMTP/POP3, этот протокол является «клиент-серверным». Это означает, что в вычислительной сети один из компьютеров должен выполнять роль файлового сервера, доступ к которому может осуществляться по протоколу FTP.

Как отмечено в документе RFC959, к разработке протокола FTP подвигли четыре основные необходимости:
а) организация доступа к файлам (программам и данным);
б) содействие косвенному (посредством программ) использованию удаленных компьютеров;
в) сокрытие от пользователя специфики и структуры устройств хранения информации;
г) обеспечение надежной и рациональной передачи данных.
В случае, когда требуется организовать систему обмена информацией посредством отдельных файлов, с учетом сказанного выше использование протокола FTP представляется наилучшим решением.

решение

На этом вводную часть статьи можно считать завершенной, пришло время рассмотреть порядок построения реальной файлообменной системы на основе транспортного протокола TCP/IP и протокола прикладного уровня FTP.

В первую очередь необходимо установить между головным офисом и филиалом канал связи на основе протокола PPP. Для этого в головном офисе должен быть выделен компьютер с подключенным модемом (на первом этапе; в дальнейшем, по мере нарастания потребностей в скорости и качестве связи модем может быть заменен более совершенным оборудованием). То, как строится PPP-сервер на базе операционных систем Linux или Unix, описано во многих руководствах HOW-TO и FAQ, а в случае Windows NT/2000 достаточно настроить «Входящее подключение» с помощью соответствующего «мастера» (как это сделать, можно посмотреть в справочной системе).

После настройки PPP-сервера и проверки его работы (путем установления соединения с сервером с другого компьютера, оснащенного модемом) самое время заняться установкой FTP-сервера.

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

Так же, как PPP-сервер, FTP-сервер может быть установлен и настроен на базе различных операционных систем, и физически может размещаться на том же самом компьютере, что и PPP-сервер. В случае Linux часто имеется возможность получить настроенный FTP-сервер сразу после установки дистрибутива. Для Windows ситуация несколько иная, но тут существует несколько путей. Первый — использовать FTP-сервер Microsoft из пакета ISS (Internet Information Server) для Windows NT/2000. Второй — обратить внимание на программное обеспечение сторонних разработчиков. Анализ FTP- серверов, распространенных в Интернет, показал, что существует две категории таковых: анонимные FTP-серверы и FTP-серверы с авторизацией пользователя. В чем их различия?

К анонимным FTP-серверам имеют доступ любые пользователи вычислительной сети, к которой принадлежит сервер. Этот тип серверов хорошо подходит для набирающих популярность домашних сетей с целью организации общедоступного файлового архива — дистрибутивов программного обеспечения, музыки, фильмов... Для целей же обмена коммерческой информацией такой сервер абсолютно непригоден, так как не обеспечивает элементарных требований к безопасности /* в большей степени эта проблема затрагивает, конечно, обмен информацией через Интернет, в изолированном интранете в любом случае есть дополнительные схемы авторизиации, в том же PPP – прим. ред. */.

Напротив, FTP-серверы с авторизацией пользователей способны обеспечить дифференцированный доступ различных пользователей вычислительной сети к ресурсам своей файловой системы в соответствии с правами, назначенными им администратором сервера. Как правило, при подключении к такому FTP- серверу пользователь должен указать свое имя и подтвердить правомочность его использования вводом пароля. /* Для новичков в этом деле стоит пояснить, что все FTP-серверы с авторизацией могут работать и в анонимном режиме – прим. ред. */

Если вы решили строить сервер под Windows, обратим наше внимание на FTP-сервер фирмы Extra Systems — ESFTP. Найти сам сервер, познакомиться с его описанием, примерами конфигурационных файлов и рекомендациями разработчиков можно на сайте www.esftp.org.ru. Попутно заметим, что продукт этот работает под всеми 32-битными операционными системами семейства Windows и является бесплатным как для личного, так и для коммерческого использования, что выгодно отличает его от аналогичных предложений, которые можно встретить в глобальной сети. /* Справедливости ради следует отметить, что аналогичными достоинствами обладает по крайней мере один из известных мне FTP-серверов под Windows - War FTP Daemon, сокращенно warftpd – прим. ред. */ Кроме того, вызывает уважение размер: сервер поставляется в одном EXE-файле объемом всего 38400 байт!

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

Второй конфигурационный файл содержит учетные записи пользователей FTP-сервера. Спектр настроек, а это - имя пользователя и пароль, путь к базовому каталогу и определение прав «чтение/запись» - является необходимым и достаточным для реализации той схемы информационного обмена, о которой идет речь в статье. Действительно, на FTP-сервере головного офиса можно для каждого филиала выделить свой каталог, причем каждый филиал будет иметь доступ только к файлам своего каталога.

Далее в статье будет подразумеваться использование именно Extra Systems FTP сервера, хотя читателю ничто не мешает использовать любой из доступных ему продуктов. Отвлекаясь, можно отметить, что Extra Systems предлагает широкий спектр бесплатного программного обеспечения для организации серверов в Интер- или интранет. Например, заслуживает внимания почтовый POP3/SMTP-сервер, способный удовлетворить потребности небольшой организации в построении внутренней почтовой системы с возможностью выхода в Интернет.

После конфигурирования, установки и запуска проверим работоспособность нашего сервера, например, так:

C:\>ftp 127.0.0.1

Если ответом будет сообщение:

->ftp: connect:В соединении отказано

значит, что-то работает не так, как нужно. В этом случае нужно остановить службу «Extra System FTP server», убрать конфигурационный файл ESFTP.INI из каталога Windows и запустить сервер снова — базовый конфигурационный файл будет создан автоматически, после запуска сервера в работу его можно будет подкорректировать.

Если же все настройки выполнены верно, то в ответ будет получено приглашение:

Связь с 127.0.0.1.
220 Extra Systems FTP Server 3.05 Ready
Пользователь (127.0.0.1:(none)):


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

После того, как PPP- и FTP-серверы настроены, запущены и проверена их работоспособность, можно приступать к заключительному этапу построения системы информационного обмена — выбору FTP-клиента, посредством которого пользователь филиала будет общаться с сервером.

Сказать, что FTP-клиентов существует множество — это не сказать ничего. В Интернет можно найти массу программ, распространяемых под различными лицензиями, занимающих различный объем и отличающихся набором функциональных возможностей — от аналогов уже затронутой стандартной утилиты «ftp» до роботов, автоматически опрашивающих FTP-сервер по расписанию и выполняющих файловый обмен по заданному сценарию. Если необходимость в какой- то особенной функциональности отсутствует, кажется вполне сбалансированным решение использовать FTP-клиенты, встроенные в файловые менеджеры Windows (Total) Commander или FAR Manager. С помощью этих программ сотрудник филиала без особых проблем сможет работать с каталогом на FTP- сервере точно так же, как с каталогами на локальных дисках.

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

Сначала решим задачу отправки файлов из филиала на сервер головного офиса. Предположим, что все отчеты филиала к моменту отправки упаковываются в архив FILIAL.ZIP, который размещается в локальном каталоге, назовем его, скажем, C:\OUT. Как передать этот архив на FTP-сервер, в подкаталог IN-каталога, доступного для филиала через FTP?

Во-первых, нужно установить модемное соединение с сервером головного офиса по протоколу PPP, организовав таким образом канал для работы протоколов более высокого уровня, в том числе TCP/IP и FTP. Во-вторых, используя этот канал, нужно подключиться к FTP-серверу, пройти процедуру авторизации и отправить необходимый файл на сервер. В-третьих, нужно завершить работу с FTP-сервером и отключить удаленное соединение, установленное на первом шаге.

Каким же образом можно установить удаленное соединение? Существует два часто применяемых способа. Первый предполагает настройку удаленного доступа таким образом, чтобы соединение устанавливалось автоматически, как только какая-нибудь программа запросит доступ к удаленному ресурсу. Однако при этом всегда устанавливается одно и то же «соединение по умолчанию», что может оказаться неприемлемым в ситуации, когда помимо подключения к корпоративной сети филиал имеет необходимость доступа к сети Интернет – с этого же компьютера, через этот же модем. Второй способ заключается в создании ярлыка для удаленного соединения и размещении его на рабочем столе Windows. Необходимое соединение в этом случае устанавливается щелчком по соответствующему ярлыку. Этот способ универсальнее, однако мало того, что пользователю нужно вручную устанавливать соединение, он еще должен помнить о необходимость его завершения после выполнения сеанса обмена файлами.

К счастью, существует еще один способ, лишенный недостатков предыдущих. Он заключается в использовании для управления удаленными соединениями специальной утилиты RASDIAL, которая входит в дистрибутивы Windows NT/2000/XP. Эта утилита позволяет устанавливать требуемое удаленное соединение по его наименованию, задавать имя пользователя и пароль для подключения к удаленному серверу, а также завершать удаленное соединение, когда в нем больше нет необходимости.
Как же быть пользователям Windows 95/98/Me, ведь в этих версиях такая утилита отсутствует? Они могут воспользоваться программой RASDw9x (iharsw.at.tut.by), которая разработана автором этой статьи и работает под всеми 32-битными версиями Windows.

Допустим, что в филиале настроено удаленное соединение «Office» для доступа к серверу головного офиса под именем «Filial_1» и паролем «Slonim». /* Отличный пароль, черт возьми ;) – прим. ред. */ Тогда для подключения из-под Windows NT/2000/XP нужно набрать в командной строке:

C:\>rasdial Office Filial_1 Slonim

или при использовании программы RASDw9x:

C:\>rasdw9x connect Office /u:Filial /p:Slonim

Чтобы завершить соединение, нужно для Windows NT/2000/XP дать команду:

C:\>rasdial Office /DISCONNECT

или в случае RASDw9x:

C:\>rasdw9x disconnect Office

либо

C:\>rasdw9x disconnect *

Читатель может поинтересоваться, неужели набирать команды с клавиатуры проще, чем щелкнуть по значку на рабочем столе? Конечно же нет. Сейчас самое время вспомнить, что для выполнения часто повторяющихся действий в Windows традиционно используется язык сценариев, команды которого записываются в пакетных файлах BAT и CMD. И для того, чтобы написать такой командный файл для автоматизации выполнения пересылки файла, осталось сделать последний шаг — описать в терминах команд операционной системы механизм отправки файла по протоколу FTP.

Ранее в этой статье уже упоминалась стандартная команда-утилита Windows ftp, реализующая функции FTP-клиента. В интерактивном режиме она уступает своим собратьям, оснащенным графическим пользовательским интерфейсом, и пригодна разве что для тестирования FTP-сервера, как это было описано выше. Однако у нее есть очень важная малоизвестная «изюминка»: она способна в пакетном режиме выполнять FTP-команды, записанные в текстовом файле.

Запишем последовательность команд, которые нужно вводить в процессе диалога с программой ftp, в текстовый файл UPLOAD.FTP (комментарии набирать, само собой разумеется, не нужно ;):

Filial_1 (имя пользователя)
Slonim (пароль)
lcd C:\OUT (каталог, откуда отправлять)
cd IN (каталог, куда отправлять)
put FILIAL.ZIP (отправить файл)
bye (завершить ftp-соединение)


Чтобы командный процессор ftp выполнил эту последовательность команд, нужно в командной строке набрать:

C:\>ftp –s:UPLOAD.FTP 192.168.1.15

где 192.168.1.15 — IP-адрес FTP-сервера (предполагается, что соединение с сервером на этом этапе уже установлено). Если все сделано правильно, на экране пробегут ответы FTP-сервера, а файл будет записан по назначению. Если же что-то пойдет не так, как планировалось, придется заняться отладкой сценария. Помочь в этом деле может запись протокола обмена с сервером в журнальный файл, например, так:

C:\>ftp –s:UPLOAD.FTP 192.168.1.15 >UPLOAD.LOG

Отладку удобнее производить на самом FTP-сервере.
После того, как FTP-сценарий записан, отлажен и проверен, можно собрать все описанные выше команды в единый пакетный файл UPLOAD.BAT. Вот что, приблизительно (плюс-минус комментарии и служебный вывод на экран) должно получиться:

@echo off

rem
rem 1. Подключение к вычислительной сети головного
rem офиса по протоколу PPP.
rem

rasdw9x connect Office /u:Filial_1 /p:Slonim

if ErrorLevel 1 goto DIAL_ERROR

rem
rem 2. Отправка файла FILIAL.ZIP из локального
rem каталога C:\OUT в каталог IN на FTP-сервере.
rem

ftp –s:UPLOAD.FTP 192.168.1.15

rem
rem 3. Завершение удаленного подключения
rem к PPP-серверу.
rem

rasdw9x disconnect Office

echo Файл FILIAL.ZIP отправлен в головной офис
goto EXIT

rem
rem 4. Сообщение об ошибке подключения
rem к PPP-серверу.
rem
:DIAL_ERROR
echo ОШИБКА:
echo не удалось подключиться к сети головного офиса!
:EXIT


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

Полдела сделано. Осталось написать аналогичный сценарий DOWNLOAD.BAT для получения файлов из головного офиса (пусть файл OFFICE.ZIP находится в каталоге OUT на FTP-сервере, а записать его нужно в каталог C:\IN на филиале). А для этого достаточно только подготовить сценарий обмена с FTP- сервером DOWNLOAD.FTP:

Filial_1 (имя пользователя)
Slonim (пароль)
lcd C:\IN (каталог, откуда принимать)
cd OUT (каталог, куда принимать)
get OFFICE.ZIP (принять файл)
bye (завершить ftp-соединение)


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

заключение

Таким образом, получилась система информационного обмена «Головной офис — филиал», вполне пригодная для передачи файлов. Оглядываясь на выполненную работу, заметим, что при построении системы были использованы только стандартные возможности операционной системы Windows и свободно распространяемое бесплатное программное обеспечение.

Отметим еще один важный момент. По тексту статьи автор ненавязчиво напоминал читателю о месте используемых компонентов в сетевой модели OSI: модем – для организации физического канала передачи данных, PPP – протокол канального уровня, TCP/IP – протокол транспортного уровня, FTP – протокол прикладного уровня. Сейчас самое время объяснить, какое это имеет значение. Дело в том, что построенная система, какой бы простой она не казалась, использует в качестве своих кирпичиков стандартные компоненты, которые, возникни в том необходимость, с минимальными затратами и усилиями могут быть заменены более совершенными.

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



Игорь Орещенков.


Сетевые решения. Статья была опубликована в номере 07 за 2005 год в рубрике sysadmin

©1999-2024 Сетевые решения