Tortoise SVN: Tempo limite de conexão inicial

Question

Eu tenho um problema ao conectar o Tortoise SVN ao meu servidor SVN. A primeira conexão parece ter um tempo limite (o SVN trava cerca de 20 segundos) e a segunda tentativa (automática) funciona instantaneamente. Ou seja cada atualização, commit, log leva um tempo muuuuito e deixa todo mundo louco ...

A mesma ação do SVN de um cliente de linha de comando do Linux funciona instantaneamente. O acesso via navegador da Web funciona também sem atrasos.

A configuração do SVN é a seguinte: O servidor SVN roda o CentOS 7, o Apache 2.4.6 e o mod_dav_svn 1.7.14. O acesso via SSL está configurado. A autenticação é feita via LDAP em um Windows Server 2012 R2. O cliente (Windows 7 x64) executa o Tortoise 1.7.15 (x64).

Esta é a configuração relevante do Apache (ofuscada ...):

# 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>

O log do Apache (ssl_error_log) é iniciado assim ao iniciar a atividade do 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

Agora o SVN parece travar (timestamp no segundo 14) - O Apache mataria a conexão um pouco mais tarde quando o módulo reqtimeout estivesse ativado (eu o desativei neste cenário). Cerca de 20 segundos depois (data e hora no segundo 36), a atividade continua:

[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

O ssl_access_log e ssl_request_log começam no segundo 36, nada é registrado do segundo 14

Para mim, parece que o Tortoise SVN inicia a conexão sem credenciais ou não usando https (?), o que leva a um tempo limite. A segunda conexão parece estar usando https, mas com as credenciais erradas e, finalmente, o Tortoise se conecta usando as credenciais corretas e a autenticação é bem-sucedida.

Alguma ideia? O que acontece entre o segundo 14 e o segundo 36 e como posso evitar que isso aconteça? ; -)

Obrigado Florian

Atualização: Encontrei uma solução (embora não tenha certeza do motivo) ... Toda vez que eu inicio o Tortoise SVN (ou o cliente de linha de comando svn do Windows), notei atividade no firewall: o controlador de domínio estava tentando acessar vários servidores, por exemplo, c.root-servers.net que parecem ser servidores VERISIGN para verificar o certificado SSL ou para encontrar novos certificados raiz etc (?). Isso foi bloqueado pelo firewall, então o DC demorou para passar pela lista de servidores alternativos.

Estamos usando certificados autoassinados, portanto, minha primeira tentativa foi injetar nosso certificado de autoridade de certificação no gerenciamento de certificados do Windows por meio da política de grupo. Isso funcionou (pelo menos o SVN não reclamou de uma CA desconhecida após excluir todas as informações de autenticação). No entanto, o atraso de 20 segundos ainda está lá (e o DC ainda está tentando alcançar a Verisign).

Eventualmente eu tentei a opção de configuração local do SVN "ssl-authority-files" para passar estaticamente o certificado de CA et voilà: o atraso se foi!

Ou seja. isso leva a 20 segundos de atraso:

svn list myrepo

e isso não

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

Ainda é um pouco triste que essa solução precise de configuração em cada cliente, mas pelo menos é uma solução ...

Não sei ao certo o que o Windows está fazendo ao verificar o certificado, talvez ele esteja verificando a revogação ou algo assim e aguardando o tempo limite (porque não pode alcançar a Verisign e os amigos). Não faço ideia.

    

Answer 1

Problema: Após invocar o SVN na linha de comando em um servidor com firewall, nada visível acontece por 15 segundos e, em seguida, o programa é encerrado com o seguinte erro:

svn: E170013: Não é possível conectar-se a um repositório na URL 'SVN.REPOSITORY.REDACTED'

svn: E730054: Erro ao executar o contexto: Uma conexão existente foi forçosamente fechada pelo host remoto.

Investigação: A pesquisa na Internet sobre os erros acima não revelou nenhuma informação pertinente.

Rastreamento de processo (procmon) mostrou uma tentativa de conexão a um servidor Akamai (serviços de nuvem) após o handshake SSL / TLS para o servidor SVN. O nome do host para o servidor não foi mostrado no rastreio do processo. A pesquisa reversa de DNS mostrou a184-51-112-88.deploy.static.akamaitechnologies.com ou a184-51-112-80.deploy.static.akamaitechnologies.com como o nome do host, e o IP era 184.51.112.88 ou 184.51. 112,80 (2 entradas no cache do DNS).

A ferramenta de captura de pacotes (MMA) mostrou uma tentativa de conexão ao nome do host ctldl.windowsupdate.com após o handshake SSL / TLS para o servidor SVN.

A API do Windows Crypto estava tentando se conectar ao Windows Update para recuperar as informações de revogação de certificados (CRL - lista de revogação de certificados). O tempo limite padrão para a recuperação da CRL é de 15 segundos. O tempo limite para autenticação no servidor é de 10 segundos; como 15 é maior que 10, isso falha.

Resolução: A pesquisa na Internet revelou o seguinte: (veja também a imagem na parte inferior)

Solução 1: Diminuir a diretiva de grupo de tempo limite da CRL - > Configuração do computador - > Configurações do Windows - > Configurações de segurança - > Políticas de chave pública - > Configurações de validação do caminho do certificado - > Recuperação de Rede - veja a imagem abaixo.

link

support.microsoft.com/pt-BR/kb/2625048

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

Solução 2: Abra o firewall para o tráfego da CRL

support.microsoft.com/pt-BR/kb/2677070

Solução 3: sinalizadores de linha de comando do SVN (não testado)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - solução de sinalizador de linha de comando do svn alternativo.

Informações adicionais: A depuração desse problema foi particularmente difícil. O SVN 1.8 desabilitou o suporte para a biblioteca Neon HTTP RA (acesso ao repositório) em favor da biblioteca Serf que removeu o registro de depuração do cliente. [1] Além disso, o código de erro SVN retornado não corresponde à string dada em svn_error_codes.h [2] Além disso, os códigos de erro SVN não podem ser mapeados facilmente para o rótulo ENUM, neste caso o código de erro SVN E170013 é mapeado para SVN_ERR_RA_CANNOT_CREATE_SESSION. / p>

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

Alterações sugeridas ao SVN:

1. Ative a verbosidade no comando, como para todas as operações

2. Adicione o nome do erro ENUM ao stderr

3. Adicione o sinalizador de configuração para o log de depuração da biblioteca de Serf.

Answer 2

Com base na resposta do trapperjohn:

se você estiver em um ambiente restrito sem acesso às ACs externas (mesmo que não auto-assinadas) (e o acesso for lento ao acessar o SVN via https), você poderá especificá-las no arquivo C:\Users\<user>\AppData\Roaming\Subversion\servers da seguinte forma :

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

Observe que você precisa especificar a CA intermediária e a raiz (se houver uma CA intermediária). (Para obter os certificados no formato PEM, o Firefox pode ser usado.)