Discuta este tópico no fórum

Se este conteúdo te ajudou, deixe um presente!

quinta-feira, 8 de dezembro de 2011

Atendimento Eletrônico da Anatel com suporte para Firefox

Quem tentou usar no passado o atendimento eletrônico da Anatel a partir do Linux provavelmente esbarrou na limitação da aplicação que somente funcionava em Internet Explorer. Para usuários M$ Windows, era somente o caso de trocar o navegador enquanto para os usuários Linux, a solução possível seria extremamente exótica (como rodar o IE no wine).

Bem, era extremamente frustrante que, após não resolver o problema com a Telecom (por sinal, no meu caso, era a Oi), você não consiga nem mesmo reclamar com a Anatel. Como eu estava realmente indignado, resolvi ir ao limite para tentar sanar o problema. Inicialmente, o primeiro passo seria entrar em contato com a Ouvidoria da Anatel e informar do problema. Para a minha surpresa, até mesmo a ouvidoria usava o mesmo sistema do atendimento eletrônico! E, para ajudar, não achei, na época, outra forma de contato que não seja o telefônico. Para utilizar o meio eletrônico, eu teria que "subir o nível".

Pensei no Ministério das Telecomunicações. Contudo, estudando um pouco, encontrei que a "...a agência tem independência administrativa e financeira e não está subordinada a nenhum órgão de governo". Investigando mais um pouco, cheguei em alguém que poderia me ajudar: Controladoria Geral da União (CGU).

Entrando na página da controladoria, consegui facilmente relatar o problema encontrado. Os argumentos foram simples. A exigência do uso do IE daria privilégios a uma empresa (Micro$oft) sem qualquer motivo ou concorrência pública. Para usar legalmente o sistema da Anatel, eu teria que comprar uma licença do produto, ou utilizar uma cópia ilegal, que seria "contra a lei". Isto estaria restringindo os direitos de cidadão dos não clientes da Microsoft. Além de tudo, a limitação não teria qualquer justificativa pois existem outros navegadores de alta qualidade no mercado (que inclusive são mais usados do que o IE), compatíveis com diversos sistemas operacionais, além da compatibilidade com a crescente onda dos dispositivos móveis. Por fim, ainda o uso de recursos limitadores fora dos padrões vai contra a orientação do Padrões de Interoperabilidade de Governo Eletrônico (E-ping). Para quem não conhece, o E-ping define diversas normativas de soluções de TI para o Governo como protocolos e formatos de documentos, inclusive adotando o ODT. É de caráter obrigatório para o Poder Executivo mas o Judiciário também aderiu voluntariamente.

Em pouco tempo, recebi por e-mail a resposta da CGU:



Prezado Senhor,

                        Acuso o recebimento da manifestação em referência, originada de correspondência eletrônica em que Vossa Senhoria reclama sobre a restrição de acesso ao atendimento eletrônico da Agência Nacional de Telecomunicações/ANATEL que exigiria do usuário a utilização de determinado navegador de internet para utilização dos seus serviços.
2.                     Considerando a natureza da matéria ali abordada, informo que sua manifestação foi enviada, nesta data, à ouvidoria daquela Agência para conhecimento, providências e oportuna comunicação com Vossa Senhoria, bem como à Secretaria-Executiva do Governo Eletrônico, a título de colaboração na implementação do programa.
                        Atenciosamente,




RICARDO GARCIA FRANÇA

Assessor do Ouvidor-Geral da União



Alguns meses se passaram e, algumas semanas atrás, testei novamente o sistema utilizando o navegador Google Chrome. Para minha surpresa, consegui avançar em muito em relação às limitações que eu enfrentei no passado. Porém, ainda assim  não conclui um cadastro pois existe algum problema com a consulta do CEP. Poucos dias depois, recebo a tão aguardada resposta da Anatel:

