Chita

Ah, os túneis. Mistura de dádiva e maldição para os usuários fuçadores e administradores de rede, respectivamente. Neste artigo irei abordar como utiliza-los para burlar quase qualquer tipo de restrição imposta ao acesso a internet em redes públicas; que podem não só serem utilizados para fins excusos ou para a defesa da liberdade de expressão na China ou em Cuba, mas também para simplificar muito o seu dia-a-dia.

Antes de começar:
Todos os métodos que irei comentar aqui assumem que você tenha disponível uma outra conexão à internet disponível em algum lugar, seja em sua casa ou em um servidor pago ou de terceiros, para que seja usado como proxy. Nerd que se preze sempre tem a mão uma conexão SSH disponível

Se você não tem uma, suas opções para conseguir uma são:

• Registrar-se em um servidor gratuito – Geralmente os serviços de shell gratuitos são bem limitados, mas você pode tentar o Cjb.net ou o Rootshell.be, ou ainda caçar algum outro.
• Largar a mão de ser muquirana e usar um serviço comercial: Boa parte dos provedores de hospedagem costumam prover também serviços de SSH, com toda a qualidade e customização que o seu dinheiro pode comprar – E nem costuma ser tão caro assim. Minha dicas: VPSByte para VPSs (Virtual Private Server) a partir de US$10/mês, ou o LeaseWeb para um serviço mais sofisticado, com servidor dedicado como o que a Chita usa
• Instalar seu próprio servidor na conexão de casa – Algo que pode ser feito com o seu desktop ou mesmo ou instalando Linux no seu roteador para não precisar deixar o micro ligado 24/7.

Método 1 – O Clássico Tunelamento SSH

Local: Praticamente qualquer rede corporativa ou pública (lan houses, escolas, faculdades)
Problema: Você consegue acesso normal a HTTP, contudo a navegação é barrada para alguns sites específicos, devido ao firewall draconiano. Além disso, toda sua navegação está sendo logada no servidor da instituição – Um prato cheio para qualquer amante de teoria da conspiracao. Você não consegue acessar portas não-HTTP, o que impede o uso de alguns programas.
Solução: O clássico tunelamento SSH irá criar um canal de comunicação privativo entre o seu desktop e seu servidor, cujo conteúdo não poderá ser interceptado pela rede pública do mal, graças a criptografia empregada. Dependendo do caso, sua navegação poderá até mesmo ficar mais rápida do que seria normalmente, se utilizar também a opção de compressão SSH!

Como fazer:
Para isso, você irá precisar que a rede permita uma conexão TCP (SSH) até o seu servidor. Como em geral nessas redes são permitidas apenas conexões TCP para serviços HTTP, (porta 80 ou 443), é recomendável que o seu servidor pessoal fique ouvindo SSH também nessas portas, além da padrão 22. Desta forma você poderá se conectar a ele “disfarçado” de requisição HTTP/S.

1) Abra uma conexão ssh até seu servidor, com as seguintes opções:

ssh usuario@seuservidor.seudominio.com -D 8080 -C

A opção -D indica que deverá ser criada uma Tunel Dinâmico na porta 8080 de seu desktop. Um túnel dinâmico funciona exatamente da mesma forma que um proxy SOCKS, ou seja, você pode pode configurar qualquer aplicação que tenha suporte a SOCKS para que utilize o túnel!

A opção -C indica que deverá ser utilizada compactação de dados na conexão. Utilize-a somente se a conexão entre os dois pontos (Seu Desktop e seu Servidor) não for muito rápida.

Se você usa Putty/Windows (Meus pesames pela segunda opção), a opção equivalente a -D se encontra em Connection, SSH, Tunnels e a -C em Connection, SSH.

2) Configure seu navegador para utilizar o túnel:

No Firefox, basta você ir em Editar, Preferências, Rede, Conexão – Configurar, Configuração de manual de proxy, e no campo SOCKS, informe localhost e porta 8080.

3) Teste que a aplicação está realmente usando o túnel

Uma forma de fazer isso é acessar http://tools.chita.com.br – O IP e Hostname de seu servidor deverão ser exibidos, e não os da rede que você se encontra.

Método 2 – Tunelamento HTTP

