tim2172, На Вин7 powershell, конечно, есть. Если в вашем конкретном случае его почему то нет, то его можно поставить руками.
По наличию файлов/папок смотрите мой пример.
twiniii, Групповые политики используют стандартные виндовые возможности удаленного управления, которые были отключены этой галкой.
Надо срочно избавляться от пользователей с правами локального админа.
twiniii, Если вы хотите таким образом поиграть в хакера, то спешу огорчить - все другие предложенные варианты требуют админского доступа к консоли удаленного компьютера.
В этом случае ваш вариант - это искать уязвимости с помощью каких-либо инструментов для взлома. Но это уже не для тостера.
На этих клиентах добавьте в таблицу маршрутизации соответствующую запись для сети за микротиком, шлюзом указывайте IP микротика в ВПН.
Например клиент на винде, а сеть за микротиком имеет адрес сети 192.168.1.0/24:
route -p add 192.168.1.0 mask 255.255.255.0 192.168.42.2
Как автоматически это сделать при подключении - х.з., я толком не работал с этим вариантом ВПН. Но можно и статикой сделать - ничего страшного, что подключения может не быть.
semax95, В виндовом клиенте в свойствах IP4 в свойствах подключения зарыта галка, что-то типа "Использовать как маршрут по умолчанию" (в английской винде она называется "Use default gateway on remote network"). Она по умолчанию включена и при подключении весь трафик направляется на ВПН сервер (т.е. обычный шлюз по умолчанию заменяется адресом ВПН сервера). Если ее выключить этого не происходит и маршрутизация идет обычным образом, т.е. интернет трафик пойдет через свой маршрутизатор, а через ВПН пойдет только трафик для подсети ВПН.
Подозреваю, что и в настройках клиента на микротике есть похожая настройка.
Не написали главного - какой вариант ВПНа используете.
В OpenVPN это рулится настройками ВПН сервера, можно для каждого клиента сделать отдельные настройки.
dom1n1k, Поэтому такой точности, обычно и не требуется. Сомневаюсь, что стандартные библиотечные функции Си выдают точность в 15 десятичных знаков.
Если нужна большая точность, то, видимо, нужно использовать другие типы данных, не double. Возможно библиотеки для больших чисел и т.п.
А так можно было? Там не должно быть какие-то файлы и т.д.?
Можно и нужно. Быть ее не должно - это вообще из линукса пришло вместе с гитом и ssh, так что хорошо что хоть как-то работает на винде :)
В .ssh вы должны сгенерировать файлы ключей для ssh доступа. Смотрите любую инструкцию о подключении гит к удаленному серверу (любому) по ssh.
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 обычно проходят спокойно.
По наличию файлов/папок смотрите мой пример.