Prezado Sr. Luiz Ângelo Daros de Luca,
1.          Em atenção ao Ofício nº 21531/2011/OGU/CGU-PR, encaminhado à Anatel e recebido no dia 05 de agosto de 2011, referente à sua reclamação de restrição de acesso ao sistema FOCUS, informamos que já se encontram em produção desde o dia 13 de outubro as alterações inerentes a cadastro de entidade externa com compatibilidade com os navegadores Mozilla Firefox e Microsoft Internet Explorer. Tais alterações visaram aprimorar os processos de atendimento eletrônico da ANATEL, e aproveitamos para agradecer o contato.
2.          Informamos ainda que estamos trabalhando em outras alterações visando compatibilizar o acesso ao atendimento com o navegador Google Chrome, com previsão de conclusão para o dia 9 de dezembro próximo.
3.          Informamos também que o tratamento relativo ao Sr. Evandro de Andrade Bastos, referente à mudança de plano e aparelho já foi encaminhada à área competente e terá o devido retorno.
4.          Pedimos desculpas pelo inconveniente causado e nos colocamos a disposição para quaisquer esclarecimentos.

Bingo! O problema foi solucionado! Testei o cadastro com o Mozilla Firefox e tudo funcionou sem qualquer problemas. O problema que eu enfrentei com o Google Chrome já é conhecido e, segundo a resposta, já estão trabalhando na solução. De qualquer maneira, dou-me por satisfeito com a opção do Firefox.

Fica a lição de que "reclamar resolve". Mas não com os seus colegas. Reclamem com os tomadores de decisão da instituição, que em geral não estão cientes do problema e, no caso das públicas, até mesmo da orientação do Governo Federal. Se o caso for com uma empresa privada, deixe claro que você tentou comprar/contratar o serviço e não conseguiu. Se isto chegar aos ouvidos dos interessados, eles irão escutar. A falta de compatibilidade é, em geral, descuido do desenvolvimento e vai fornecer aos tomadores de decisão os argumentos para discutirem com a equipe de TI.

Por fim, muito obrigado a CGU e a Anatel pela resposta ao problema. Apesar dos meses para a solução e do aviso de sua disponibilidade, sei que isto é, em parte, dos problemas do trâmite administrativo dentro de uma instituição pública. Porém, ainda assim, o prazo foi comparável ou até mais favorável do que o encontrado com diversos problemas de soluções de "referência" no mercado.

terça-feira, 27 de setembro de 2011

Twice NAT: Comunicando redes com o mesmo endereço utilizando Cisco ou Linux

As boas práticas recomendam que as mudanças no ambiente de produção sejam planejadas, documentadas e testadas antes de serem implementadas. Estes testes, quando possível, são realizados em um ambiente de homologação, ou pré-produção, para evitar qualquer impacto na qualidade dos serviços disponibilizados. Uma das características importantes de um bom ambiente de homologação é a sua semelhança com a produção. Quanto maior esta semelhança, mais problemas poderão ser detectados antes de afetar os usuários.

Um dos pontos interessantes para ser replicado é a configuração de rede. Assim, uma máquina poderia migrar entre o ambiente de produção e homologação sem mudanças, nem mesmo na configuração da rede. Alguém pode perguntar: os endereços IP e, ainda mais, as redes não deveriam ser únicos dentro de uma mesma rede local? Sim, caso contrário, o roteador não saberia para qual das duas redes enviar os pacotes. Deixar as duas redes desconectadas uma da outra também não é uma boa solução. Não é muito prático enviar dados pelo protocolo PPCPPL (pendrive para cá, pendrive para lá). Vejamos o problema de duas redes com endereços conflitantes. O roteador, ao receber um pacote do computador 10.1.2.2 para 10.1.1.2, não teria como escolher entre as duas redes 10.1.1.0/24:

 10.1.1.0/24 (homolog)
 ----------------------+-------------------------------
                       |
                  +----+----+               10.1.2.0/24
                  |Roteador +--------------------------
                  +----+----+
                       |
 ----------------------+-------------------------------
 10.1.1.0/24 (produção)



