DNS sobre o túnel SSH

Question

Eu quero configurar meu sistema OSX de forma que todo o tráfego de rede seja feito através de um túnel SSH.

Eu escrevi um pequeno script para esse propósito, e estes são os comandos executados por ele:

// setup tunnel
ssh -fN -D 1080 -p 22 user@remote

// start up redsocks
sudo redsocks -c /tmp/redsocks.conf -p /tmp/redsocks.pid

// forward all tcp traffic to tunnel
sudo ipfw add 0010 fwd 127.0.0.1,12345 tcp from me to any not dst-port 12345 not dst-port 1080 not dst-ip REMOTE_IP

Eu uso redsocks para criar um proxy http para o meu ssh-tunnel (para que eu possa encaminhar todo o tráfego tcp para ele via ipfw), o redsocks.conf se parece com isso:

base {
    log_debug = on;
    log_info = on;
    log = "file:/tmp/redsocks.log";
    redirector = generic;
}
redsocks {
    local_ip = 127.0.0.1;
    local_port = 55660;
    ip = 127.0.0.1;
    port = 1080;
    type = socks4;
}

Tudo parece funcionar até agora, todo o tráfego TCP no meu sistema OSX é feito através do túnel ssh, mas o problema é com o tráfego UDP e, por causa disso, as consultas DNS não estão funcionando.

Como posso obter DNS em minha máquina local para trabalhar no túnel SSH?

    

Answer 1

Sua linha ipfw … encaminha apenas o tráfego TCP. Talvez adicione a seguinte linha?

sudo ipfw add 0011 fwd 127.0.0.1,12345 \
                   udp from me \
                   to any not dst-port 12345 \
                          not dst-port 1080 \
                          not dst-ip REMOTE_IP

Também é uma boa idéia adicionar set -x (para depuração) e set -e (falhar imediatamente se algum dos comandos falhar).

• Geralmente, deve-se usar o termo "tunelamento SSH" para se referir a tun / tap com SSH.
• O encaminhamento de porta é uma forma específica de encapsulamento, mas ainda deve ser chamado de "encaminhamento de porta" neste contexto.
• Não use o encapsulamento SSH (como em -oTunnel e -oTunnelDevice ), exceto para tarefas ad-hoc rápidas.
  • TCP sobre TCP é uma ideia muito ruim:
    • Por que o TCP sobre TCP é uma má idéia
    • Noções básicas sobre TCP sobre TCP: efeitos do encapsulamento TCP na taxa de transferência de ponta a ponta e na latência
  • O UDP over TCP adiciona excessivamente a latência aos aplicativos que normalmente fazem uso dele. Programas que fazem uso do UDP devem ter controle total sobre sua própria confiabilidade e controle de congestionamento, como é o caso da RTP.
• O DNS pode usar o TCP como um transporte. Não está restrito ao UDP, embora seja o transporte preferido .

Answer 2

Use sshuttle em vez disso? O sshuttle alega lidar com DNS e TCP corretamente, sem essa quantidade de intrigas - apenas a opção --dns .

IME SOCKS parecia um pouco velho e não amado. E eu realmente não entendo esse uso de ipfw e redsocks.

No entanto, gostaria de salientar que SOCKS4 não suporta DNS de tunelamento, por isso não me surpreende que você esteja tendo problemas. Versões subsequentes do SOCKS suportam isso, então você pode ver isso. E, aparentemente, o SSH pode suportar o SOCKS5 .

    

Answer 3

Além do que você já está usando, o sSH permite encapsular todo o tráfego IP, independente do protocolo da camada 4 utilizada. Seu servidor remoto deve ter PermitTunnel yes e o cliente deve solicitar um encapsulamento usando a diretiva Tunnel . Então você pode usar esse novo link como seu gateway padrão. Veja instruções detalhadas para o túnel aqui.