… alta disponibilidate “ethernet”

Neste pequeno artigo a idéia básica é ter uma interface virtual com duas interfaces de rede física, uma ativa e a outra desativada, caso a outra falhe. No linux esta facilidade em se configurar uma alta disponibilidade para a interface é chamada de bonding.

Isso na verdade só faz parte de uma solução com alta disponibilidade, já que para um servidor ser atrelado a uma infra-estrutura de alta disponibilidade, precisa de alguns componentes como um raid para os discos, fontes redundantes, etc.

O nome da interface pode ser algo específico, para cada usuário. Pode ser algo como bond0 ou algo similar. Lembrando que toda interface quandoé criada tem um MAC. No exemplo abaixo vamos agregar um mesmo MAC para ambas as interfaces.

Exemplo de configuração bonding

[root@real-server root]# modprobe bonding mode=1 miimon=100 downdelay=200 updelay=200
[root@real-server root]# ip link set dev bond0 addr 00:80:c8:e7:ab:5c
[root@real-server root]# ip addr add 192.168.100.33/24 brd + dev bond0
[root@real-server root]# ip link set dev bond0 up
[root@real-server root]# ifenslave  bond0 eth2 eth3
The interface eth2 is up, shutting it down it to enslave it.
The interface eth3 is up, shutting it down it to enslave it.
[root@real-server root]# ip link show eth2 ; ip link show eth3 ; ip link show bond0

4: eth2: <BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 100
  link/ether 00:80:c8:e7:ab:5c brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,NOARP,SLAVE,DEBUG,AUTOMEDIA,PORTSEL,NOTRAILERS,UP> mtu 1500
qdisc pfifo_fast master bond0 qlen 100
  link/ether 00:80:c8:e7:ab:5c brd ff:ff:ff:ff:ff:ff
58: bond0: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue
  link/ether 00:80:c8:e7:ab:5c brd ff:ff:ff:ff:ff:ff

Note que há uma nova saída para o comando ip link show. E temos assim duas interfaces, sendo uma master e a outra slave que ser reportam a mesma direção. Também as interfaces Ehternet indicam uma interface mestere com nome de master bond0

Note também que as 3 interfaces tem o mesmo MAC ADDRESS.

… campus party

Começa nesta segunda 11 de fevereiro, o Campus Party, evento que integra a comunidade da Internet e comunicação e tecnologia. Em sua décima primeira edição, a feira ocorre até sábado dia 16 no prédio da Bienal do Ibirapuera, em São Paulo.

Esta é a primeira vez, que o evento ocorre fora da Espanha. Para mais informações: http://www.campus-party.com.br

… traceroute com icmp e tcp

Quando “debugamos” problemas em um rede, sempre utilizamos alguns comandos ou temos sempre uma mesmo direcionamento:

- ping para o host

- traceroute para o host

- conectar ao host

- …

Mas quando nos confrontamos com firewall em algumas partes da rede, eis que surgem os problemas. Pois muitos firewalls bloqueiam o protocolo ICMP, e outros pings e até mesmo o uso traceroute se torna obsoleto. Para estes casos surge uma ferramenta bem interessante , o TCPtraceroute (ou similares).

Situação:

Imaginem a situação:Alguém esta tentando enviar um e-mail, porém esta tentando saber o porque o mesmo não está sendo enviado. O servidor está com o nome de BRUMAIL, e esta disposto em uma DMZ. Infelizmente não temos acesso as configurações do firewall, para verificar se há ou não uma regra barrando o tal acesso.

Passos para se debugar o fato relatado:

Segundo o que havíamos comentando inicialmente, as primeiras tentativas se baseiam exclusivamente nas 3 principais ferramentas: ping, traceroute, netcat

O teste de verificar se o host está sendo alcançado, ou mesmo ha resposta se baseia no ping, e veja o resultado:

$ ping -c 2 193.190.255.40
PING 193.190.255.40 (193.190.255.40) 56(84) bytes of data.

--- 193.190.255.40 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms

O ping realmente não foi produtivo, já que nem mesmo nos retornou qualquer resposta. Então no tentamos utilizar o segundo comando traceroute:

$ tracepath -n 193.190.255.40
 1:  213.251.167.209   0.200ms pmtu 1500
 1:  213.251.167.252   0.819ms
 2:  213.186.32.1      0.634ms
 3:  213.186.32.4    asymm  2   2.467ms
 4:  194.68.129.183   16.559ms
 5:  193.191.1.1      16.443ms
 6:  193.191.1.174    17.083ms
 7:  no reply
 8:  no reply
 9:  no reply

Neste caso, tivemos um resultado para os 7 primeiros hops. Mas o hop 7 não nos mostra nada, e o firewall provavelmente nos anula qualquer resultado conclusivo. Neste caso, vamos utilizar o comando seguinte, o netcat, já que um acesso a porta do servidor de e-mail poderá ser algo bem mais conclusivo do que as tentativas anteriores.

$ nc -n -vv 193.190.255.40 25
(UNKNOWN) [193.190.255.40] 25 (smtp) : Connection timed out
 sent 0, rcvd 0

