Infraestrutura da Internet

Atualizado em: 28/01/2011.
Atualizado em: 30/01/2011.
Atualizado em: 09/04/2011. Inserida a referência [2] com o objetivo de entender os comentários, relacionados com rotas ping-pong.

Introdução

Sempre que finalizamos uma determinada aplicação, ela torna-se fácil. Mas, antes de terminá-la, há dois componentes: um, também, fácil e outro difícil. O fácil geralmente é a concepção. Sempre que concebemos um modelo de um problema, ele é a parte fácil porque o prérequisito, isto é, o conhecimento, já existe. Se não existisse, provavelmente, não haveria o modelo. A parte difícil é a implementação. Estamos falando, naturalmente, de infraestrutura da Internet. A dificuldade está na tecnologia de uso da ferramenta (nesse caso, o Mikrotik) e, suas sutilezas inerentes.

Claro que, à medida que se usa determinados recursos, amadurece o aprendizado da ferramenta. Principalmente, quando se comete erros. O problema aqui descrito é simples: como rotear, na Internet, IPs válidos para ambientes que não os tem. De outra maneira a questão fica mais compreensível analisando a figura abaixo:

A rede do Mikrotik 2 (MK2) tem um telefone VoIP (no exemplo, um ramal do INOC-BR). A interconexão para a Internet é uma aDSL, como se sabe, com IP válido, mas dinâmico. Com NAT, até funcionaria mas, as mudanças do IP dinâmico força um sistemático processo de autenticação no servidor VoIP. Se o IP não mudasse tanto, não teríamos o problema. Mesmo assim, atravessar o NAT para chegar no IP privativo do aparelho telefônico, traz algumas instabilidades indesejáveis no VoIP (hoje em dia, não tão sério), pois a mídia de voz é atravessada ou conduzida pelo MediaProxy. Um componente a mais na ligação. Então, a questão é, em outras palavras: como colocar IPs válidos na rede interna do MK2?

Há muitas maneiras. A mais simples é estabelecer um túnel (VPN) entre o MK1 e o MK2. O MK1 é quem tem IPs válidos disponíveis e, rotear um bloco de IP para a rede do MK2. O ideal é que a conexão da VPN evitasse o uso de recursos, tais como “scripts” no MK, já que a dificuldade é o uso. A escolha cai então sobre o túnel PPTP, que subtende um parceiro como sendo o servidor e o outro como sendo o cliente. No exemplo, o servidor será o MK1, pois ele está sob a conexão de uma operadora e, portanto, com IP público, fixo, na interface para a Internet. O cliente é o MK2, portanto. Toda vez que houver mudança de IP na interface do MK2, haverá nova conexão do cliente ao servidor PPTP.

Implementação no MK1 (servidor PPTP)

Essa é a parte fácil e pode ser criada assim:

/ppp secret name=”tunel_pptp” service=pptp caller-id=”” password=”senha_escolhida” profile=default local-ddress=10.0.0.1 remote-address=10.0.0.2 routes=”” limit-bytes-in=0 limit-bytes-out=0

Uma olhada na documentação do MK, outros atributos podem ser usados, como por exemplo, routes. Uso de rotas estáticas fica mais intuitivo. Lembrando que a máscara escolhida é irrelevante, tem-se:

IP do servidor PPTP:  10.0.0.1/30
IP do cliente PPTP:   10.0.0.2/30

Uma interface dinâmica é criada (quando a conexão se estabelece) e pode ser vista assim:

[admin@MK1] > interface print
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                        TYPE             MTU   L2MTU
 ...
 4 DR                                    pptp-in          1460

e, um endereço, também dinâmico, para a interface do PPTP foi estabelecida:

[admin@MK1] > ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 ...      
 1 ADC  10.0.0.2/32        10.0.0.1                 0       
 ...      

Finalmente, cria-se a rota estática para o prefixo desejado, abaixo exibida em um print:

[admin@MK1] > ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 ...      
 3 A S  ip.valido-1.estatico.0/27                   10.0.0.2           1       
...

Implementação no MK2 (cliente PPTP)

No cliente, o equivalente ‘secret’ ficará da seguinte forma, compatível com o que foi feito no servidor PPTP:

[admin@MK2] > ppp secret print detail
Flags: X - disabled 
 0   name="tunel_pptp" service=pptp caller-id="" password="senha_escolhida" 
      profile=default local-address=10.0.0.2 remote-address=10.0.0.1 routes="" 
      limit-bytes-in=0 limit-bytes-out=0

Agora, os passos seguintes:

Passo 1: Criação da interface PPTP cliente:

[admin@MK2] > interface print detail
Flags: D - dynamic, X - disabled, R - running, S - slave 
 ...
 4  R  name="PPTP_Cliente" type="pptp-out" mtu=1460 
...

Passo 2: Colocando o respectivo IP, na interface criada no Passo 2. Observe o endereço na interface da rede interna, com o IP ip.valido-1.estatico.1/27, vindo do Servidor PPTP, via rota estática:

[admin@MK2] > ip address print detail
Flags: X - disabled, I - invalid, D - dynamic 
 ...
 1   address=ip.valido-1.estatico.1/27 network=ip.valido-1.estatico.0 
      broadcast=ip.valido-1.estatico.31 interface=Rede Interna 
      actual-interface=Rede Interna
 2   address=10.0.0.2/30 network=10.0.0.0 broadcast=10.0.0.3 interface=PPTP_Cliente 
      actual-interface=PPTP_Cliente 
...

Passo 3: No cenário do Cliente PPTP, há um NAT via o aDSL, com a respectiva rota default estabelecida. Há necessidade de uma segunda rota default para o Servidor PPTP. A solução do eventual conflito das duas rotas default, é resolvido através da marcação de pacotes, mostrado no Passo 4. Eis a configuração das rotas e observem o ‘routing-mark’ e as duas rotas default, presentes:

[admin@MK2] > ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, 
r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 0 A S  dst-address=0.0.0.0/0 gateway=10.0.0.1 gateway-status=10.0.0.1 
           reachable PPTP_Cliente distance=1 scope=30 target-scope=10 
           routing-mark=rota_pptp 
 1 A S  dst-address=0.0.0.0/0 gateway=Speedy gateway-status=Speedy 
           reachable distance=1 scope=30 target-scope=10 
 2  DS  dst-address=0.0.0.0/0 gateway=ip.publico.dinamico.? 
           gateway-status=ip.publico.dinamico.? reachable Speedy distance=1 
           scope=30 target-scope=10 
 3 ADC  dst-address=10.0.0.0/30 pref-src=10.0.0.2 gateway=PPTP_Cliente 
            gateway-status=PPTP_Cliente reachable distance=0 scope=10 
 4 ADC  dst-address=10.0.0.1/32 pref-src=10.0.0.2 gateway=PPTP_Cliente 
            gateway-status=PPTP_Cliente reachable distance=0 scope=10 
 ...
 8 ADC  dst-address=ip.publico.dinamico.?/32 pref-src=ip.publico.dinamico.outro 
            gateway=Speedy gateway-status=Speedy reachable distance=0 scope=10 
 9 ADC  dst-address=ip.valido-1.estatico.0/27 pref-src=ip.valido-1.estatico.1 
            gateway=Rede Interna gateway-status=Rede Interna reachable 
            distance=0 scope=10 

Passo 4: Marcar os pacotes. Tem uma sutileza, no que diz respeito ao conflito das rotas default. Uma marcação é para os pacotes, com os IPs do sub-bloco ip.valido-1.estatico.0/27 que trafegam pelo MK2 e a outra marcação, para os pacotes, com os mesmos IPs, que sairão do MK2, via o túnel VPN (obrigatoriamente). Esse último, efetivamente resolve o conflito das rotas default e não é muito referenciado na literatura disponível. Um bom teste é suprimir a marcação 1, abaixo e tentar pingar de fora a interface da rede local do MK3. Vejamos as configurações:

[admin@MK2] > ip firewall mangle print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=prerouting action=mark-routing new-routing-mark=rota_pptp 
      passthrough=no src-address-list=pptp 
 1   chain=output action=mark-routing new-routing-mark=rota_pptp 
      passthrough=no src-address-list=pptp 

Para constar, eis a lista ‘pptp’:

[admin@MK2] > ip firewall address-list print detail
Flags: X - disabled, D - dynamic 
...
 1   list=pptp address=ip.valido-1.estatico.0/27 
...

Epílogo I

Embora o funcionamento estivesse normal, alguns dias depois criei um esquema de acesso à rede interna (cliente), em pilha dupla e instalei uma sessão BGP remota com a FFE, que está no meu notebook. A pilha dupla não estava estável, pois alguns acessos externos não conseguiam chegar ao servidor de Web nem via IPv6, nem via IPv4. O roteador da FFE que fazia a parceria BGP multi-hop não era alcançado de uma rede externa. Nem tampouco se conseguia pingar nos IPv6 da rede interna onde está a FFE. Após uma revisão no mecanismo de roteamento do Mikrotik achei que faltava uma marcação de conexão de entrada, da seguinte forma:

0   chain=input action=mark-connection new-connection-mark=PPTP_conn 
     passthrough=no in-interface=PPTP_Cliente 

e, no mangle output, inclui:

... connection-mark=PPTP_conn

Nesse, momento o ping local está funcionando (antes ele ficava em um loop, indo e vindo pela conexão pptp, durante um traceroute). A pilha dupla, uma novidade do contexto, ainda sem a conclusão dos testes finais. O fato é que à medida do aumento das conexões nas interfaces (do lado do cliente) aumenta a complexidade no “mangle”. No meu caso, a inserção de um “tunnelbroker” IPv6, em BGP com a HE adicionou um componente cuja explicação darei mais tarde, em abordagem que seguirá ao texto BGP: Tabelas de roteamento.

Epílogo II: Sobre a complexidade de uma topologia “multihoming”

Tal complexidade não é privilégio do Mikrotik, como veremos. E é uma preocupação sobre topologias multihoming, parecidas com a do exemplo, na qual o nó cliente (ou o nó servidor, ou qualuqer outro nó) interconecta diversos pontos criando uma variedade de possibilidades em relação ao tráfego de pacotes da direção de múltiplas interfaces e/ou conexões. Caso haja conflitos, os danos podem gerar reflexos locais ou remotos. Não é o caso do exemplo acima, mas vale lembrar a existências de preocupações, muito bem descritas em [1].

Em artigo no qual daremos ênfase ao roteamento e fluxo de pacotes no Mikrotik faremos referência aos cuidados que devem ser tomados. Basicamente estão envolvidos marcação de pacotes (falado acima), roteamento e firewall.

Referências

1. M. Blanchet e P. Seite,Multiple Interfaces and Provisioning Domains Problem Statement. Disponível em: http://www.ietf.org/id/draft-ietf-mif-problem-statement-09.txt. Acessado em: 28/02/2011.

2. Juniper, Configuring IPv6 VPNs. Disponível em: http://www.juniper.net/techpubs/software/erx/junose61/swconfig-routing-vol2/html/bgp-mpls-vpns-config16.html. Acessado em 09/04/2011, 14:26.