O primeiro passo da solução é isolar as duas conexões do mesmo roteador. Com o auxílio de um segundo roteador, a conexão fica desta forma:


 10.1.1.0/24 (homolog)

 ----------------------+-------------------------------
                       |
                       |fa0/0
                  +----+----+              
                  |Rot. Aux +
                  +----+----+
                  fa0/1|
                       |
                       |10.1.99.0/30
                       |
                  fa0/1|
                  +----+----+               10.1.2.0/24
                  |Roteador +--------------------------
                  +----+----+
                       |fa0/0
                       |
 ----------------------+-------------------------------
 10.1.1.0/24 (produção)


Entre os dois roteadores, foi configurada uma rede de dois endereços 10.1.99.0/30. Caso 10.1.2.2 envie um pacote para 10.1.1.2, o roteador não teria dúvidas em enviá-lo para a rede de produção. Agora, como 10.1.2.2 poderia falar com um outro computador com o mesmo endereço mas na rede de homologação? A solução é utilizar a tradução de endereços (NAT).


Em uma NAT, o endereço do pacote é mapeado para outro endereço alcançável pelo destinatário. Quanto ele deixa a rede abaixo da NAT, o IP de origem é mascarado pelo endereço do roteador. Na volta, o IP de destino é traduzido de volta para o endereço da Intranet.



 200.123.123.44 (Internet)
 ----------------------+-------------------------------
                       |
                  +----+----+
                  |Roteador |
                  +----+----+
                       |
 ----------------------+-------------------------------
 10.1.0.0/24 (intranet)


No caso do problema das duas redes internas conflitantes, esta tradução pode ser feita estaticamente, mapeando os endereços 1 para 1. Por exemplo: uma rede de mesmo tamanho da rede de homologação é reservada para ser o "alvo virtual" das redes conflitantes. Usaremos neste caso a rede 10.1.66.0/24. Quando 10.1.2.2 quer enviar um pacote para o computador 10.1.1.2 da rede de homologação, ele enviaria o pacote para o endereço correspondente da rede alvo. Se o mapeamento da rede alvo e da rede de homologação estiver na sequência, este seria 10.1.66.2. Exemplos:
  • 10.1.66.1 para 10.1.1.1
  • 10.1.66.2 para 10.1.1.2
  • 10.1.66.20 para 10.1.1.20
Os pacotes seriam enviados ao roteador e, com o auxílio de uma configuração de rota, enviados ao roteador auxiliar. Este realizaria a tradução de endereços e a comunicação estaria estabelecida.
  1. 10.1.2.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
    1. 10.1.2.2 -> 10.1.66.3
  2. O roteador principal envia o pacote para o roteador auxiliar.
    1. 10.1.2.2 -> 10.1.66.3
  3. No roteador auxiliar, ocorre a tradução de endereço de destino. Neste caso, o destino passa para 10.1.1.3:
    1. 10.1.2.2 -> 10.1.1.3
  4. O roteador auxiliar envia o pacote pela rede de homologação.
    1. 10.1.2.2 -> 10.1.1.3
Agora, e se existir a necessidade de comunicação entre a rede de produção e de homologação? Se a máquina 10.1.1.2 da rede produção necessitasse enviar um pacote para a 10.1.1.3 da rede de homologação, ela poderia utilizar a mesma estratégia de enviar para a rede alvo. Contudo, a resposta nunca chegaria. Quando a máquina 10.1.1.3 da rede de homologação fosse responder o pacote, pelo endereço de origem, esta o enviaria para a máquina 10.1.1.2 de sua própria rede (homologação). A solução para este problema é a utilização do NAT duas vezes, em inglês "Twice NAT" ou NAT "Overlapping".


No "Twice NAT", ou "Nat duas vezes", em um envio do pacote, a tradução dos endereços deve ocorrer duas vezes: uma para o endereço de destino, como na NAT tradicional, e outra para o endereço de origem.

