Slavik0981, Пусть будет кабельный, это не мешает иметь роутер, но этое важно.
Какой адрес конкретно на вашем компе вы можете посмотреть в свойствах сети в винде (или ipconfig в cmd) или по команде ifconfig в линуксе.
Бэкдоры и трояны держат снаружи свой сервер, а сами трояны являются клиентом, поэтому НАТ проходят без проблем.
Для TCP трафика преодоление NAT реальная проблема.
Для UDP есть вариант использовать промежуточный STUN/TURN/ICE сервер, но это требует их поддержки в программном обеспечении, так что простым этот вариант тоже назвать нельзя, но он вполне реальный.
Ну и вообще в логах ssh на сервере я вижу, что соединение есть, что передана git команда на исполнение, вот она то и валится, причем без каких-то ошибок, предупреждений и т.п.
Например для clone на сервере стартует такая команда: git-upload-pack '<path repo>'
Дальше в том же логе вижу, что команда завершилась с кодом возврата 0x80131506
Кроме того в ходе экспериментов, я много пробовал разных комбинаций URL для удаленного репозитория. Если URL не верный, то операция и не начинается, выдается осмысленное сообщение, о том что адрес удаленного репозитория не верный.
Без покупки белого адреса можно обойтись, если завести сервер в интернете уже с белым адресом, например арендовать VPS.
Когда-то пользовался радмином - там стандартная клиент-серверная архитектура, использует протокол TCP, все проблемы с NAT там так же присутствуют. Возможно в современных версиях они каким-то образом обходят это, например так как это делает teamviewer.
И еще: NAT нужно преодолевать только на одной стороне соединения, на той что принимает соединения, т.е. на сервере. Клиенты свой NAT обычно проходят спокойно.
yanis_kondakov, git push начинает работу, выдаются стандартные в этом случае сообщения, затем все заканчивается
"fatal: The remote end hung up unexpectedly"
При этом на сервере все без изменений.
При клонировании сразу получаю два "fatal: The remote end hung up unexpectedly" и на этом процесс заканчивается.
wscript.exe и cscript.exe - это только обертки для использования WSH из командной строки.
Приложения не обязаны пользоваться этими инструментами. Все объекты WSH реализованы в виде ActiveX объектов и доступны приложению через соответствующий интерфейс напрямую, минуя wscript/cscript.
Epicrush, Если все банки разные, то можно все разрулить таблицей маршрутизации на роутере.
Если банк один и тот же, то похоже придется применять предложенную вами схему.
Включите встроенного локального админа, задайте ему нормальный пароль и ваши батники должны работать так как хочется. Пароль лучше всего задавать отличный от других админских паролей, используемых в сети. Так по крайней мере можно обезопасить сеть от некорректного поведения пользователя.
В целях безопасности на этот комп нужно установить антивирь и возможно настроить политику "разрешенных приложений".
Кстати, если вы пытаетесь таким образом показать банку (или не банку), что это разные юр.лица, не имеющие друг к другу отношения, то стоит подумать еще и о смене МАС адреса. Т.к. МАСи локального компа в логах банковской части клиент-банка фигурируют. Причем часто собираются все имеющиеся МАСи со всех адаптеров, а не только от того по которому идет обмен.
Epicrush, Ваш ответ только породил больше вопросов :)
У вас 1 канал и 29-ая подсеть на 8 адресов от провайдера?
Или 8 каналов по 1 адресу?
8 внешних адресов, надеюсь, у вас не на этой конкретной виндовой машине?
Обычно похожие вопросы решаются настройкой маршрутизации на роутере.
Но что бы конкретно что-то сказать нужно больше информации.
С какой целью нужно переключаться?
Как пользователь будет выбирать какой ему адрес нужен в данный конкретный момент?
Ezhyg, я даже ссылку открыл :-) - удивился, что этот сайт еще жив.
Давно эти утилиты использую, начал еще при живом сисинтерналзе.
А сейчас любой whois покажет, что домен sysinternals.com принадлежит микрософту.
Константин, Да, учетная запись из под которой вы делаете shadow, должна быть админом на удаленном ПК, иначе ни как. Я об этом писал выше.
Обычно, если в сети нет домена, то заводят на каждом ПК пользователя с одним и тем же именем и паролем. Обычно это стандартный Администратор.
Если у вас нет такого, подойдет любой - у вас же нужна shadow только на один комп. Берете от туда юзера с админскими правами, заводите на своем компе такого же и запускаете shadow из-под него.
Константин, И что?
В свое время я юзал не mstsc /shadow, а просто shadow - суть одна и та же, только shadow работала из терминальной сессии, приходилось сначала подключаться к промежуточному терминальному серверу, а оттуда давать shadow.
shadow я мог запускать от любого пользователя, он не обязательно должен быть локальным админом, главное что бы он был удаленным админом.
Я думаю, что mstsc /shadow работает примерно аналогичным образом.
Сейчас я уже не использую этот механизм. Но 2 года назад плотно с ним работал, практически развернул это в сети средней величины на каждом пользовательском компе (в сети АД не было). Так что опыта было более чем достаточно.
Константин, Вы можете на своем ПК завести пользователя, который является администратором на удаленном и запускать shadow из-под него. Админские права вам по любому нужны.
Не помогут. Я привел пример, что без этого ключа при включенном UAC админские шары не работают да же при наличии прав администратора. Так же как не работает и shadow даже при наличии админских прав.
что без прав администратора на удалённом пк не подключиться
У вас проблема завести пользователя с админскими правами на удаленном ПК?
Константин, Вам, видимо, кроме всего прочего нужно еще вот это:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Этот ключ реестра нужно выставить на удаленной машине и перезагрузиться.
Это отключает UAC при логине админом удаленно, т.к. повысить привилегии удаленно нельзя. Напрямую с shadow это не связано, но влияние оказывает. Так же с этим ключем вы сможете использовать админские шары.
Когда сеть с АД, то этот ключ уже выставлен.