cUrl para um endereço / domínio HTTPS expira a menos que seja acessado anteriormente pelo navegador

5

Eu perdi alguns dias para esse problema e espero que isso aconteça a alguém.

Estou integrando vários sistemas juntos usando scripts do Powershell. Um dos dois serviços aos quais estou me conectando (o JIRA hospedado) pode ser acessado muito bem no meu sistema local, mas o script falharia ao executar a partir de uma das minhas VMs. Descobri, por acaso, que, se eu abrisse / atualizasse um navegador no servidor para uma URL HTTPS para esse host, o script seria capaz de acessar a API por HTTPS por cerca de 20 a 30 segundos depois.

Eu recebo um erro de tempo limite quando eu me conecto remotamente ao servidor e tento isso em um console do powershell. Eu então verifiquei o mesmo comportamento ocorre com cUrl (saída detalhada incluída abaixo). A atualização de um navegador com esse domínio permite que ambos acessem URLs HTTPS por um curto período de tempo. Parece estar expirando na conexão inicial antes da negociação do SSL.

Comando PoSH representativo:

Invoke-RestMethod -Method Get -Uri "https://MYDOMAIN.atlassian.net/rest/api/2/issue/PLPT-1?fields=key,id,status" -Headers @{"Authorization" = "Basic "+ [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('USERNAME:PASSWORD'))}

Comando Representative cUrl:

curl.exe "https://MYDOMAIN.atlassian.net/rest/api/2/issue/PLPT-1?fields=key,id,status" -u "USERNAME:PASSWORD" -v -X GET

Eu tenho feito muita pesquisa sobre isso e estou bastante perplexo. Eu tentei usar o Wireshark para ir mais fundo, mas faz anos desde que usei um sniffer de pacotes e estou enferrujado e tendo que aprender a interface do usuário.

Solução de problemas:

Aqui estão as perguntas / respostas que eu pude pensar ao tentar isolar o problema:

  • É o powershell?
    • O uso de cUrl também expira
  • Tudo é HTTPS?
    • https://google.com/ funciona bem sem tempo limite
    • https://localhost/... funciona bem sem tempo limite
  • É um sistema que acessou o JIRA por meio do navegador?
    • Verifiquei que meu desktop doméstico podia se conectar via PoSH, apesar de nunca ter acessado o JIRA
  • Host, DC ou SO?
    • Esta é uma VM 2008 R2 no Azure, verifiquei que os comandos PoSH e cUrl funcionam bem em uma segunda VM do Azure executando 2008 R2
  • Firewall, antivírus?
    • Antivírus e Firewall desativados, cUrl + PoSH ainda tempo limite
  • Agente do usuário?
    • A inclusão de um agente do usuário não fez diferença no sistema de problemas ou nos sistemas em funcionamento
  • O que o Fiddler diz?
    • Fiddler com descriptografia SSL causou erros de gateway ao invés de timeouts, eu não pesquisei mais
  • Talvez seja um problema de rede para a Atlassian? Conectividade intermitente?
    • Tenho recebido consistentemente erros do meu servidor e tem funcionado consistentemente em todos os lugares que tentei
    • Eu realizei 10 chamadas consecutivas no servidor e localmente e obtive retornos perfeitos dos 10 tempos limite locais e perfeitos do servidor. Depois de fazer o truque de atualização do navegador no servidor, recebi 10 respostas perfeitas seguidas.
  • Como se parece no Wireshark?
    • Com cUrl: Wireshark mostra que a chamada TCP inicial sai, mas não é ACKed, então você vê duas tentativas de Retransmissão TCP
    • Com cUrl após o preparo do brower: Wireshark mostra que a primeira chamada do TCP é ACKed e então tudo funciona conforme o esperado

Por um curto período de tempo, achei que tinha conseguido trabalhar de forma consistente. Eu estava usando -3 -4 para forçar endereços SSL3 e ipv4 e parecia estar funcionando sem que eu precisasse estabelecer a conexão com um navegador da web. Infelizmente, após a reinicialização, isso não funciona mais.

Métodos que eu tentei no servidor:

  • cUrl, cRrl com -3 -4
  • PoSH: Invoke-RestMethod, Invoke-WebRequest, WebClient, WebRequest / WebResponse, configurando SSL padrão para SSL3 via ServicePointManager, configurando credenciais de proxy e proxy por meio de padrões do sistema, caso haja um (não é do meu conhecimento)
  • IE: funciona
  • Chrome: funciona

Saída cUrl

Aqui está um exemplo de saída da cUrl. Eu já tenho um navegador aberto para https://MYDOMAIN.atlassian.net (está na tela de login), mas deixei por um tempo, então a conexão seria obsoleta.

Saída cUrl antes de atualizar o navegador:

* Hostname was NOT found in DNS cache
*   Trying 165.254.226.145...
* connect to 165.254.226.145 port 443 failed: Timed out
* Failed to connect to MYDOMAIN.atlassian.net port 443: Timed out
* Closing connection 0

saída cUrl quando eu corro logo após atualizar o navegador:

* Hostname was NOT found in DNS cache
*   Trying 165.254.226.145...
* Connected to MYDOMAIN.atlassian.net (165.254.226.145) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: C:\Users\Administrator\AppData\Local\Apps\cURL\bin\curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
... rest of handshake and HTML for a 401 error page because I didn't force pre-authentication ...

Atualizado

Eu adicionei os resultados do Wireshark às perguntas acima.

Agora também descobri que, se eu executar o comando cUrl e cancelá-lo antes que ele expire e execute-o imediatamente, ele será bem-sucedido. se eu deixar o tempo limite do comando cUrl voltar a executá-lo imediatamente, ele expira novamente.

Se eu executar o comando PoSH e cancelá-lo antes que ele expire e execute-o imediatamente novamente, posso executá-lo 5 vezes seguidas com êxito.

Isso é definitivamente algo relacionado a redes, eu vou ver se re-executar o comando eventualmente chega a um ponto em que ele expira novamente ou se cancelar a primeira chamada de alguma forma me permite continuar fazendo chamadas subsequentes contanto que Eu posso (o que pode ser possível, acho PoSH está aproveitando de manter vivo uma vez que a conexão inicial é formada).

    
por Tarwn 28.09.2014 / 17:26

2 respostas

0

Minha "solução" temporária é usar um tempo limite curto nas chamadas iniciais e tentar novamente imediatamente se elas falharem. O tempo limite é curto o suficiente para que nesse servidor ele falhe e tente novamente rápido o suficiente para começar a se comunicar com êxito (como quando eu o executei manualmente, cancelei e executei novamente).

Até agora, parece que ter um tempo limite e novas tentativas é bom o suficiente para manter a conexão funcionando para que o resto do script de automação seja executado sem problemas.

Esta é uma solução alternativa, ainda estou procurando a causa raiz e uma resposta melhor.

    
por 29.09.2014 / 15:42
0

Para sintomas muito semelhantes (curvatura de saída detalhada ao falhar versus passar), mas para falhas intermitentes com apenas ondulação do CL, aparecem , descobrimos que essa opção adicional para enrolar efetivamente resolve esse problema:

--connect-timeout 30
    
por 05.06.2018 / 14:53