Назад | Перейти на главную страницу

Tortoise SVN: время ожидания начального подключения

У меня проблема при подключении Tortoise SVN к моему серверу SVN. Похоже, что при первом подключении истекло время ожидания (SVN зависает около 20 секунд), а вторая (автоматическая) попытка срабатывает мгновенно. Т.е. каждое обновление, фиксация, журнал занимает очень много времени и сводит всех с ума ...

То же действие SVN из клиента командной строки Linux работает мгновенно. Доступ через веб-браузер также работает без задержек.

Настройка SVN выглядит следующим образом: Сервер SVN работает под управлением CentOS 7, Apache 2.4.6 и mod_dav_svn 1.7.14. Настроен доступ по SSL. Аутентификация выполняется через LDAP на Windows Server 2012 R2. Клиент (Windows 7 x64) работает под управлением Tortoise 1.7.15 (x64).

Это соответствующая конфигурация Apache (запутанная ...):

# Reduce LDAP cache to 30 seconds
LDAPCacheTTL 30 
LDAPOpCacheTTL 30

<Location /svn>
  DAV svn
  SVNParentPath /var/svnrepo
  SVNListParentPath on
  AuthName "My Repository"
  AuthType basic
  AuthBasicProvider ldap
  AuthLDAPURL "ldap://dc.mydomain.local/OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local?sAMAccountName?sub?(objectClass=*)" NONE

  AuthLDAPBindDN "CN=ServiceUser,OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local"
  AuthLDAPBindPassword "VERYSECRETPASSWORD"

  # Require ldap group via Microsoft rule "LDAP_MATCHING_RULE_IN_CHAIN"
  Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local
</Location>

Журнал Apache (ssl_error_log) начинается следующим образом при запуске активности SVN:

[Wed Aug 26 07:48:14.560025 2015] [ssl:info] [pid 2310] [client 192.168.1.155:49316] AH01964: Connection to child 0 established (server svnserver.mydomain.local:443)
[Wed Aug 26 07:48:14.560563 2015] [ssl:debug] [pid 2310] ssl_engine_kernel.c(1878): [client 192.168.1.155:49316] AH02043: SSL virtual host for servername svnserver.mydomain.local found

Теперь кажется, что SVN завис (метка времени на секунде 14) - Apache убьет соединение немного позже, когда включен модуль reqtimeout (я отключил его в этом сценарии). Примерно через 20 секунд (метка времени на секунде 36) активность продолжается:

[Wed Aug 26 07:48:36.102214 2015] [ssl:debug] [pid 2310] ssl_engine_kernel.c(224): [client 192.168.1.155:49316] AH02034: Subsequent (No.2) HTTPS request received for child 0 (server svnserver.mydomain.local:443)
[Wed Aug 26 07:48:36.102267 2015] [authz_core:debug] [pid 2310] mod_authz_core.c(809): [client 192.168.1.155:49316] AH01626: authorization result of Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local: denied (no authenticated user yet)
[Wed Aug 26 07:48:36.102275 2015] [authz_core:debug] [pid 2310] mod_authz_core.c(809): [client 192.168.1.155:49316] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Wed Aug 26 07:48:36.102334 2015] [authnz_ldap:debug] [pid 2310] mod_authnz_ldap.c(501): [client 192.168.1.155:49316] AH01691: auth_ldap authenticate: using URL ldap://dc.mydomain.local/OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local?sAMAccountName?sub?(objectClass=*)
[Wed Aug 26 07:48:36.147960 2015] [ldap:debug] [pid 2310] util_ldap.c(372): AH01278: LDAP: Setting referrals to On.
[Wed Aug 26 07:48:36.154921 2015] [authnz_ldap:debug] [pid 2310] mod_authnz_ldap.c(593): [client 192.168.1.155:49316] AH01697: auth_ldap authenticate: accepting john.doe

Ssl_access_log и ssl_request_log запускаются со второй 36, ничего не регистрируется со второй 14

На мой взгляд, Tortoise SVN запускает соединение либо без учетных данных, либо без использования https (?), Что приводит к таймауту. Второе соединение, похоже, использует https, но с неправильными учетными данными, и, наконец, Tortoise подключается с использованием правильных учетных данных, и аутентификация проходит успешно.

Любые идеи? Что происходит между 14 и 36 секундами и как этого избежать? ;-)

Спасибо, Флориан

Обновить: Я нашел решение (хотя я не совсем уверен, в чем причина ...): каждый раз, когда я запускаю Tortoise SVN (или клиент командной строки Windows svn), я заметил активность на брандмауэре: контроллер домена пытался связаться с несколькими серверы, например c.root-servers.net, которые кажутся серверами VERISIGN для проверки сертификата SSL или поиска новых корневых сертификатов и т. д. (?). Это было заблокировано брандмауэром, поэтому DC не торопился просмотреть список альтернативных серверов.