O fluxo do pacote do exemplo anterior, 10.1.1.2 da rede produção para a 10.1.1.3 da homologação seria algo como:

  1. 10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
    1. 10.1.1.2 -> 10.1.66.3
  2. O roteador principal envia o pacote para o roteador auxiliar.
    1. 10.1.1.2 -> 10.1.66.3
  3. No roteador auxiliar, ocorre a tradução de endereço, tanto do emissor como do receptor. Neste caso, o destino passa para 10.1.1.3:
    1. 10.1.55.2 -> 10.1.1.3
  4. O roteador auxiliar envia o pacote pela rede de homologação.
    1. 10.1.55.2 -> 10.1.1.3
O retorno seria o mesmo processo mas em ordem inversa. Para a rede de homologação, a rede "alvo" da produção é a 10.1.55.0/24. Caso os roteadores sejam Cisco, a configuração do roteador auxiliar seria algo como:

interface FastEthernet0/0
 ip address '''10.1.1.1''' 255.255.255.0
 ip nat '''inside'''
!
interface FastEthernet0/1
 ip address '''10.1.99.1''' 255.255.255.252
 ip nat '''outside'''
! Os proximos, um para cada equipamento da rede!!!
! 10.9.1.1 
ip nat inside source static 10.1.1.1 10.1.55.1 
ip nat outside source static 10.1.1.1 10.1.66.1
! 10.9.1.2 
ip nat inside source static 10.1.1.2 10.1.55.2 
ip nat outside source static 10.1.1.2 10.1.66.2 

Um fato interessante é que as duas redes alvo poderiam compartilhar o endereço sem problemas. A rede alvo a partir da produção para a rede de homologação e a rede alvo a partir da homologação para a produção poderiam ser ambas 10.1.66.0/24. Não existe conflitos.


Como nem todos possuem a possibilidade de utilizar dois roteadores Cisco, vamos também trabalhar no mesmo problema com um servidor Linux.



10.1.1.0/24 (homolog)
 ----------------------+-------------------------------
                       |
                       |eth1
                  +----+----+              
                  |Rot. Aux +
                  +----+----+
                   eth0|
                       |

                       |10.1.99.0/30
                       |
                   eth0|
                  +----+----+               10.1.2.0/24
                  |Roteador +--------------------------
                  +----+----+
                       |eth1
                       |
 ----------------------+-------------------------------
 10.1.1.0/24 (produção)

Diferente do Cisco, o Linux não consegue realizar a tradução dupla do endereço de origem e destino. No Linux, a tradução do NAT é feita pelas tabelas nat do iptables. Elas possuem 3 chains: PREROUTING, POSTROUTING e OUTPUT. OUTPUT é utilizado pelos pacotes originados dentro do próprio roteador e não é interessante para nosso caso. Quanto aos outros dois, o fluxo de encaminhamento do pacote é o seguinte:
  1. O pacote é capturado pela placa de rede
  2. Regras do PREROUTING
  3. Roteamento
  4. Regras do POSTROUTING
  5. O pacote sai pela interface escolhida
Nesta sequência, existe algumas limitações. O Linux pode fazer o mascaramento tanto dos endereços de origem como de destino. Porém, cada um é feito exclusivamente em uma etapa. No PREROUTING, apenas o endereço de destino pode ser mascarado. No POSTROUTING, apenas o de origem. Isto gera um problema interessante para o roteamento. Vamos rever o exemplo da máquina 10.1.1.2 da rede produção enviando pacotes para a 10.1.1.3 da homologação, mas com roteador Linux:
  1. 10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
    1. 10.1.1.2 -> 10.1.66.3
  2. O roteador principal envia o pacote para o roteador auxiliar.
    1. 10.1.1.2 -> 10.1.66.3
  3. No roteador auxiliar:
    1. O pacote é capturado pela placa de rede eth0.
      1. 10.1.1.2 -> 10.1.66.3 
    2. Regras do PREROUTING
      1. 10.1.1.2 -> 10.1.1.3 
    3. Roteamento
Neste ponto o Linux deve rotear o pacote de 10.1.1.2 para 10.1.1.3, originado da interface eth0. Porém, isto é uma anomalia. A rede 10.1.1.0/24 é da interface eth1 e pacotes originados desta rede não podem entrar pela eth0. Isto é o famoso caso dos "martian source", que povoam o dmesg e logs dos mais desavisados. O pacote é descartado e nada acontece.

