Managing cached connections

I'm developing a script to failover different links when one of them fails. After some tests I could see some strange behavior. After changing the routing table, flushing the route cache, removing the NAT rule and creating a new one to satisfy the new link, the packets were going out through the new interface(specified in the new route) but using the translated IP address of the old NAT rule.

After some research I found out that linux kernel keeps a kind of cache for all connections, maybe just the NATed ones?!

The nice thing is you can see this table:

cat /proc/net/ip_conntrack

The netfilter team also developed a tool to manage this table, flush, list, delete, add entries, etc.
It's called conntrack-tools. It's a replacement for the /proc interface. What you will need is to compile and install the following:


libnfnetlink
libnetfilter_conntrack
conntrack-tools

You can download all the sources from:
http://conntrack-tools.netfilter.org/downloads.html

After installed you can call the conntrack binary.
I.e.:

conntrack -L -d x.x.x.x

The above command list all entries with x.x.x.x destination IP.

conntrack -F

The above command flushes the whole table. That's exactly what I have to do in order in my fail-over scripts.

conntrack -L -m 11

If you're using the MARK target in any iptables rule you can check out if the packets are being marked correctly with the above command. This command list all the connections with mark=11(-j MARK --set-mark 11)

References:

http://linux.derkeiler.com/Mailing-Lists/Debian/2005-08/3411.html
http://lists.netfilter.org/pipermail/netfilter-devel/2002-October/009530.html
http://mailman.ds9a.nl/pipermail/lartc/2003q1/007249.html
http://linux.die.net/man/8/conntrack
http://www.mail-archive.com/netfilter-devel@lists.samba.org/msg01394.html
http://conntrack-tools.netfilter.org/downloads.html

Playing with ip command

ip -o -s -s route show table cache

Existe um tabela chamada "cache" que nem preciso dizer que ela contém o cache :)

com a opção -s é exibido a idade(age), em segundos, daquela entrada, quantas vezes aquela regra foi usada(used), etc.

A opção -o é só pra mostra tudo em uma linha só. Fica mais fácil de fazer grep ou wc -l

A idade é zerada toda vez que aquela regra é usada e a o valor used é incrementado.

Não consegui determinar de quanto em quanto tempo essa tabela é esvaziada. Apenas determinei que de tempos em tempos ela é completamente zerada e reiniciada. Uma vez que eu acompanhei demorou algo em torno de 8 minutos, de uma outra vez 3:30min, depois 4 min cravados. Então o mais certo é: vai saber né?

o importante é lembrar que quando se alterar rotas ou rules é importante limpar essa tabela de cache com o comando:

ip route flush cache

ou

ip r f c

Do contrário você vai morrer tentando e não vai entender o comportamento do seu linux roteando.


Vou só incluir alguns comando aqui de exemplo que serão úteis logo logo:

ip rule show

ip rule add from 192.168.0.0/24 table 10
ou
ip rule add from 192.168.0.0/24 table dez
ou
ip rule add from 192.168.0.0/24 lookup 10
ou
ip rule add from 192.168.0.0/24 table dez

Observações:
lookup ou table podem ser usado interchangeable.

o Nome ou número da tabela no arquivo /etc/iproute2/rt_tables também podem ser usados interchangeable.

ip rule from 10.1.1.0/22 lookup WAN
ip rule to 200.0.0.1/24 lookup ADSL


Usando marcas(lembrando que o pacote não é alterado de forma alguma, essa marcação quem toma conta é o kernel, como se fosse NAT, pois existem uma tabela, porém no NAT o pacote ainda é alterado, nesse caso não):

iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -j MARK --set-mark 10
ip rule add fwmark 10 table GVT

Se você realmente deseja alterar o pacote deve usar o alvo TOS do iptables(não testei):


iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -j TOS --set-tos 0x10

tente: iptables -j TOs -h para descobrir as opções do --set-tos

ip rule add tos 0x10 lookup 10


Quando você for listar as rules você verá que surge na tela 'lowdelay' ao invés do valor 0x10. Isso porque o ip traduz e/ou mapeia isso de acordo com o arquivo /etc/iproute2/rt_dsfield

ip route get 192.168.1.55

Will pretend sending a packet to this destination resolve and get back the route that will be used to reach the destination. It actually creates an entry into the cache table. Check it out with ip route show cache

As the manual says it's equivalent to send a ping and running ip route show cache.