Se a sua rede for realmente restritiva e não permitir nenhuma conexão externa a não ser por um proxy HTTP, não tema! Você ainda tem chances!

Método 2A – Tunelamento HTTP+SSH

Esta solução é bem parecida com a do método 1, com a única diferença de que você irá realizar uma conexão SSH passando pelo Proxy HTTP, e não diretamente.

Se você usa o Putty, basta configurar o endereço do Proxy diretamente em Connection, Proxy:

Com o bom e velho ssh de linha de comando, você irá precisar da opção ProxyCommand. Essa opção é bem interessante, porque permite a possibilidade de utilizar qualquer outro programa para estabelecer o tunel no qual a sessão SSH será estabelecida. Neste exemplo, iremos usar o netcat como ProxyCommand. Resumindo, o netcat vai ser responsavel por realizar a conedxão de sua máquina ao proxy, e a partir deste ponto o SSH assume, usando esta ponte para abrir a sessão SSH normalmente.

Edite o arquivo ~/.ssh/config

Adicione as linhas:

## Para todos os hosts,
Host *
ProxyCommand connect -H proxy.local.net:8080 %h %p

Este método exige que o Proxy permita o uso de SSL (Comando Connect). Se não for o seu caso, leia o próximo método.

Método 2B – Tunelamento HTTP Puro

No caso de um proxy HTTP REALMENTE restritivo, onde SSL não possa ser usado, ainda existe mais um jeitinho: Tunelar por HTTP Puro.
A ferramenta clássica para este fim é o GNU httptunnel. Ele é dividido em 2 partes: cliente (htc) e servidor (hts).
O processo todo é bem simples, basta você especificar no cliente qual será a porta local a ser redirecionada e no servidor qual será a porta destino. Exemplo:

Cliente:

htc -F 12345 192.168.1.100:443

Servidor:

hts -F 443 ssh.meuservidor.com:22

Desta forma quando você realizar uma conexão em seu desktop, localhost na porta 12345, o cliente htc irá encaminhar o tráfego encapsulado em HTTP para o servidor 192.168.1.100:443, que irá estar executando o hts. O hts, por sua vez irá desencapsular o tráfego recebido e encaminha-lo para ssh.meuservidor.com:22.
Na prática, isso permite que você possa usar SSH e o tunelamento clássico que mencionamos no método 1, mesmo que o seu proxy de regime comunista não permita tal ato, uma vez que todo o tráfego será convertido em HTTP Puro, amado e geralmente permitido sem ou com poucas restrições pela maioria dos administradores de rede.

O GNU httptunnel, contudo, tem algumas limitações chatas:

• A parte server hts toma a porta de entrada só para ela e não pode compartilha-la com um webserver. Isso é extremamente incoveniente, visto que conseguir um servidor com uma porta privilegiada 80 ou 443 dando sopa é quase sempre um ato homérico.
• Se você ter destinos diferentes, irá ter que rodar diversas instancias do servidor, cada uma com seu destino e porta de entrada respectivos. Não é um problema se você pretende tunelar apenas uma conexão SSH para método clássico, mas com certeza será um problemas se você quiser tunelar diretamente tráfego sem depender do SSH.

Por sorte, acabei encontrando um programa que se propõe a corrigir esses erros terríveis do httptunnel, o webtunnel.

O funcionamento é bem parecido com o do httptunnel, com a grande diferença que a parte servidor roda dentro de um webserver, logo, não toma uma porta importante como a 80 ou 443 só para si, podendo ser hospedado em praticamente qualquer webhost existente. O destino da conexão é especificado na parte do cliente e não da do servidor, permitindo que sejam criados diversos destinos diferentes de uma forma bem simples e tão prática que pode até mesmo dispensar o uso do SSH, dependendo de sua necessidade.

Exemplo:

Servidor:
Basta publicar o arquivo wts.pl em qualquer parte visível de um website que tenha suporte a perl.

Cliente:

./wtc.pl tcp://localhost:12345 tcp://ssh.meudominio.com:22 http://meuservidorweb.com/wts.pl

Neste exemplo, todo o tráfego chegando a localhost na porta 12345 será redirecionado para ssh.meudominio.com na porta 22, usando http://meuservidorweb.com/wts.pl como túnel. Apesar de logico, vale lembrar que o destino será sempre o como é visto pelo servidor e não pelo cliente.

Estou disponibilizando a parte servidor aqui na Chita, para voces brincarem: http://tools.chita.com.br/wts.pl

Fique a vontade para usa-lo para um eventual acesso, mas no caso de abuso, serei obrigado a retira-lo do ar.

De qualquer forma, com este túnel aberto, basta você abrir uma sessão de SSH para a porta especificada e usar o Método 1 para não precisar criar diversos destinos diferentes durante a navegação:

ssh usuario@localhost -p 12345 -D 8080 -C

Métodos mais obscuros:

Se nenhum dos métodos de tunelamento acima funcionaram ou se aplicam a você, chegou a hora de tentar usar alguns métodos mais obscuros, maquiavélicos e perversos.

CUIDADO: O uso inescrupuloso dos métodos abaixo pode fazer com que você passe o resto da eternidade queimando nos mármores do inferno. Você foi avisado.

Local: Hotspots pagos em geral (Aeroportos, Cafés, etc), Dial up 0800 que alguns provedores oferecem para a assinatura do serviço (Lembra dos CDs da AOL?)  ou redes administradas diretamente por algum ditador comunista.

Problema: Você precisa urgentemente de acesso a internet. Não querem que você tenha acesso a internet enquanto você não abra a sua carteira ou aceite que o regime vermelho é futuro da nação.

Soluções:

Estas soluções consistem no princípio que quando sua conexão deveria estar bloqueada, como acontece quando você está conectado em um hotspot e tem acesso somente a página de boas-vindas da operadora ou para a compra de crédito, sua conexão não costuma estar completamente bloqueada. Na grande maioria dos casos apenas conexões TCP estão bloqueadas, que é o que pessoas comuns e mentalmente saudáveis usam para navegação. Você, por outro lado, pode se aproveitar de que outros tipos de tráfego costumam ser “esquecidos” de ser bloqueados pelos administradores, como UDP, ICMP e DNS – E sim, você também pode usa-los para navegar com os métodos abaixo:

Método 3: OpenVPN Server na UDP 53.
Possívelmente a solução mais simples possível.
Em geral essas redes não restrigem tráfego UDP, principalmente na porta 53, geralmente utilizada para servidores de nomes. Você pode muito bem rodar a OpenVPN em seu servidor, fazendo com que ele ouça na porta 53 UDP – E conseguir conectar a VPN sem grandes problemas a partir dessas redes.
Para verificar se tal façanha é possível, basta verificar se você consegue se comunicar com um servidor de DNS Externo ao da rede que voc6e se encontra. Por exemplo:

nslookup www.uol.com.br – 208.67.220.220
Server:         208.67.220.220
Address:        208.67.220.220#53

Non-authoritative answer:
Name:   www.uol.com.br
Address: 200.221.2.45
Name:   www.uol.com.br
Address: 200.98.249.12

Neste exemplo, a partir de minha rede, me comuniquei diretamente com o servidor de DNS 208.68.220.220 (da OpenDNS) por UDP 53, e tive sucesso na resolução de nome. Significa que a comunicação UDP/53 está liberada e eu poderia me conectar normalmente através do OpenVPN.

Contudo, se a saída for como essa:

nslookup www.uol.com.br – 208.67.220.220
;; connection timed out; no servers could be reached

Significa que o tráfego UDP/53 está sendo bloqueado e você deve tentar um dos próximos métodos.

Método 4: TCP Over DNS

Aqui a coisa comeca a ficar interessante. Ja imaginou a possibilidade de trafegar qualquer tipo de dados apenas usando o sistema de DNS? Isso me ocorreu justamente da ultima vez que conectei em um hotspot num aeroporto, e quando fui pesquisar sobre, descobri que o conceito era bem mais velho do que eu imaginava.

Existem diversas implementacoes de TCP over DNS, sendo as mais famosas: Ozymandns (com um fork aqui), NSTX, entre outras. Andei brincando um pouco com elas, e a que trouxe melhores resultados foi a da Analogbit, feita em Java.

Nao da para esperar muito da performance, e bem, na pratica voce so vai conseguir uma conexao extremamente lenta, ainda assim, e melhor que nada. Trata-se mesmo do ultimo recurso.

Método 5: TCP Over ICMP