Proxy Transparente + Conectividade Social + IPFilter no NetBSD
A Conectividade Social é um aplicativo que fornece serviços geralmente utilizados pelo setor pessoal de uma empresa para entrega do SEFIP, pedir extratos do FGTS, guia do INSS e coisas do tipo. Resumindo: O setor pessoal NECESSITA da conectividade.
O acesso à Internet coloca ao alcance dos usuários de uma empresa informações ou conteúdos que geralmente são inconvenientes para a empresa (sites pornográficos, download de música, livros piratas e afins). Para evitar isso se usa Proxys que são sistemas capazes de bloquear acesso a conteúdos indesejados pela política ou necessidade da empresa. Resumindo: A empresa NECESSITA de um PROXY.
A Conectividade Social (CS) não se comporta muito bem quando passa por um Proxy. Isso se dá por que o fluxo de comunicação da CS acontece via porta 80 (HTTP), mas o seu conteúdo é criptografado (HTTPS). É! eles fugiram do padrão, e quando isso é feito, o que acontece? Isso mesmo: PROBLEMAS, INCOMPATIBILIDADE. E sobra sempre pra nós, administradores que independente de quem errou, temos que fazer a coisa funcionar.
Se você usa o IPTables, bem provável achará a solução para esse problema num piscar de olhos. Mas se precisa resolver esse problema usando IPFilter, acredito que esse é o primeiro, e até agora o único lugar que você poderá encontrar a informação que procura. No IPFilter é um pouco mais complicado por causa da estrutura que o NAT e o Firewall é organizada e a ordem de fluxo do pacote: http://coombs.anu.edu.au/~avalon/ipfil-flow.html ou seja, uma regra de firewall, diferentemente do IPTables, não resolveria o nosso problema. Temos de resolver isso na regra de NAT mesmo.
Em fim vamos à solução:
O Proxy Transparente funciona com a idéia básica de que todo pacote que for sair pra a Internet, deve ser redirecionado para a porta do Proxy antes, a fim de que o conteúdo seja inspecionado e, a depender da regra contida no Proxy, o trêfego será liberado ou não. No IPFilter a regra de redirecionamento desses pacotes é algo mais ou menos assim:
rdr rtk0 from any to any port = 80 -> 127.0.0.1 port 3128
rtk0 seria a interface da rede interna, 127.0.0.1 funcionaria nesse caso pois o Proxy está instalado na mesma máquina onde está o Firewall (caso fosse em máquina diferente, bastaria colocar o respectivo endereço), a porta 3128 é a porta padrão que o Squid Proxy escuta.
Já que a CS não pode passar pelo nosso filtro teremos que desviar o fluxo toda vez que o destino for caixa econômica federal (generalizei, poderia ser apenas pra o IP da CS), para evitar que ele passe pelo Proxy. Para isso teríamos que fazer um redirecionamento condicional, mas como não encontrei um modo de fazer isso, dei um jeito fazendo redirecionamento direto para o destino.
Para isso eu precisei coletar os endereços IP que estavam relacionados à conexão com a caixa até o fim da transação entre o setor pessoal e a CS. Foi um trabalho chato e meio vergonhoso usando o tcpdump, o grep, o resolvip e uma funcionária do setor pessoal (obrigado pela paciência Claudia). Mas os IPs resultantes desse trabalho fora:
200.201.173.68, 200.201.166.200, 200.201.166.240, 200.201.162.21 e 200.201.174.207
Sendo assim, agora precisamos apenas garantir que, toda vez que a comunicação for ser feita com um desses endereços, o fluxo passe direto, sem que o Proxy nem ao menos sinta o cheiro desses pacotes. Ou seja, um redirecionamento direto para o destino. De forma lógica eu concluí que deveria ser posta antes da regra de redirecionamento geral para a porta 3128, uma outra regra, que seria mais restritiva, assim:
rdr rtk0 from 0/0 to 200.201.173.68/32 port = 80 -> 200.201.173.68 port 80
rdr rtk0 from 0/0 to 0/0 port = 80 -> 127.0.0.1 port 3128
Assim tudo seria enviado para a porta 3128 de meu squid, EXCETO o que fosse para o endereço 200.201.173.68, por que quando o pacote chegasse na interface (rtk0) e o firewall fosse checar a regra de NAT pra ele, a primeira regra (que por padrão será aceita) é: MANDE ISSO PRA O DESTINO. Logo o pacote não passa pelo Proxy. SIMPLES! Todos os outros pacotes não iriam casar com a primeira regra, logo iriam passar pelo Proxy. Então o meu arquivo de NAT completo ficou assim:
firewall@~#cat /etc/ipnat.rules
map rtk1 192.168.0.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:60000
map rtk1 192.168.0.0/24 -> 0.0.0.0/32
################################################################
# SQUID #
################################################################
rdr rtk0 from 0/0 to 200.201.173.68/32 port = 80 -> 200.201.173.68 port 80
rdr rtk0 from 0/0 to 200.201.166.200/32 port = 80 -> 200.201.166.200 port 80
rdr rtk0 from 0/0 to 200.201.166.240/32 port = 80 -> 200.201.166.240 port 80
rdr rtk0 from 0/0 to 200.201.162.21/32 port = 80 -> 200.201.162.21 port 80
rdr rtk0 from 0/0 to 200.201.174.207/32 port = 80 -> 200.201.174.207 port 80
rdr rtk0 0/0 port 80 -> 127.0.0.1 port 3128
Feito isso, basta recarregar o ipnat e tudo estará lindo: /etc/rc.d/ipnat forcerestart. Agoravocê pode continuar a bloquear acesso a conteúdo impróprio, e o setor pessoal continuará funcionando!
Espero ter sido claro na explicação e ter te ajudado. Caso haja alguma dúvida ou correção, estou à inteira disposição para ajudar: alancordeiro@gmail.com. Agradeço a todos que colaboraram e tentaram me ajudar na época (Alan Jumpi). Fica aí minha parcela de contribuição.
Of course it runs NetBSD
Alan MeC Lacerda,
:wq!
