res2001

На сервере какая сборка гита у вас стоит? Есть варианты и могут быть нюансы при задании урла.

Попробуйте варианты:
ssh://user@server/d/git/repo.git
ssh://user@server:/d/git/repo.git
ssh://user@server:d/git/repo.git
ssh://user@server/d:/git/repo.git
По формату URL тут подробней.

У меня на гит на сервере из состава msys2 работает первый вариант URL.
На сколько помню на "Git for Windows" работает последний.

Кстати, я не так давно настраивал гит сервер на винде. По ssh так и не получилось завести - любая операция заканчивалась ошибкой. Грешу на плохой канал - сервер у черта на куличках, да еще и через ВПН, скорость не фантан, задержка при передаче приличная. Но сам ВПН работал, ssh то же, а гит отказывался. Пришлось поднять на сервере git-daemon и работать через протокол git, а не ssh.

Нужно настроить сервер ssh, чтоб гит мог подключаться к репозиторию по ssh.

Кроме не рассматриваемого варианта эта ошибка может быть вызвана следующими причинами:
1.удаленному пользователю на сервере не назначен пароль;
2.пользователь не является администратором или пользователь не входит в группу "Пользователи удаленных рабочих столов".

Вообще странно, что пришлось выключить "Network Level Authentication". Вариант с выключением этой настройки предназначен для старых клиентов под WinXP. В Вин10 клиент точно это поддерживает (собственно в Вин7 уже это работало).

Возможно корпоративный прокси с прозрачной авторизацией через АД.

1.Часто браузер для одного сайта открывает не одно соединение, а сразу пачку и качает ресурсы параллельно. Порты в этом случае для каждого соединения разные. Кроме того на одной странице могут быть ссылки ведущие на разные сайты, для них браузер открывает новые соединения.
2.Как было сказано порт выбирает ОС. При открытии сокета браузер указывает, что нужен "любой локальный порт". Считайте, что ОС выбирает первый свободный порт из динамического диапазона. На самом деле сложнее, конечно, но конкретный алгоритм обычно не важен.
3.В общем случае шлюз с NAT подменяет и адрес и порт, поэтому сервер увидит не адрес и порт отправителя, а адрес и порт шлюза. Все это происходит прозрачно для сервера и для клиента. Клиент думает, что он общается на прямую с сервером, а сервер думает, что клиент - это шлюз с NAT и не подозревает, что по пути пакета реальный адрес/порт клиента был подменен NATом.

По IP теоретически можно, но в типичной ситуации это, обычно, будет стоить дорого и спеца, который это сделает, еще нужно поискать.
Есть более дешевые способы в offline.

Если известен e-mail или аккаунт в соц.сетях и т.п. - то уже можно попытаться развести пользователя на установку трояна, который тебе откроет ворота в компьютер. Этот вариант более реальный, обычно так все и происходит. Но от него так же достаточно просто защититься - не разводиться, не ходить по левым ссылкам, не устанавливать левый софт, включить UAC, работать без прав администратора, установить антивирус...
Если комп используется для работы с финансами или другой чувствительной информацией, то с него вообще нельзя ходить "на лево", только на ограниченный разрешенный список сайтов/хостов в интернете. Этот список нужно явно прописать в фаерволе, остальное нещадно блокировать.

Т.к. нет возможности все ПО настроить на хождение через прокси, то вместо него нужно использовать ВПН. Вариант с ВПН не зависит от поддержки ПО, он работает на более низком уровне. Нужен вариант ВПН, который бы поддерживался всеми платформами на которых вы работаете, например OpenVPN.
В остальном схему вы правильно описали.
Было бы удобнее арендовать для ВПН сервера VPS/VDS. В этом случае на ВПН сервере нужно будет поднимать NAT, но это не является проблемой.

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

Используйте не ВПН, а прокси. В прокси нет шифрования, поэтому гораздо выше пропускная способность.

Только подозрение?
Нужно убедится точнее.
Если на линуксе, то посмотрите в top что грузит проц, если винда - менеджер задач.
Естественно есть инструменты для профилирования БД, только нужно знать какой сервер БД вы используете - для каждого свой инструмент.

Дайте доступ учетной записи пользователя, а не компьютера.

Если кабель в стене состоит из 4 пар и 1 пара вышла из строя, то можно, понизив скорость до 100Мб/с жить и на оставшихся парах. Главное выяснить какие конкретно провода не работают и исключить их из работы, а остальные развести вместо не работающих.
Я бы разобрал розетку в кабинете, закоротил попарно все пары, на другом конце кабеля обычным тестером выясняем какие пары работают, какие нет. Находим 4 работающих провода и разводим их для Ethernet 100BASE, не используемые по стандарту провода не разводим (цветовая маркировка проводов, конечно будет не та, что в 568A/B, но прохождение электрического сигнала от цвета провода не зависит).

Ходите в локальной сети на прямую на 192.168.0.2. Зачем вам эти извраты во внутренней сети?

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

Маршрутизация в винде обычно включена по умолчанию, если в компе 2 и более сетевых карты.
За ее включение/отключение отвечает параметр в реестре: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter
Если установлено в 1, то маршрутизация включена, 0 - выключена.
После изменения параметра нужно перезагрузиться.
После этого можно отключить фаервол и проверить. Потом включить фаервол, если нужно открыть порты.

Переносить ради переноса не стоит.
Если уж соберетесь переносить, то лучше не NAS, а SAN, отдайте том по iSCSI.