Мы используем самозаверяющие сертификаты, поэтому моей первой попыткой было внедрить наш сертификат CA в систему управления сертификатами Windows через групповую политику. Это сработало (по крайней мере, SVN не жаловался на неизвестный CA после удаления всей информации аутентификации). Тем не менее, 20-секундная задержка все еще существует (и DC все еще пытается связаться с Verisign).

В конце концов я попробовал локальную опцию конфигурации SVN "ssl-Author-files", чтобы статически передать сертификат CA и вуаля: задержка исчезла!

Т.е. это приводит к задержке в 20 секунд:

svn list myrepo

и это не

svn list --config-option servers:global:ssl-authority-files=C:\temp\mycertificate.crt myrepo

Все еще немного грустно, что этот обходной путь требует настройки на каждом клиенте, но, по крайней мере, это решение ...

Я не уверен, что Windows делает при проверке сертификата, возможно, она проверяет аннулирование или что-то еще и ожидает тайм-аута (потому что он не может связаться с Verisign и друзьями). Без понятия.

На основании ответа трапперджона:

если вы находитесь в ограниченной среде без доступа к внешним (даже несамоподписанным) центрам сертификации (и доступ медленный при доступе к SVN через https), вы можете указать их в C:\Users\<user>\AppData\Roaming\Subversion\servers файл следующим образом:

ssl-authority-files = C:\<some path>\<intermediate CA>.pem;C:\<some path>\<root CA>.pem

Обратите внимание, что вам нужно указать как промежуточный, так и корневой ЦС (если есть промежуточный ЦС). (Для получения сертификатов в формате PEM можно использовать Firefox.)

Проблема: После вызова SVN из командной строки на сервере с брандмауэром ничего видимого не происходит в течение 15 секунд, затем программа завершает работу со следующей ошибкой:

svn: E170013: Невозможно подключиться к репозиторию по URL-адресу 'SVN.REPOSITORY.REDACTED'

svn: E730054: Ошибка при запуске контекста: существующее соединение было принудительно закрыто удаленным узлом.

Изучение: Интернет-исследование вышеуказанных ошибок не дало соответствующей информации.

Трассировка процессов (procmon) показала попытку подключения к серверу Akamai (облачные службы) после установления связи SSL / TLS с сервером SVN. Имя хоста для сервера не было показано в трассировке процесса. Обратный поиск в DNS показал в качестве имени хоста a184-51-112-88.deploy.static.akamaitechnologies.com или a184-51-112-80.deploy.static.akamaitechnologies.com, а IP-адрес был 184.51.112.88 или 184.51. 112,80 (2 записи в кеше DNS).

Инструмент захвата пакетов (MMA) показал попытку подключения к имени хоста ctldl.windowsupdate.com после установления связи SSL / TLS с сервером SVN.

Windows Crypto API пытался подключиться к Центру обновления Windows для получения информации об отзыве сертификата (CRL - список отзыва сертификатов). Тайм-аут по умолчанию для получения CRL составляет 15 секунд. Тайм-аут аутентификации на сервере составляет 10 секунд; поскольку 15 больше 10, это не удается.

Разрешение: Интернет-исследование выявило следующее: (также см. Картинку внизу)

Решение 1. Уменьшите время ожидания CRL Групповая политика -> Конфигурация компьютера -> Параметры Windows -> Параметры безопасности -> Политики открытого ключа -> Параметры проверки пути сертификата -> Получение по сети - см. Рисунок ниже.

https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698

support.microsoft.com/en-us/kb/2625048

blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx

Решение 2. Откройте брандмауэр для трафика CRL

support.microsoft.com/en-us/kb/2677070

Решение 3.Флаги командной строки SVN (не проверено)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - альтернативное решение флага командной строки svn.

Дополнительная информация: Отладка этой проблемы была особенно сложной. SVN 1.8 отключил поддержку библиотеки Neon HTTP RA (доступ к репозиторию) в пользу библиотеки Serf, которая удалила ведение журнала отладки клиента. [1] Кроме того, возвращенный код ошибки SVN не соответствует строке, указанной в svn_error_codes.h [2] Кроме того, коды ошибок SVN не могут быть легко отображены обратно в их метку ENUM, в этом случае код ошибки SVN E170013 отображается на SVN_ERR_RA_CANNOT_CREATE_SESSION.

  1. stackoverflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output
  2. people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
  3. code.google.com/archive/p/serf/issues/172

Предлагаемые изменения SVN:

  1. Включить многословие в команде, как для всех операций

  2. Добавить имя ENUM ошибки в stderr

  3. Добавить флаг конфигурации для ведения журнала отладки библиотеки Serf.