Альтернатива пробросу nx-клиентских шар (а не сделать ли попытку смелую самоотверженную?)

Модераторы: dimbor, Модераторы разделов

dimbor
Ведущий рубрики
Сообщения: 1506
Статус: Подвинутый участник

Альтернатива пробросу nx-клиентских шар

Сообщение dimbor »

Djelf писал(а):
10.04.2011 11:21
dimbor писал(а):
09.04.2011 06:19
От использования nx-овых шар в конторе месяц назад пришлось отказаться.

С обратной стороны тоже как-то не так получается. Но нашел такую штуку http://www.swish-sftp.org
Шикарно! Но нам без напильника, как всегда, обойтись не получится.

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

Цели: Интеграция в nx-клиент реализации надежного совместного использования дисковых ресурсов (клиентских/серверных - пока не вдаемся) на уровне операционных систем - возможность доступа к ресурсам других приложений.

Средства: opennx, freenx, напильник.

Налицо имеем явную недоделанность 3-го nx-а: даже при клиенте на линуксе, шарить приходится по кифс (smb). Нонсенс.
Имеем также рабочий открытый win32 код для использования scp/sftp ресурсов (WinSCP тоже со счетов сбрасывать не надо). Это был плюс.

Djelf писал(а):
10.04.2011 11:21
Думаю, надо nxservice пропатчить, чтобы где то, как то, он читал некий ini и добавлял проброс портов (localhost:ЧтоТоизИНИ>remote:22) в nxssh чтобы Swish заработал.
В принципе уже понятно куда курить, но формат ini и его расположение под вопросом.

У попа была собака, рекурсивная до жути. Он ее любил...

remote:22 - это единственное, что нам вообще видно из оч. удаленного Кукуева на нашем терминальном сервере. Зачем его самого в себя пробрасывать? И даже ssh-сессия уже есть. Другое дело, что она юзера nx с правами чуть больше чем никакими. Использовать ее - надо проковыривать дыру в безопасности сервера, на сервере, мучительно.

А если синхронно со стартом nx-cессии рядом с ней кидать другую от юзера? Средствами клиентского opennx. Код по авторизации там есть - практически копи-паст. Точнее комбинируем с кодом означенных выше продуктов. На сервере не надо править _ничего_.
(Другое дело, что клуб анонимных алко-параноиков негодуе использовать для юзеров ssh по паролю, но это решаемые частности.)
Спасибо сказали:

Djelf
Сообщения: 614
ОС: Гигтег+Цшт32

Re: Альтернатива пробросу nx-клиентских шар

Сообщение Djelf »

WinSCP - много кнопочек. А Swish (пока) не умеет авторизации по ключу, поэтому напрямую как-то не очень хочется. Кроме того папка с документами может находится вообще не на сервере с NX, Вот идея по пробросу порта до менее защищенного сервера ssh и появилась.

Вот еще вариант: LocalSMB.exe отсюда http://www.sshvpn.de/ нашел тут: http://social.technet.microsoft.com/forums...5-f5620882020d/
Устанавливает сервис ApplicationProxy, при этом блокировка проброса 139 и 445 портов не работает! Т.е. ставим Адаптер Microsoft замыкания на себя, устанавливаем ему IP, в свойствах адаптера отключаем все кроме IPv4, пробрасываем 445 и ура... удаленная самба доступна по ip адресу адаптера. Скорость раз в 100 быстрее чем проброс в NX. Но это подойдет только если серверов с которыми надо соединяться не много т.к. на каждый сервер надо заводить свой адаптер.
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1506
Статус: Подвинутый участник

Re: Альтернатива пробросу nx-клиентских шар

Сообщение dimbor »

Djelf писал(а):
11.04.2011 08:50
Вот еще вариант: LocalSMB.exe отсюда http://www.sshvpn.de/ нашел тут: http://social.technet.microsoft.com/forums...5-f5620882020d/
Устанавливает сервис ApplicationProxy, при этом блокировка проброса 139 и 445 портов не работает! Т.е. ставим Адаптер Microsoft замыкания на себя, устанавливаем ему IP, в свойствах адаптера отключаем все кроме IPv4, пробрасываем 445 и ура... удаленная самба доступна по ip адресу адаптера.

Хорошо бы было, но там же только блоб с плеча буржуя, не?

Спасибо сказали:

