Encaminhar todo o tráfego através de um túnel ssh

1

Espero que alguém possa seguir isso e eu explicarei da melhor maneira possível.

Estou tentando encaminhar todo o tráfego da porta 6999 em x.x.x.224, por meio de um túnel ssh e na porta 7000 em x.x.x.218.

Aqui estão algumas artes ASCII:

|browser|-----|Squid on x.x.x.224|------|ssh tunnel|------<satellite link>-----|Squid on x.x.x.218|-----|www|
         3128                      6999                          7000                                80

Quando eu removo o túnel ssh, tudo funciona bem.

A ideia é desativar a criptografia no túnel ssh (para economizar largura de banda) e ativar a compactação máxima (para economizar mais largura de banda). Isso é porque é um link de satélite.

Aqui está o túnel ssh que eu tenho usado:

ssh -C -f -C -o CompressionLevel=9 -o Cipher=none [email protected] -L 7000:172.16.1.224:6999 -N

O problema é que não sei como obter dados do Squid em x.x.x.224 no túnel ssh? Eu estou indo sobre isso da maneira errada? Devo criar um túnel ssh em x.x.x.218? Eu uso iptables para parar o squid em x.x.x.224 da porta de leitura 80, mas para alimentar a partir da porta 6999 (ou seja, através do túnel ssh). Preciso de outra regra iptables?

Qualquer comentário muito apreciado.

Muito obrigado antecipadamente,

Com relação à pergunta de Eduardo Ivanec, aqui está um netstat -i any port 7000 -nn dump de x.x.x.218:

14:42:15.386462 IP 172.16.1.224.40006 > 172.16.1.218.7000: Flags [S], seq 2804513708, win 14600, options [mss 1460,sackOK,TS val 86702647 ecr 0,nop,wscale 4], length 0
14:42:15.386690 IP 172.16.1.218.7000 > 172.16.1.224.40006: Flags [R.], seq 0, ack 2804513709, win 0, length 0

Atualização 2:

Quando executo o segundo comando, recebo o seguinte erro no meu navegador:

ERROR
The requested URL could not be retrieved

The following error was encountered while trying to retrieve the URL: http://109.123.109.205/index.php

Zero Sized Reply

Squid did not receive any data for this request.

Your cache administrator is webmaster.


Generated Fri, 01 Jul 2011 16:06:06 GMT by remote-site (squid/2.7.STABLE9)

site remoto é 172.16.1.224

Quando faço uma tcpdump -i any port 7000 -nn

Eu recebo o seguinte:

root@remote-site:~# tcpdump -i any port 7000 -nn  
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused 
channel 2: open failed: connect failed: Connection refused
    
por Eamorr 01.07.2011 / 15:17

1 resposta

2

Se eu entendi corretamente, há algo errado com a sua definição de túnel. O que você parece estar fazendo com a sua linha de comando atual é encaminhar o tráfego da porta 7000 no host atual (suponho que seja .224) para a porta 6999 no próprio .224.

Tente isso:

ssh -N -g -f -C -o CompressionLevel=9 -o Cipher=none [email protected] -L 6999:172.16.1.218:7000

Ou, se 172.16.1.218:7000 não puder ser acessado diretamente (suponho que não seja, como você provavelmente se conectaria diretamente a ele de outra forma), você provavelmente desejará conectar-se a 172.16.1.218:

ssh -N -g -f -C -o CompressionLevel=9 -o Cipher=none [email protected] -L 6999:localhost:7000

O formato para -L é <localport>:<remotehost>:<remoteport> . <remotehost> é relativo ao host de destino, portanto, neste caso localhost deve funcionar.

Note que eu adicionei -g caso você queira usar o tunel de uma máquina diferente de .224 (suponho que você esteja rodando ssh em .224).

    
por 01.07.2011 / 15:37