Início > Mikrotik, Túneis, TCP/IP > Mandando IPs para a Conchinchina, no Mikrotik.

Mandando IPs para a Conchinchina, no Mikrotik.

Querer aprender sempre mais reflete a nossa
curiosidade. Acreditar poder saber tudo reflete apenas uma ilusão.
Marcelo Gleiser,
em Criação Imperfeita.

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.
Categorias:Mikrotik, Túneis, TCP/IP
  1. int21
    16/12/2010 às 14:37

    Usando o Eoip sobre o pptp nos leva à camada 2, com isso, até o multicast é possivel em redes remotas. Ja testei e funciona acontento, vale a pena experimentar.

  2. juliaobraga
    21/02/2011 às 09:43

    O seguinte e-mail foi passado na lista da Anid. Como não estou mais em tal lista, reproduzo-o aqui e minha resposta via lista “Novos Rumos”:

    > —–Mensagem original—–
    > De: inclusaodigital-bounces@anid.com.br
    > [mailto:inclusaodigital-bounces@anid.com.br] Em nome de Rubens Kuhl
    > Enviada em: domingo, 20 de fevereiro de 2011 16:25
    > Para: Associados da ANID
    > Assunto: Re: [Inclusão Digital]Venda de IP
    >
    >> Tem até um “tutorial” sobre a experiência dele:
    >>
    > https://juliaobraga.wordpress.com/2010/12/16/mandando-ips-para-a-conchinchina
    >> -no-mikrotik
    >
    > A experiência dele o colocou em diversas edições na lista de prefixos
    > mais instáveis da Internet brasileira. Quem for fazer este tipo de
    > tunelamento deve melhorar as configurações sugeridas para evitar que a
    > disponibilidade menor dos circuitos de última milha coloque o prefixo
    > em dampening.
    >
    > Por exemplo, gerando o anúncio EBGP através de uma rota estática para
    > nul0 com distância administrativa alta. Assim, na falta do anúncio
    > interno via túnel, o tráfego que vier é descartada mas o anúncio de
    > rota fica estável.
    >
    >
    > Rubens
    > _______________________________________________
    > Inclusaodigital mailing list
    > Inclusaodigital@anid.com.br
    > http://anid.com.br/mailman/listinfo/inclusaodigital

    • juliaobraga
      21/02/2011 às 09:44

      Rubens,

      Você está confundindo alhos com bugalhos!

      Primeiro porque, a referência “A experiência dele o colocou em diversas edições na lista de prefixos mais instáveis da Internet brasileira …” exala fétido odor de má fé e, segundas intenções, já que a experiência foi feita ao largo do PTT-SP e não tem nada a ver com falhas cometidas na implementação (à época, por volta de 10/11 e discutida na lista GT-AS), corrigidas imediatamente e que não foram tão graves assim, até na avaliação de pessoas mais bem preparadas do que você. Pelo menos para mim foi ótimo, pois aprendi algo mais sobre a tecnologia de uso do Mikrotik. Desde então, meu palíndrome está estável há muito tempo, junto aos diversos empareamentos, incluíndo com, o PTT-SP.

      Segundo porque não tem nada de EBGP, na experiência. O que provavelmente indica que você nem leu o pequeno artigo.

  3. juliaobraga
    25/02/2011 às 12:16

    Resposta do Rubens á lista da Anid e Novos Rumos:

    —–Mensagem original—–
    De: inclusaodigital-bounces@anid.com.br
    [mailto:inclusaodigital-bounces@anid.com.br] Em nome de Rubens Kuhl
    Enviada em: sexta-feira, 25 de fevereiro de 2011 11:03
    Para: Listas dos Provedores da Abrint
    Cc: Lista da ANID
    Assunto: Re: [Inclusão Digital][Novosrumos] Mandando IPs para a Conchinchina

    Julião,

    Os eventos discutidos na lista GT-AS foram do anúncio de bogons IPv4
    pelo AS da Telesa, e não tem nada a haver com o que comentei na
    mensagem abaixo, que foram as instabilidades do prefixo IPv6
    2001:1294::/48 do AS da Telesa registradas em todos os roteadores da
    DFZ IPv6 no mês de Dezembro/2010. Esse tipo de flapping é que pode ser
    evitado ao fazer pull-up routes quando se faz túnel para transportar
    blocos de IPs, e com isso evitar dampening.

    Quanto ao seu comentário sobre a inteligência dos membros da lista da
    ANID, eu entendo que seja apenas na sua visão distorcida que se pense
    desta maneira, pois a sua é a única manifestação nesse sentido em
    diversos anos de participação nessa lista.

    Rubens

  4. juliaobraga
    25/02/2011 às 16:34

    Rubens,

    Os eventos de sua animosidade não tem nada a ver com o meu artigo. Sua animosidade, lamentavelmente, obscurece a objetividade que se espera de um debate técnico.

    Continuo com minha opinião, portanto, em relação ao “alhos e bugalhos” e sobre a noção de imbecilidade. Acho curioso, também, que você, como membro do Nic.br fique divulgando os blocos de terceiros de forma gratuita. Principalmente para quem está querendo fazer carrreira no CGI.br, talvez substituindo o Demi no “reconhecido saber”. Acho meio difícil. Mas reconheço que estamos em um país inovador.

    O papo é shakesperiano. Não vale a pena discutir, pois sua habilidade é imensa e ” … perde-se até a ação perder o nome”.

    Ficamos por aqui, com minha téplica, com o registro da sua não explicada atitude, na pródiga Internet e com seu eterno direito de resposta assegurado.

  1. No trackbacks yet.

Deixe uma resposta

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: