Conexão redirecionada recusada pelo servidor: proibida administrativamente [falha na abertura]

3

Por vezes, utilizo o PuTTY como um proxy SOCKS, e notei que, por vezes, quando a página Web a que estou a tentar ligar (do navegador da Web) não existe e requer um tempo limite prolongado, trava de sessão do shell (não é possível digitar interativamente no terminal até que o tempo limite seja atingido) e também todos os outros pedidos de páginas da Web ficam paralisados .

Recentemente, observei que isso parece estar relacionado ao DNS : no momento, parece que os servidores especificados no sshd side em /etc/resolv.conf estão tendo alguns problemas e Como resultado, é quase impossível navegar na Internet por meio de um proxy PuTTY SOCKS, e também o terminal PuTTY fica parado quase o tempo todo quando qualquer navegação na Web é feita sem sucesso.

O erro a seguir aparece com freqüência nos registros do PuTTY, após o qual a paralisação parece parar por um tempo:

2014-01-11 17:12:03 Forwarded connection refused by server: Administratively prohibited [open failed]

Normalmente, isso é o que eu vejo nos logs, o que me dá a impressão de que meu navegador com SOCKS nem sabe qual endereço IP o proxy SOCKS irá conectá-lo a:

2014-01-11 17:18:11 Opening forwarded connection to superuser.com:80

A alteração do servidor DNS em torno do daemon ssh seria apenas uma solução temporária, que não resolveria o problema subjacente com a paralisação do OpenSSH / PuTTY nessas situações. (Não usar nomes de host através do SOCKS também parece estar errado.)

Existe alguma maneira de mitigar o bloqueio ssh para o bem?

(No mínimo, pareceria que o sshd deveria ser mais agressivo no tempo limite de DNS, e tentando novamente com outro servidor. Eu tenho vários servidores especificados em /etc/resolv.conf, e dig parece Emitir o pedido para o próximo servidor após exatamente 1s, o que parece mais apropriado do que o sshd parece estar fazendo.)

    
por cnst 12.01.2014 / 02:32

1 resposta

1

De acordo com um desenvolvedor do OpenSSH na lista de discussão oficial, link , isso se deve ao fato de que um resolvedor padrão da libc é usado pelo OpenSSH, que é síncrono e bloqueador, de modo que nenhum outro tráfego é processado enquanto uma resolução está em andamento.

Corrigir esse problema exigiria uma correção em torno de ssh / channels.c # connect_to no OpenSSH ( bug # 1357 confirma que está no caminho de código do SOCKS5 como usado pelo Mozilla), para usar uma função de resolução diferente do padrão getaddrinfo da libc.

    
por 12.01.2014 / 19:03