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 (заслуживает конфиденциальности…):

# Уменьшить кэш LDAP до 30 секунд
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"

  # Требовать ldap group через правило Microsoft "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: Установлено подключение к дочернему процессу 0 (сервер 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 виртуальный хост для servername svnserver.mydomain.local найден

Теперь 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: Последующий (No.2) HTTPS запрос получен для дочернего процесса 0 (сервер 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: результат авторизации Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local: отказано (пользователь еще не аутентифицирован)
[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: результат авторизации <RequireAny>: отказано (пользователь еще не аутентифицирован)
[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: использование 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: Установка ссылок в 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: принятие john.doe

Журнал ssl_access_log и ssl_request_log начинается на 36-й секунде, ничего не записывается с 14-й секунды.

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

Есть идеи? Что происходит между 14-й и 36-й секундой, и как предотвратить это? 😉

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

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

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

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

Это приводит к 20-секундной задержке:

svn list myrepo

а это – нет

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

К сожалению, немного печально, что это решение требует конфигурации на каждом клиенте, но, по крайней мере, это решение…

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

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

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

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

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

Отладка процесса (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 Update для получения информации о отзыве сертификата (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.

Основываясь на ответе trapperjohn:

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

ssl-authority-files = C:\<некоторый путь>\<промежуточный CA>.pem;C:\<некоторый путь>\<корневой CA>.pem

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