A solução é mascarar o endereço de origem antes de chegar no roteador com a interface 10.1.1.1/24 de homologação. Isto pode ser feito ainda no roteador principal ou em um terceiro roteador intermediário entre os dois. Com isto, o fluxo seria:

  1. 10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
    1. 10.1.1.2 -> 10.1.66.3
  2. Ainda no roteador principal ou no roteador intermediário, ocorre o mascaramento da origem.
    1. O pacote é capturado pela placa de rede eth0.
      1. 10.1.1.2 -> 10.1.66.3 
    2. Regras do PREROUTING
      1. nada acontece
    3. Roteamento
      1. É escolhida a rota para o roteador secundário
    4. Regras do POSTROUTING
      1. Endereço de origem é mascarado
      2. 10.1.55.2 -> 10.1.66.3
    5. O pacote sai para o roteador Secundário
  3. No roteador auxiliar, ocorre a tradução apenas do destinatário. Neste caso, o destino passa para 10.1.1.3:
    1. O pacote é capturado pela placa de rede eth0.
      1. 10.1.55.2 -> 10.1.66.3
    2. Regras do PREROUTING
      1. O destino é mascarado
      2. 10.1.55.2 -> 10.1.1.3
    3. Roteamento
      1. É escolhida a rota para a rede diretamente conectada
    4. Regras do POSTROUTING
      1. Nada acontece
    5. O pacote sai para o host 10.1.1.3 da rede de homologação
Se o objetivo é comunicação para ambos os sentidos, é necessário reproduzir as regras mas em ordem inversa. Uma vantagem para a configuração em Linux é que o mapeamento das redes alvo para a rede 10.1.1.0/24 pode ser feito por regra única e não uma por endereço de rede. Um dos destinos para o iptables é o NETMAP, que mascara um endereço de uma rede para outra.

Para o caso onde o roteador principal já realiza o mascaramento da origem, as configurações seriam:
 
Roteador principal:

iptables -t nat -A POSTROUTING -o eth0 -s 10.9.0.0/24 -j NETMAP --to 10.9.55.0/24
iptables -t nat -A PREROUTING -i eth0 -d 10.9.66.0/24 -j NETMAP --to 10.9.0.0/24


Roteador secundário:

iptables -t nat -A POSTROUTING -o eth0 -s 10.9.0.0/24 -j NETMAP --to 10.9.66.0/24
iptables -t nat -A PREROUTING -i eth0 -d 10.9.55.0/24 -j NETMAP --to 10.9.0.0/24

Claro, além disto, é necessário habilitar o ip_forward em ambos para eles atuarem como roteadores.
 
Assim como no caso do Cisco, as duas redes alvo poderiam ser a mesma. Se for o caso, e pela ordem das interfaces de rede, as configurações do mascaramento dos dois roteadores seriam idênticas.

Além deste exemplo para uso de ambiente de homologação e produção, esta mesma técnica pode ser aplicada em outros casos. Em algumas situações, duas intranets precisam ser interligadas (por exemplo, uma VPN) e, nos piores deles, ambas compartilham uma ou mais redes. Para evitar o custo da conversão dos endereços de toda uma rede, o "Twice NAT" permite a utilização de uma faixa de endereços falsos vaga para realizar o mapeamento.

sexta-feira, 29 de julho de 2011

Arranhando roteamento avançado em Linux

Esse é para as pessoas que algum dia já conectaram duas placas de redes em um equipamento Linux e nada funcionou direito...

O Linux é um sistema operacional versátil. Opera desde celulares a grandes computadores. Dentro deste espectro, ele também é muito utilizado como o coração de uma gama enorme de roteadores. Um Linux não faz feio frente a um roteador Cisco, só talvez não com o mesmo desempenho. Enfim, com Linux, qualquer computador se torna um roteador avançado. Basta adicionar mais interfaces de rede.

Um dos problemas comuns de conectar 2 placas de rede a um computador é em relação ao roteador padrão. Sempre existe apenas um roteador padrão. Para uma única interface, o que em geral é encontrado em um computador convencional, temos as seguintes rotas:

# ip route
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.11
127.0.0.0/8 dev lo  scope link
default via 192.168.1.1 dev eth0

A primeira é da rede diretamente conectada pela eth0, a segunda, o mesmo da primeira para a interface de loopback. E a última é a rota para as outras redes (o roteador padrão). Quando adicionamos uma segunda interface de rede, aparece mais uma rota diretamente conectada:

# ip route
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.11
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.22
127.0.0.0/8 dev lo  scope link
default via 192.168.1.1 dev eth0

Em geral, a segunda interface de rede conecta uma rede isolada, acessível apenas através do próprio Linux (como roteador ou não).

Agora, quando a máquina que está conectada em duas redes não é a única forma de acessar a subrede, o que acontece? Imagine um cenário onde um Linux está conectado em duas redes. Simples não?

Rede A(192.168.1.0/24)              Rede B(192.168.2.0/24) 
       |............Roteador (R)...........|
   X...|                                   |....Y
       |........eth0 Linux (L) eth1........|                  
       |                                   |

Nem tanto. Se o equipamento X, conectado na rede A tenta falar com a eth0 do servidor Linux, ele responde sem problemas (pois está diretamente conectado). O mesmo ocorre quando o equipamento Y tenta falar com o servidor Linux pela interface eth1. Agora, se X precisa falar com o endereço da interface eth1? O que acontece?
  1. X prepara um pacote para 192.168.2.22
  2. X envia para o roteador pois o IP 192.168.2.22 não está nas suas redes locais
  3. Roteador recebe o pacote da rede A e repassa para a rede B
  4. O servidor Linux recebe o pacote pela interface eth1
O caminho de ida foi sem problemas. Agora a resposta:
  1. O servidor Linux prepara resposta para X
  2. X está em uma rede diretamente conectada (interface eth0). O pacote é enviado diretamente.
Olha que interessante! O pacote chegou pela interface eth1 mas saiu pela eth0 (e com o MAC dela). O roteador, se quisesse, não teria como restringir a resposta do servidor Linux.

Vamos a outro cenário. Uma máquina Z fora das duas redes, tenta falar com a a interface eth0.
  1. Roteador recebe o pacote vindo de Z, pela rede C, e repassa para a rede A
  2. O servidor Linux recebe o pacote pela interface eth0
  3. O servidor Linux prepara a resposta de Z 
  4. Como Z não é uma interface diretamente conectada, ele envia ao roteador padrão (192.168.1.1).
  5. O Roteador recebe o pacote vindo de (192.168.1.11) vindo da rede A e o repassa para Z
Sem problemas. Agora se Z estivesse falando com a eth1?
  1. Roteador recebe o pacote vindo de Z, pela rede C, e repassa para a rede B
  2. O servidor Linux recebe o pacote pela interface eth1
  3. O servidor Linux prepara a resposta de Z
  4. Como Z não é uma interface diretamente conectada, ele envia ao roteador padrão (192.168.1.1).
  5. O Roteador recebe o pacote de (192.168.2.22) vindo da rede A e REJEITA!. Como o pacote da rede B pode surgir dentro da rede A?
O problema é que a tabela de roteamento não faz distinção quanto ao ip de origem (ou interface de origem). Ele apenas observa o destino. Como o destino é fora da rede local, ele envia pelo roteador padrão. Não existe 2 roteadores "padrão". Como resolver esta questão?

O Linux permite que seja criada mais de uma tabela de roteamento. Basta acrescentar a qual tabela estamos nos referenciando no comando "ip route". Exemplo:

# ip route show table main
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.11
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.22
127.0.0.0/8 dev lo  scope link
default via 192.168.1.1 dev eth0

As tabelas "local" e "0" também são bem interessantes para quem só usava até agora o comando "route".

O que precisamos fazer é criar uma nova tabela. Primeiro, cadastre um nome (para não usar números)

echo "1 redeB" >>/etc/iproute2/rt_tables

Isto permite que redeB seja usada nos comandos ao invés de apenas números.

Agora, a nova tabela de roteamento pode ser recriada.

ip route add 192.168.2.0/24 dev eth1 table redeB
ip route add default via 192.168.2.1 dev eth1 table redeB

 Mas quando que esta tabela nova vai ser usada? Isto pode ser definido por regras. Esta regra faz com que todos os pacotes que chegam pela interface eth1 utilizem a tabela de rotas redeB ao invés das regras padrão.

ip rule add from 192.168.2.2/32 lookup redeB

E pode ser necessário (em geral é) limpar o cache de rotas:

ip route flush cache

Como sempre, toda esta configuração (exceto pelo cadastro do nome) é volátil e se perde ao derrubar a rede ou reiniciar o computador. Por isto, deve ser carregada em script junto ao processo de configuração da rede.

Um outro cenário onde a configuração de tabelas de roteamento distintas pode ser útil é o caso de uma VPN quando até o tráfego Internet da rede interna deve ser roteado para a VPN. O roteador VPN deve utilizar uma rota padrão que aponte para a Internet, para operar a VPN, mas os pacotes vindos da rede interna devem ser todos roteados pela VPN.

Outro caso seria em laptops com interface WLAN e LAN. Se as duas estiverem conectadas em segmentos distintos da rede local, para algumas máquinas uma das interfaces não será acessível.

Este é só um caso onde é necessário o roteamento avançado. Porém, roteamento avançado pode ser usado em uma infinidade de casos como múltiplas conexões para a Internet. Vale a pena buscar no Google...

Ah, se alguém sentiu falta dos comandos "ifconfig", "route", ta mais do que na hora de aprender o comando "ip". Ele é mais limpo, mais fácil e toda a saída pode ser usada como entrada, basta prefixar com "ip <modulo> add/del". Talvez eu escreva sobre isto no futuro...

Atualização: pode ocorrer casos de pacotes de "origem marciana", os "martian source". Por que isto? O Linux possui uma filtragem que bloqueia pacotes estranhos que chegam por uma interface mas seriam roteados por outra, chamado de "Reverse Path Filtering" (rp_filter). Ex: pacotes com IPs da intranet chegando pela interface conectada na internet ou vice-versa. Porém, para casos onde as duas redes podem se comunicar, esta filtragem não faz sentido desta forma. Por isto, é necessário mudar o modo de "1" ("Strict Reverse Path filtering") para "2" ("Loose Reverse Path filtering"). Isto deve ser definido nos parâmetros: net.ipv4.conf.default.rp_filter, net.ipv4.conf.all.rp_filter e/ou net.ipv4.conf.<interface>.rp_filter.

sexta-feira, 29 de abril de 2011

A quem interessa o IPv6?

Tava aqui filosofando com meus botões...

Os provedores de Internet receberam "de graça" um bem que são endereços IPv4. Era só justificar que levava e era assim no mundo inteiro. Enquanto tinha endereços "a vontade", tal bem não tinha preço. Segundo a lei da oferta e procura, se a oferta é ilimitada, o preço é zero. Bem, hoje, a oferta já não é mais ilimitada.

Os endereços IPv4 são necessários para acessar a Internet. Como o mundo não migrou para IPv6, ele ainda é fundamental. Bem, se a oferta reduz (ou melhor, a "produção parou") e a procura só aumenta, temos uma inflação no preço do endereço.

Agora voltamos ao provedor de Internet. Se vc tinha um bem que vale zero, ele não era tão importante assim. Bastava que ele suprisse suas necessidades de negócio e pronto. Agora, quando este bem, ou melhor, ativo, começa a valer alguns milhões, a história muda. O pior de tudo é que, até agora, ninguém disse que o ativo endereço IPv4 é ou não é negociável. Recebeu de graça e agora pode vender. Entendeu a jogada? Quase a galinha dos ovos de ouro. Só não é melhor porque a galinha só vai botar ovos até, no máximo, 2012.

A implementação de IPv6 envolve custos e não possui um retorno visível para o cliente, exceto pelos problemas no serviço durante a migração. Se um provedor implementa a sua rede IPv6, e todos o fizerem, a procura por endereços irá cair, e inclusive, a oferta pode aumentar com os endereços vagos. Com isto o preço do ativo que eles atualmente possuem irá cair abruptamente. Alguém que visa o lucro é louco de fazer isto?

Moral da história: os provedores comerciais não irão implementar IPv6 enquanto a curva de crescimento do valor do endereço ainda estiver subindo e começarão a fazer gambiarras nos seus serviços para poder vender para outros novos provedores o que puder de seus endereços enquanto o preço estive em alta.

Os provedores não irão implementar a rede IPv6 até que:

  1. Os clientes exijam o serviço (IPv6 ou vou para outro que tenha), coisa que não vai acontecer se o cliente não souber do que se trata;
  2. O governo force sua implementação por força de lei ou norma;
  3. Ou, no caso de mau planejamento, eles tenham vendido mais endereços do que podiam e agora precisam comprar.
É, esperem uma inversão no serviço de Internet daqui a um, dois anos. Preços mais altos e qualidade pior devido as gambiarras para usar menos endereços.

domingo, 24 de abril de 2011

Luiz 1 x 0 SW de gerenciamento de celular

Como responsável da área da computação em casa, eu estava realizando a migração do celular da mulher. Bem, vamos dizer que é um celular exótico: gradiente fabricado pela francesa Sagem. Para a época, o celular era muito bom e ainda funciona bem. Agora voltando ao assunto...

A ferramenta de exportação foi terceirizada para uma empresa que, claro, não suporta mais este celular e nem vende o produto que o fazia. Com muita luta, achei uma versão demo que faz o que eu queria, exceto pelo fato de ser limitada a 6 contatos (o celular tem algumas centenas deles). Procura aqui, ali e nada de solução. Conclui que eu teria que fazer isto sozinho!

Tem um debugger para windows muito bom: w32dsm. Faz milagres. Pena que eu não tive assembly x86 na universidade. Com ele, busquei qualquer referencia a string "contacts" na memoria e coloquei um breakpoint depois de cada uma. Rodei o programa e foi contando o breakpoint que batia 6 vezes. E não é que eu achei?!

String Resource ID=17035: "Reading contacts: Mobile memory"

Desta forma, existe algum loop do tipo:

while ??? {
    ???
    chamada1()
    ???
}
chamada1 ( ) { chamada2 () }
(...)
chamadaX () { char[] str = "Reading contacts: Mobile memory" }

Com esta informação, fuirastreando (stepover) as chamadas "ret" do assembly que representam o retorno da chamada de função até o ponto onde o stepover bateu novamente no breakpoint da string. Isto me indicou que eu havia chegado no loop de leitura dos contatos. Voltei para as intruções do loop e analisei uma passada completa. O resultado não foi nada inovador. Algumas comparações no começo do loop, muita coisa no meio e um incremental no final: o bom e velho "for":


for (i-0;???;i++) {
    ???
    chamada1()
    ???
}
Bastou observar com cuidado para ver qual comparação gerava o jump para fora do loop. Na sexta iteração, achei uma comparação interessante entre o EAX (neste caso, i) e uma região da memória EBP+018. Mais sugestivo é que a comparação é >=. Quando ambos eram 6, o processo saia do loop. Olhando este EAX+018, ele possui o valor 6 desde o início do loop.


a=6;
for (i-0;???;i++) {
    if (i >= a) break;
    chamada1()
    ???
}
Agora é a parte fácil :-) Durante um loop qualquer, ainda pelo debugger, troquei o valor da memória para algo como 0x1000, retirei o breakpoint e fui para o abraço. Se fosse fazer algo permanente, teria que trocar a intrução do jump para uma nop ou modificar a comparação para que esta sempre desse negativa.

Já tinha feito algo parecido no passado mas com if e não for. O loop é muito mais fácil de identificar.

O pior de tudo: vou ganhar só um "ah tah... obrigada" por todo este trabalho :-(