Quais configurações de DNS estão relacionadas ao proxy do DNS usando o SOCKSv5 por meio de um túnel openssh?

Question

USE CASE: Eu tenho uma máquina Debian Stretch funcional. Ele tem acesso WAN através do meu roteador com resolução de DNS operacional (eu posso pingar www.google.com e obter uma resposta). Ele roda open-sshd , que eu uso como um proxy SOCKS5 . Por exemplo eu uso Putty em MS. Máquinas Windows para encapsular seu tráfego através de redes desprotegidas e / ou redes excessivamente protegidas (ou seja, eu uso como uma VPN de pobre). Normalmente, essa configuração funcionou perfeitamente.

PROBLEMA: agora que tenho um novo roteador, me deparo com o seguinte problema:

Depois que eu ligo " DNS proxy ao usar o SOCKS v5 " no cliente que usa o proxy / túnel (o Firefox neste caso) o túnel fica imenso (falando minutos aqui) quando tento resolver, por exemplo, www.google.com. Quando uso o IPv4 do Google (172.217.17.100), ele é carregado quase instantaneamente.

Então eu já o reduzi a um DNS (tempo limite?), mas aqui meu conhecimento me falha Por isso, minha pergunta aqui:

• Quais são as configurações de roteamento que podem estar relacionadas à solução de DNS quando estão em proxy (especialmente em relação ao caso de uso mencionado anteriormente)?

Nota 1) A máquina que está executando o opensshd não tem problemas usando o próprio DNS (é como se simplesmente não estendesse essa funcionalidade para o client abreviado do openssh).

Nota 2) O problema é maior do que simplesmente desligar o uso do DNS remoto no cliente (possível no Firefox) como muitos programas sempre (não configuráveis) usam o DNS do servidor no ponto final do túnel (principalmente para razões de privacidade).

P.S. Que este post seja relacionado: link

    

Answer 1

Embora muitas outras configurações provavelmente estejam relacionadas ao DNS por proxy, a que causou o atraso no caso descrito foi simplesmente o DNS primário apontando para uma falha não extirpadora (pi-hole ). Parece que os clientes regulares simplesmente mudaram para o secundário (neste caso, o roteador), já que tirei o Pi-hole algumas semanas atrás, mas o proxy de tunelamento ssh aparentemente não mudava tão facilmente (mas, em vez disso, esperei minutos ou mesmo até um tempo limite ou algo nesse sentido). A qualquer custo; remover o encaminhamento para o servidor DNS não existente removeu o atraso!