$ nc -n -vv 193.190.255.40 80
(UNKNOWN) [193.190.255.40] 80 (www) open
 sent 0, rcvd 0

Assim, verificamos que o nosso webserver esta rodando. E que o serviço de SMTP, ao qual havíamso inicialmente validar, está fora do ar. Infelizmente dizer para todos que a resposabilidade é do firewall, pode ser algo ainda prematuro, pois como na maioria dos lugares dirão que o firewall está configurado corretamente.

A solução:

TCPtraceroute (ou outras variantes) é a solução. Em comparação com o traceroute normal, tcptraceroute não usa pacotes ICMP. Mas ainda assim usa o principio o TTL para os hops, porém com pacotes TCP.

A grande questão é que os pacotes TCP, sempre são liberados nos firewall e não bloqueados com o ICMP. A resposta para as tentativas anteriores, para acesso ao webserver e ao SMTP seguem abaixo com a nova ferramenta.

$ tcptraceroute -i eth0 -n 193.190.255.40 80
Selected device eth0, address 213.251.167.209, port 53545 for outgoing packets
Tracing the path to 193.190.255.40 on TCP port 80 (www), 30 hops max
 1  213.251.167.252  0.522 ms  0.378 ms  0.544 ms
 2  213.186.32.1  0.475 ms * 5.214 ms
 3  213.186.32.4  0.657 ms * 1.252 ms
 4  194.68.129.183  15.986 ms  16.138 ms  15.946 ms
 5  193.191.1.1  15.824 ms  16.130 ms  16.017 ms
 6  193.191.1.174  16.204 ms  16.683 ms  16.917 ms
 7  193.191.9.29  17.168 ms  17.091 ms  17.676 ms
 8  193.190.255.40 [open]  16.953 ms  17.342 ms  17.429 ms

Aguarde, e verá que diferentemente do traceroute neste caso, são mostrados todos os hops além dos apenas 7, que tinhamos anteriormente. E ainda podemos assumir que o 193.191.9.29 é um fiewall. E imediatamente testaremos o serviço SMTP (Porta 25).

$ tcptraceroute -i eth0 -n 193.190.255.40 25
Selected device eth0, address 213.251.167.209, port 57399 for outgoing packets
Tracing the path to 193.190.255.40 on TCP port 25, 30 hops max
 1  213.251.167.252  0.504 ms  0.388 ms  0.396 ms
 2  213.186.32.1  0.292 ms * 6.403 ms
 3  213.186.32.4  0.977 ms * 0.691 ms
 4  194.68.129.183  16.052 ms  15.803 ms  15.862 ms
 5  193.191.1.1  16.088 ms  16.021 ms  15.870 ms
 6  193.191.1.174  16.806 ms  16.505 ms  16.571 ms
 7  * * *
 8  * * *
 9  * * *

A conclusão:

A conclusão é simples. É provavel que o firewall esteja bloqueando conexões para a porta 25. Com estas informações, podemos convencer todos sobre a configurações errônea do firewall.Já que a justificativa se mostra é a seguinte, porque o pacote vai até o hop7 e não até temos resposta do 8 em diante? E se buscarmos pela porta 80 isso não acontece, e só acontece caso tentamos o STMP na porta 25? Bem ai, está a justificativa.

Espero ter ajudado e boa sorte.

… fedora 6 – proxy transparente

Um amigo estava tentando colocar o Fedora 6, como proxy transparente. Embora eu tenha também tentado e como á máquina estava em produção, preferi baixar uma versão 2.5 e instalá-la e seguir a mesma receita de sempre . Porém no Fedora 6 quando ele é atualizado, somos apresentado a uma nova versão do squid (2.6.x), e ai esta o problema, pois não é tão simples criar um proxy transparente…ao menos era o que eu achava !!!!

Mas esta aí a dica do Moisés Coffani, que após várias tentativas também achou o pulo do gato !!

Veremos que é mais simples do que a gente imaginava:

1. Abra o arquivo /etc/squid/squid.conf e procure pela opção http_port.

Ela deve ficar assim http_port <ip squid>:<porta> <transparent> . Exemplo:

http_port 192.168.0.254:3128 transparent

2. Procure a opcao always_direct allow all , onde esta opção deve ser habilitada, já que por default ela vem desabilitada. Então basta retirar o # da frente e pronto.

O resto é seguir os passos simples, de redirecionamento via iptables e habilitar o forward de pacotes.

Pronto, agora é só reiniciar a máquina e navegar.

Valeu Moisés, pela dica !!!

… demorei

É demorei um pouco para atualizar novamente o blog, mas saiba que também mereço férias..mas enfim, estamos de volta e pretendo dar continuidade ao projeto do blog, assim como as notícias relacionadas ao Fedora.

Mas durante estes dias, surgiram novas notícias sobre a distro, inclusive o codinome escolhido para a versão 9.0 do fedora, Surphur.

Opiniões á parte, eu gostei !!! Lembrando que caso alguém se interesse, pode mandar artigos para adamantina.rodrigo@gmail.com, que o quanto antes estarei postando no blog.

Obrigado e continuando….