Estou tentando criar um proxy transparente na minha máquina MacOS para portar o proxy sshuttle transproxy VPN baseado em ssh do Linux. Eu acho que quase tem funcionando, mas infelizmente, quase não é 100%.
Versão curta é isso. Em uma janela, inicie algo que escuta na porta 12300:
$ while :; do nc -l 12300; done
Agora ative o proxy:
# sysctl -w net.inet.ip.forwarding=1
# sysctl -w net.inet.ip.fw.enable=1
# ipfw add 1000 fwd 127.0.0.1,12300 log tcp from any to any
E agora teste:
$ telnet localhost 9999 # any port number will do
# this works; type stuff and you'll see it in the nc window
$ telnet google.com 80 # any host/port will do
# this *doesn't* work!
Após o último experimento, vejo linhas como esta no netstat:
$ netstat -tn | grep ^tcp4
tcp4 0 0 66.249.91.104.80 192.168.1.130.61072 SYN_RCVD
tcp4 0 0 192.168.1.130.61072 66.249.91.104.80 SYN_SENT
O segundo socket pertence ao meu programa telnet; o primeiro é mais suspeito. SYN_RCVD implica que meu pacote SYN foi capturado corretamente pelo firewall e recebido pelo kernel, mas aparentemente o SYNACK nunca foi enviado de volta para o telnet, porque ainda está em SYN_SENT.
Por outro lado, se eu matar o servidor nc, eu entendo isso:
$ telnet google.com 80
Trying 66.249.81.104...
telnet: connect to address 66.249.81.104: Connection refused
telnet: Unable to connect to remote host
... o que é o esperado: meu servidor proxy não está rodando, então o ipfw redireciona minha conexão para a porta 12300, que não tem ninguém escutando, ie. conexão recusada.
Meu nome diz isso:
$ uname -a
Darwin mean.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386
Alguém vê algum resultado diferente? (Estou especialmente interessado nos resultados do Snow Leopard vs Leopard, pois parece haver alguns rumores na Internet de que o transproxy está quebrado na versão do Snow Leopard) Algum conselho sobre como consertar?
Entendi! Não tenho certeza se é um bug no Snow Leopard ou algum novo recurso de segurança. Mas alguém postou na lista de discussão sshuttle a correção para o problema, que é simplesmente isso:
sysctl -w net.inet.ip.scopedroute=0
A execução desse comando faz com que o conjunto de comandos acima (na questão postada acima) funcione corretamente como no MacOS 10.5. Assim, o proxy transparente funciona novamente.
Eu me deparei com todos os tipos de problemas estranhos com o ipfw enquanto faço coisas como essa, e geralmente a razão está relacionada ao fato de que as coisas passam pela mesma regra em ambas as direções, quando você realmente quis dizer apenas uma. regras de desvio + natd pode ser especialmente complicado para acertar.
Eu não tenho tempo para brincar com isso por agora, mas você pode querer tentar criar um conjunto de regras que cause pacotes de telnet - > {tudo} para acertar a regra do fwd, mas não o nc - > pacotes telnet.
A única coisa que posso fazer é adivinhar aqui, apenas me intrometer: P
Então, meu palpite é que o 10.2 de Avery ainda não foi corrigido para o bug: link
Também descrito em kerneltrap.org/mailarchive/freebsd-current/2007/11/20/431855
Enquanto 10,5 já é. Faz sentido para mim, dadas as datas de lançamento de Darwin. Acho que vamos descobrir quando o emaste o executa em alguma versão mais antiga também. De qualquer forma, eu não corro um BSD ou Darwin, acabei de entrar no post do blog da Avery: P