Gtalk liberado para poucos

Introdução:

Recentemente postei a respeito do bloqueio do Gtalk integrado no Gmail. Consegui bloquear o acesso.
Não demorou uma semana e tem gente aqui na empresa que arrumou uma justificativa pra usar o mesmo... hehehe
assim como já tiveram aqueles que justificaram o uso do google earth.. uaheua mas enfim.. eu só executo ;-)

Meu cenário:

                                                          `.....`    
                                                         ```     `..  
                                                       `-           - 
`````````````                                         ````            `-`
-           -                                         .`                  `.`
-   LAN     -                                         `.  .   Internet      -
-           -                                         ..                     `.
-           -                                          :                   -`
```````:`````                                          -                  `.
   -                                               .`       ...``````.`
   -                                                `.````..`   ````  
   -                  .```````````````-               ````-           
   -                  -               -                   -           
   -                  -               -                   -           
   -                  -   FIREWALL    -                   -           
   ..````````````````.:       +       -```````````````````-           
                      -  Proxy(Squid) -                               
                      -    ` ``````   -                               
                      -               -                               
                      -               -                               
                      .```````````````.                               

O desenho eu coloquei só porque achei bunitinho e dá um outro ar ao blog =)

Como as coisas funcionam:

Todas as conexões são encaminhadas para o proxy. Ele por sua vez, acessa o conteúdo na "rua" e devolve pra quem fez a solicitação. Portanto, os clientes que estão atrás do proxy não tem contato direto com a internet. Isso todos sabemos =)

Portanto para bloquear o Gtalk quando se está usando um proxy é só negar na Chain OUTPUT o acesso a chatenabled.mail.google.com(acho que é isso). Com isso o proxy não vai conseguir consultar a internet.


Problema:

Como eu disse no início eu preciso fazer a liberação o Gtalk para algumas criaturinhas aqui, lê-se usuários. =)


Façamos uma análise:

Quem acessa a internet é o Squid e não o cliente diretamente. certo?! sim.

Quando alguém quiser teclar no GTalk no pacote tcp o endereço de origem vai ser o do próprio squid ex.: 200.1.2.3 e o endereço de destino vai ser chatenabled.mail.google.com (64.233.185.189) por exemplo.
Pense comigo como eu vou poder liberar para um determinado IP se eu não tenho o IP de origem(do host na lan)?!? Quem tem o ip de origem é o squid, mas isso não me ajuda. A não ser que eu criasse um ACL no squid pra bloquear. Mas eu já tentei e não dá.

Se fosse na chain FORWARD(fosse só gateway e não proxy) era beleza. O IP de origem seria, por exemplo, 192.168.1.10 e o de destino seria chatenabled.mail.google.com(64.233.185.189). Perfeito!!!!


Pus-me a pensar:

...Não demorou muito, me imaginei um pacote tcp e logo achei uma solução.


Ressaltando:

Vou falar de novo para que fiquei bem claro: Todas as conexões são enviadas para o proxy sendo assim se eu bloquer a chain OUTPUT ninguém vai ter acesso ao Gtalk já que o proxy atende todo mundo.


A solução(vamos ser práticos):

No navegador do usuário devemos configurar o acesso ao endereço do Gtalk para que não seja usado proxy. Lá na configuração do navegador onde vai o endereço do proxy tem um espaço pra colocar os endereços que não devem passar pelo proxy(conexão direta com a internet). Coloca lá o endereço do Gtalk(chatenabled.mail.google.com).

Agora sim.. o navegador vai tentar conectar diretamente com a internet. Vamos ter esse pacote na chain FORWARD. Agora sim teremos um host da rede fazendo a solicitação diretamente ao endereço que deseja acessar.

Portanto, crie uma regra liberando esse host ao acesso. Ex:

iptables -A FORWARD -s 192.168.1.10 -d chatenabled.mail.google.com -j ACCEPT

Como o netfilter é stateful não precisa se preocupar criando uma regra pro pacote voltar.



Resumo:

No navegador sete para que não seja usado proxy para o endereço:
chatenabled.mail.google.com.

No firewall crie a regra liberado o host que pode ter acesso ao gtalk:
iptables -A FORWARD -s 192.168.1.10 -d chatenabled.mail.google.com -j ACCEPT

E a chain OUTPUT deve continuar negando para todos.


Espero ter conseguido expressar-me.