Архив форумов ЦИТФорума

[Dmitry_Karpov]

Есть локальная сеть с "серыми" IP-номерами 192.168.*.* и выходом наружу через FreeBSD, на котором работает Apache. Есть юзеры, работающие под Windows.

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

• Выдать "внешние" IP-номера юзерским машинам и наладить роутинг. Очевидно, что такой вариант крайне нежелателен.
  
• Поднять на юзерских машинах Apache и использовать Proxy для проброса запросов внутрь.
  
• Рас'share'ть папки с выставляемыми наружу данными, смонтировать их (ro) на FreeBSD по smbfs и выставить наружу через Apache.

Хотелось бы услышать мнение товарищей, которые решали подобные задачи, о возможных "граблях" с работоспособностью и безопасностью на каждом из путей или рекомендации ещё какого-нибудь способа. В частности, надо учитывать, что поддержание работоспособности софта на юзерских машинах - это лишний геморрой; а есть ещё проблемы в том, что юзерская машина м.б. выключена - как известно, FreeBSD очень не любит когда смонтированный раздел недоступен.

PS: С возмущением обнаружил, что если прописать в /etc/fstab монтирование smbfs-системы при загрузке, стартовые скрипты пытаются сделать это до активизации сетевых интерфейчов - соотвественно, система переходит в single-user mode. Собственно, отсюда мой интерес к amd.
_________________
Хочу в Хогвардс преподавателем информатики.

[and3008]

OpenVPN по моему очень ничего себе впишется в эту задачу.

FreeBSD будет сервером. И в соответствии с политикой пускает избранных внутрь сети. И не абы куда, а только куда надо. Разруливается это все довольно просто.

Недостаток один - на внешнем клиенте надо ставить софт.

[Dmitry_Karpov]

[fLamer]

Так как технические варианты ты сам знаешь, то вопрос тут скорее в политике фирмы, надо выбирать по ситуации.
Ещё один момент,
От кого исходит инициатива расшаривать данные и кому это нужно?
Если это связано с работой фирмы, то предлагаю ещё варианты:
1. поставить перед начальством вопрос о дополнительном дисковом пространстве на шлюзе.
2. купить внутрисетевой файлсервер и мапить внешний инет на него.
Это если внешние пользователи анонимные и разные и vpn для каждого организовать невозможно.
А если сервисом пользуются всего 5 человек своих сотрудников - тогда VPN.
А сколько внешних клиентов?
А данные секретные, шифрование требуется?
А сколько внутренних машин с сервисами?

[!Axel2]

Yeah, you are right man!
_________________
God bless America!

[Dmitry_Karpov]

[C37]

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

[Valera]

Поднять НАТ на FreeBSD и мапить порты на внутренние адреса.
Внутри можно поднять несколько вэбсерверов.

[Dmitry_Karpov]

[sedfom]

Насколько продвинуты пользователи (сами они можут поднять и настроить Apache)?
Кто будет все это настраивать и поддерживать?


Если бы эту задачу решал я:

Поднимается сервер и дисковым массивом достатотчным для всех данных умножить на 3. На нем поднимается FTP. Юзерам раздаются аккаунты на доступ к FTP. IP на сервер я бы поставил серый и настроил маппинг на Фре. У такого решения на мой взляд меньше всего граблей, меньше генороя и поддержкой, ну и меньше самой работы

Не хватит одного сервера можно поднять несколько, тогда лучше раздавать реальные IP.

Примечание:

ХР - не серверная ОС.
_________________
Каков вопрос, таков ответ.

[fLamer]

если каждый сам посебе, да ещё НИИ, типа умными себя считают во всех науках, нельзя мапить снаружи в сеть и делать этот процесс стихийным, надо брать это в свои руки, организовывать заранее определённый механизм расшаривания, ответственных людей! Делать всё централизованно! Что это за гигабайты информации из НИИ?! Это кому это "всем в интернете" нужны гигабайты из НИИ?! Это бред! Это произвол, выделить место на шлюзе каждому, и не гигабайты, а под нужную информацию, я думаю что всётки кто-то за это отвечает и решает оправданные расходы или капризы пользователей.

[Dmitry_Karpov]

[fLamer]

Я думаю что пользовательская машина не сервер, и если уж действительно надо, то выделить сервер хотя бы внутри сети и сделать его доступным снаружи. Сервер в твоих руках и за ним следить проще. Централизовано надо сделать. А на сервер пусть заливают данные свои. А сколько машин внутри сети нуждается в расшаривании данных? И через какую службу расшаривать? http? ftp? как распределять один порт внутри сети по разным машинам?

[Dmitry_Karpov]

[QUOTE=fLamer]как распределять один порт внутри сети по разным машинам?[/QUOTE]
Есть куча способов; собственно, они все исползуются для создания вирт.хостов:

• IP-based (нужно несколько внехних IP-номеров);
  
• Port-based (каждый сайт на собственном порту; используется очень редко);
  
• Name-based (один IP-номер, порт:80, сайты различаются по именам).

Первые два варианта можно сделать средствами NAT или HTTP-Proxy, а третий - только средствами HTTP-Proxy.
_________________
Хочу в Хогвардс преподавателем информатики.

[MiK]

Да, задача необычная хотя цель понятна. Мне понравился этот вариант

[C37]

Хоть убейте, не вижу смысла выставлять наружу данные с участием внутренних машин пользователей. Организация файлового сервера (ftp, http...) на шлюзе, в DMZ или "рядом" имеет несколько очевидных преимуществ:
1. данные доступны постоянно, а не только тогда, когда их владелец уже пришел на работу и включил компьютер;
2. владельцы данных помещают их в открытый доступ более сознательно, чем если бы они просто открывали доступ к некоторой папке на своей машине;
3. данные передаются по внутренней сети только один раз при их размещении на сервере, а не при каждом обращении к ним
4. исключается обращение к незащищенным внутренним машинам извне, пусть даже и опосредованное.

[MiK]

Сам Дмитрий похоже решил проблему или "остыл" уже.

[Dmitry_Karpov]

[C37]

[and3008]

Mik наверно ничего не слышал о системах HP EVA или EMC ClariOn или Hitachi Thunder.

А так же о ПО виртуализации. На таких железках может совершенно успешно сосуществовать СУБД Oracle и файлопомойка с неограниченным кол-вом гигабайт.

[MiK]

and3008 наверно не понял сути задачи, но это ничего - бывает.