Я работаю в организации с (излишне) строгими требованиями безопасности. В прошлом году мы установили сервер SVN на облачной машине. Требования к этой машине диктовали, что единственным одобренным методом доступа была двухфакторная аутентификация через токен RSA.
Это означало, что мы не могли использовать svn + ssh: //, потому что разработчикам приходилось использовать свои неудобные токены RSA для каждого отдельного действия SVN. Но мы также не могли наивно использовать svn: //, потому что (не дай бог) люди могли получить доступ к данным на сервере SVN без использования двухфакторного токена.
В итоге мы разработали сложную систему экспедирования портов. Сервер имел типичный svnserve процесс-демон прослушивает соединения на 3690, но брандмауэр заблокировал все подключения к этому порту, кроме localhost. Если пользователь не находится в центре, он должен сначала подключиться к сети через VPN. Пользователь должен создать SSH-туннель к серверу и перенаправить порт (скажем) 6789 на порт 3690 (порт SVN) на сервере (другими словами, ssh user@server -L 6789:localhost:3690). Пока сеанс SSH оставался открытым, пользователь мог использовать обычные URL-адреса svn, ссылаясь на этот порт: например, svn://localhost:6789/path/to/repository/trunk.
Это работало около года как для систем * nix, так и для Windows (с PuTTY и TortoiseSVN). Теперь у нас возникла проблема с новым членом команды, который использует Windows / TortoiseSVN. Она может подключиться к VPN и начать сеанс SSH с переадресацией портов, но когда она действительно идет, чтобы что-то проверить (см. Пример пути выше), она получает следующее сообщение: «Сетевое соединение неожиданно закрыто». Сеанс PuTTY не отображает никаких сообщений об ошибках и не завершается, поэтому я не уверен, что это ошибка сервера. И я независимо проверил способность ее машины слушать себя через порт 6789.
Я не уверен, какой компонент системы здесь виноват: TortoiseSVN, PuTTY, настройки брандмауэра ее компьютера, настройки брандмауэра ее сети, настройки брандмауэра нашего сервера или процесс svnserve. Я подозреваю, что дело в настройках ее брандмауэра, потому что это единственное, что у нее отличается от всех остальных. Но как брандмауэр может предотвратить трафик через туннель с перенаправлением портов SSH? Кажется, что все это проходит через порт 22, поэтому он должен пройти, если SSH-соединение может быть успешно установлено в первую очередь. Я в тупике.
Так: