O tunelamento de DNS através de uma conexão SSH perde conectividade

5

Na pergunta de superusuário Tráfego UDP pelo túnel SSH , descreve como encapsular o DNS através de um túnel SSH:

Primeiro, no lado do cliente, faça isso:

ssh -N -L 6667:localhost:6667 user@server

Então, no lado do servidor, faça isso:

mkfifo /tmp/fifo
nc -k -l 6667 < /tmp/fifo | nc -u ip_of_dns_server 53 > /tmp/fifo

Finalmente, de volta no lado do cliente, faça isso:

mkfifo /tmp/fifo
nc -k -l -u 53 < /tmp/fifo | nc 127.0.0.1 6667 > /tmp/fifo

Depois disso, posso fazer uma consulta DNS conforme o esperado, mas apenas para uma única solicitação :

client# host m6.fr 127.0.0.1

Como posso manter a conexão ativa para mais solicitações?

    
por StackUnderflow 24.04.2014 / 16:46

1 resposta

1

TL; DR: não use o Netcat, use Socat para experiências. Ele lida com algo melhor.

A razão de não estar funcionando não é sobre os pipes nomeados (mesmo que seja um método feio com outros problemas ocultos), mas uma limitação do netcat.

Quando o Netcat recebe uma conexão UDP, ele se vincula a ele. Por isso, não está mais ouvindo a porta 53, ela está conectada à porta que enviou o pacote inicial, exatamente como faria com o TCP. Sempre que você faz uma solicitação de DNS, a ferramenta altera a porta e o Netcat nunca recebe a solicitação. Então, apenas o primeiro pedido funcionará.

Ao configurar seu exemplo, tente este comando antes da primeira consulta:

netstat -aunp|grep -w 53
udp        0      0 0.0.0.0:53              0.0.0.0:*                           12316/nc.openbsd 

Faça a consulta (somente trabalhando) e tente novamente netstat:

# netstat -aunp|grep -w 53
udp        0      0 127.0.0.1:53            127.0.0.1:44335         ESTABLISHED 12316/nc.openbsd

Como você pode ver, o netcat acabou de alterar o modo: De ouvir o loop por uma conexão. Por ser o UDP, a Netcat não saberá mais que a "conexão estabelecida" não está mais lá.

Eu tenho uma prova de conceito (que faz com que funcione e mostre que o problema está relacionado a este modo UDP), mas requer socat além do netcat no cliente. O objetivo é que todas as solicitações cheguem ao netcat usando a mesma porta UDP source . Nada muda no lado do servidor, mas insiro socat no início da cadeia (então o último comando) para forçar a porta de origem da solicitação UDP para o Netcat.

Primeiro, no lado do cliente, faça isso:

ssh -N -L 6667:localhost:6667 user@server

Então, no lado do servidor, faça isso:

mkfifo /tmp/fifo
nc -k -l 6667 < /tmp/fifo | nc -u ip_of_dns_server 53 > /tmp/fifo

Finalmente, de volta no lado do cliente, faça isso:

mkfifo /tmp/fifo
nc -k -l -u 5555 < /tmp/fifo | nc 127.0.0.1 6667 > /tmp/fifo

socat udp4-listen:53,reuseaddr,fork udp:127.0.0.1:5555,sourceport=55550,reuseaddr

Agora posso fazer várias consultas.

Antes da primeira consulta:

# netstat -aunp|egrep -w '53|5555'
udp        0      0 0.0.0.0:5555            0.0.0.0:*                           12715/nc.openbsd    
udp        0      0 0.0.0.0:53              0.0.0.0:*                           12717/socat         

Após o 1º:

udp        0      0 127.0.0.1:55550         127.0.0.1:5555          ESTABLISHED 12736/socat         
udp        0      0 127.0.0.1:5555          127.0.0.1:55550         ESTABLISHED 12715/nc.openbsd    
udp        0      0 0.0.0.0:53              0.0.0.0:*                           12717/socat         

Após a segunda consulta:

udp        0      0 127.0.0.1:55550         127.0.0.1:5555          ESTABLISHED 12750/socat         
udp        0      0 127.0.0.1:5555          127.0.0.1:55550         ESTABLISHED 12715/nc.openbsd    
udp        0      0 0.0.0.0:53              0.0.0.0:*                           12717/socat         
udp        0      0 127.0.0.1:53            127.0.0.1:53255         ESTABLISHED 12750/socat         

O Socat sofreria o mesmo problema, mas com a opção fork , ele escuta novamente, e parece que detecta a “conexão” perdida anterior; Acho que isso causa um atraso.

Você pode obter o comportamento antigo (funciona uma vez) se simplesmente remover a parte ,sourceport=55550,reuseaddr no comando socat.

    
por 12.09.2016 / 03:30