Djelf
Сообщения: 614
ОС: Гигтег+Цшт32

Re: Альтернатива пробросу nx-клиентских шар

Сообщение Djelf »

dimbor писал(а):
20.04.2011 03:05
Хорошо бы было, но там же только блоб с плеча буржуя, не?

Увы, это так. Другое решение тут: http://alirezabagheri.com/blog/?p=67 но оно неудобное и нестабильное (ssh вырубится - перегружай компьютер).
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1506
Статус: Подвинутый участник

Re: Альтернатива пробросу nx-клиентских шар

Сообщение dimbor »

Те же яйца. Устойчиво кажется (интуиция так и заходится ;)), что решение должно быть универсальным для лин и вин-клиентов, следовательно вражеский кифс надо послать лесом. А не употреблять его с одной стороны, с другой, как извращенцы какие, прости г-ди. Протянуть параллельно и автоматически с сессией юзерский ssh - идеальное решение для лин-клиента. Затраты только на изучение процесса сборки opennx и cpp заодно ;).
По виндой другое дело - блочное трудно совместить с сеансовым (термины самопальные, не бейте). В смысле scp/sftp в диск: так просто не отмапишь. Видел решения только через временный каталог, с файлами, сдунутыми целиком. А если файл мег так 50 окажется? Производительность это... нарастет короче.

Может кто знает больше? Тут прнимаются идеи и советы. За респект и уважуху. Курс выгодный. Ночью дешевле.
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1506
Статус: Подвинутый участник

Re: Альтернатива пробросу nx-клиентских шар

Сообщение dimbor »

Поток сознания девать больше некуда, близкие уже давно шугаются, не говоря о дальних. Осталось только это безответное место, куда можно выплеснуть.

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

Винда же дело другое. Ночным кошмаром с титрами "nxhelper.exe" встает такая картина: При старте первой nx-сессии запускается эта звездопроушина в виндовом трее, умеющая изрыгать из себя меню и что-то запускать. Меню хранится в файле имя_сессии.nxh и состоит из избранных путей на сервере. (этот файл хранит также ключик юзера для авторизации при надобности). По клику на пункте меню запускаем простейший фронтенд к plink+pscp а ля плагин к фару SCP, который позволяет листать драгать и дропать. Код его можно практически полностью попереть из лабораторной работы по MSVC "FTP-клиент" какого-нить честолюбивого студента. Накрайняк и сам наропаю на дельфях часов за несколько.

Вот только подружить даже WinSCP с русскими именами файлов на сервере мне не удалось. Списываю на криворукость.
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1506
Статус: Подвинутый участник

Re: Альтернатива пробросу nx-клиентских шар

Сообщение dimbor »

Охотно верю предыдущему оратору, что по скорости предлагаемый вариант слабоват.
(Это не шиза пробивает - это из поста Djelf с элегантным костылем была рождена отдельная тема. А высказывание о скорости потерлось - разбивать сообщения не умею.)

Возвращаясь к обдумыванию вин-клиента и самбы на сервере, видна похожесть двух вышесосланных вариантов.
В первом случае на сессию заводится отдельный адаптер, прокидывается адаптер:445 - сервер:445. Плюс некая таинственная служба заботится о связи адаптера с подготовленным ssh-клиентом (nxssh.exe).
Во втором более простом случае в винде отключается служба "сервер" и проброс идет локалхост:445 - сервер:445.
И то, и другое криво. Даже с мутной службой можно было бы смириться (винда сама не OSS ни разу), вот только дополнительный адаптер требует дополнительного IP и хорошо бы от него избавиться. Полез в исходники nxssh и узрел, что ему наплевать, какой айпишник на клиентском конце туннеля. Какой задали, такой и будет. А если сделать его внешним адресом сервера (с которым сессия)? Тогда от него будут идти cifs-пакетики, как будто он в локальной сетке. Только туда они идти не будут, т.к. винда будет их кидать на default route, а там их никто не ждет.
А если повесить свою службу, которая будет ловить пакеты на сервер:445 и по наличию живого nxssh перекидывать их в туннель.
Скажите, спецы, собаку съевшие, работоспособна ли такая схема? И как ее правильно назвать. Чет кажется, что изобретается велосипед OpenVPN ;).

А если внезапно это окажется не полным бредом, в какую сторону рыть MSDN для ее реализации?
Спасибо сказали: