Problemas de Roteamento ao Acessar recursos através de uma VPN


Por: Yuri Diógenes


 


1. Introdução


 


Mais e mais as empresas estão usando o recurso de VPN, muitas empresas disponibilizam notebooks para seus executivos ou para seus funcionários que fazem serviços remotos de forma que os mesmos tenham acesso a recursos da empresa quando estão viajando. Além do desafio de acessibilidade ao estar remoto também podem surgir outros desafios de conectividade.


 


O cenário deste artigo foi baseado em um caso onde por uma infelicidade do destino o cliente ao viajar e se hospedar em um determinado hotel descobriu que naquele hotel ele não conseguia fazer acesso à VPN, apesar de conseguir se logar com sucesso ele não conseguia fazer acesso aos recursos da rede interna. Vejamos a seguir o que estava ocorrendo neste caso…


 


2. Cenário


 


Abaixo temos a figura com o cenário do usuário:


 



 


 


Figura 1 – Cenário de exemplo.


 


 


Veja bem o cenário e note que a rede da empresa do usuário usa a mesma classe e a mesma máscara de subrede que o hotel utiliza. Neste caso específico, sempre que o cliente tentava acessar os recursos da rede interna ele recebia um erro dizendo que não conseguia acessar os recursos.


 


3. Como Funciona a Decisão no Roteamento


 


Neste caso temos um problema puro de rotas IP e irei falar sobre isso no próximo tópico, porém antes mesmo de chegar neste ponto é importante lembrar das premissas de como um host determina se o recursos é local ou remoto.


 


Quando atribuímos um endereço IP para um host este por si só já cria automaticamente uma tabela de roteamento. Caso um endereço de “default gateway” não seja passado, ele criará apenas rotas para rede local. Vejamos por exemplo um host cujo IP é 192.168.0.250, se apenas este IP for preenchido nas propriedades do TCP/IP então teremos a seguinte tabela:


 


Network Destination         Netmask                       Gateway                       Interface           Metric


127.0.0.0                         255.0.0.0                       127.0.0.1                       127.0.0.1           1


192.168.0.0                      255.255.255.0                192.168.0.250                192.168.0.250    20


192.168.0.250                   255.255.255.255            127.0.0.1                       127.0.0.1           20


192.168.0.255                   255.255.255.255            192.168.0.250                192.168.0.250    20


224.0.0.0                          240.0.0.0                       192.168.0.250                192.168.0.250    20


255.255.255.255                255.255.255.255            192.168.0.250                192.168.0.250    1


 


Note que nesta tabela básica (sem gateway) temos as seguintes rotas:


·         127.0.0.0/8 – Faixa reservada para “loopback” ou auto-teste. Note que esta faixa envia para a interface 127.0.0.1 que é o próprio host local;


·         192.168.0.0/24 – Esta é a rota para o endereço da rede do host, que por sua vez aponta para o IP da interface local;


·         192.168.0.250 – Rota com o endereço do host que aponta para ele mesmo e para o endereço de loopback;


·         192.168.0.255 – Rota para o broadcast do segmento local, o segmento de rede a qual o host faz parte onde a interface de saída é o endereço do host local;


·         224.0.0.0 – Faixa reservada para multicast onde a interface de saída é o host local também;


·         255.255.255.255 – Broadcast geral de rede.


 


Bem, note que neste caso não temos IP e ao não termos IP não temos uma rota que seria a rota padrão. Por não ter uma rota padrão, caso este host tente se comunicar (efetuar um ping) com o endereço 10.10.10.1 ele não vai conseguir, pois não tem rota para este host e o resultado será “destino inalcançável”.


 


Note também que a última coluna desta tabela descreve a métrica, está métrica é um fator de prioridade no roteamento do pacote. Caso tenhamos duas rotas para a mesma rede a pilha TCP/IP vai dar prioridade a rota com menor métrica. Então podemos dizer que: quanto menor a métrica maior a prioridade de roteamento.


 


Agora vejamos a diferença da tabela quando se adiciona um “Default Gateway”:


 


Network Destination         Netmask                       Gateway                       Interface           Metric


0.0.0.0                            0.0.0.0                          192.168.0.3                   192.168.0.250    20


127.0.0.0                         255.0.0.0                       127.0.0.1                       127.0.0.1           1


192.168.0.0                      255.255.255.0                192.168.0.250                192.168.0.250    20


192.168.0.250                   255.255.255.255            127.0.0.1                       127.0.0.1           20


192.168.0.255                   255.255.255.255            192.168.0.250                192.168.0.250    20


224.0.0.0                          240.0.0.0                       192.168.0.250                192.168.0.250    20


255.255.255.255                255.255.255.255            192.168.0.250                192.168.0.250    1


 


Note que agora temos uma rota padrão que no final significa: todos pacotes aos quais eu não tenha uma rota específica então deverei encaminhar para o IP 192.168.0.3. Nesta frase é importante salientar que uma rota específica sempre tem prioridade, quanto mais específica a rota maior a prioridade no roteamento.


 


3.1. Anding


O processo que é utilizado para decidir se devemos ou não enviar um pacote para um rede ou para outra rede é chamado de ANDing. Vejamos o exemplo:


 


O host de origem 192.168.1.200 com a máscara 255.255.255.0, está tentando enviar um pacote para o host 192.168.2.200 com a máscara 255.255.255.0. Como o host determina que um pacote é local (mesmo segmento de rede) ou não? Vejamos como é feito o processo:


 


1. Converta os números em binários:


 


























Origem


 


192.168.1.200


11000000.10101000.00000001.11001000


255.255.255.0


11111111.11111111.11111111.00000000


 


 


Destino


 


192.168.2.200


11000000.10101000.00000010.11001000


255.255.255.0


11111111.11111111.11111111.00000000


 


2. Usando o operador “E” na tabela verdade temos que fazer então a comparação bit a bit dos três primeiros octetos (isso porque estamos usando um endereço com a máscara classe C) para verificar se o endereço de rede é o mesmo, se for então o host entende que o pacote deverá ser enviado para o segmento de rede local, se não for então o host vai olhar a tabela de roteamento local para saber se tem uma rota específica para o destino, caso não tenha então o pacote deverá ser enviado para a rota padrão (gateway).


 


– Tabela verdade com operador “E”





























0


E


0


=


0


0


E


1


=


0


1


E


0


=


0


1


E


1


=


1


 


– A única combinação que resulta em 1 é quando ambos são verdadeiros.


 


3. Vejamos como fica a conversão:


 





































Origem


Binário


Decimal


 


11000000.10101000.00000001.11001000


 


 


11111111.11111111.11111111.00000000


 


Rede de Origem


11000000.10101000.00000001.00000000


192.168.1.0


Destino


Binário


Decimal


 


11000000.10101000.00000010.11001000


 


 


11111111.11111111.11111111.00000000


 


Rede de Destino


11000000.10101000.00000010.00000000


192.168.2.0


 


4. Note que o resultado é diferente, com isso ele deverá encaminhar o pacote para o default gateway que por sua vez vai fazer o mesmo cálculo para determinar para onde o pacote será enviado.


 


Após essa revisão de roteamento vejamos então qual a causa raiz do problema….


 


4. A Causa Raiz


 


Quando o cliente se conectava na VPN ele recebia o endereço IP 192.168.0.133/24 e a seguinte tabela de endereços era criada:




 



Active Routes:


Network Destination       Netmask                       Gateway           Interface                       Metric


0.0.0.0                          0.0.0.0                          192.168.0.133    192.168.0.133                1


0.0.0.0                          0.0.0.0                          192.168.0.199    192.168.0.198                21


10.10.10.219                  255.255.255.255           192.168.0.199   192.168.0.198                20


127.0.0.0                       255.0.0.0                       127.0.0.1           127.0.0.1                       1


192.168.0.0                   255.255.255.0                192.168.0.198   192.168.0.198                20


192.168.0.133                255.255.255.255            127.0.0.1           127.0.0.1                       50


192.168.0.198                255.255.255.255            127.0.0.1           127.0.0.1                       20


192.168.0.255                255.255.255.255            192.168.0.133   192.168.0.133                50


192.168.0.255                255.255.255.255            192.168.0.198   192.168.0.198                20


224.0.0.0                       240.0.0.0                       92.168.0.198     192.168.0.198                20


224.0.0.0                       240.0.0.0                       192.168.0.133   192.168.0.133                1


255.255.255.255            255.255.255.255            192.168.0.198   192.168.0.198                1


 


Default Gateway:     192.168.0.133


 


Note que em vermelho é mostrado o que é a rota padrão para a rede 192.168.0.0/24, neste caso está  indo primeiramente para a interface de rede wireless do notebook  (192.168.0.198).


 


Lembre que neste momento o “ANDing” vai ocorrer e o host vai determinar que os pacotes para a rede 192.168.0.0/24 são locais e com isso não tem porque enviar para o gateway. Além disso a rota para esta rede tem menor métrica e com isso maior prioridade. Em suma: o pacote não será encaminhado para o Default Gateway (192.168.0.133) quando o destino for para a rede 192.168.0.0/24.


 


5. A Solução


 


Como foi visto o problema todo foi uma questão de rota, então o que foi feito inicialmente para validar a solução foi adicionar a seguinte entrada na tabela de rotas do cliente remoto:


 



add 192.168.0.0 mask 255.255.255.0 192.168.0.133 metric 1


 


Note que ao adicionar esta entrada estamos dizendo que o tráfego para a rede 192.168.0.0/24 deverá ser encaminhado para a interface de rede VPN (endereço IP recebido) com a métrica 1. Esta métrica 1 no final é importantíssima tendo em vista que a rota mostrada anteriormente continuará sendo criada pois é parte das rotas padrões que são criadas. Desta forma, ao dizermos que a métrica é 1, esta rota terá prioridade sobre a outra rota (20). Vejamos como ficou a tabela de roteamento após a adição desta rota:


 



Active Routes:


Network Destination       Netmask                       Gateway           Interface                       Metric


0.0.0.0                          0.0.0.0                          192.168.0.133    192.168.0.133                1


0.0.0.0                          0.0.0.0                          192.168.0.199    192.168.0.198                21


10.10.10.219                  255.255.255.255           192.168.0.199   192.168.0.198                20


127.0.0.0                       255.0.0.0                       127.0.0.1           127.0.0.1                       1


192.168.0.0                   255.255.255.0                192.168.0.198   192.168.0.198                20


192.168.0.0                   255.255.255.0                192.168.0.133   192.168.0.133                1      


192.168.0.133                255.255.255.255            127.0.0.1           127.0.0.1                       50


192.168.0.198                255.255.255.255            127.0.0.1           127.0.0.1                       20


192.168.0.255                255.255.255.255            192.168.0.133   192.168.0.133                50


192.168.0.255                255.255.255.255            192.168.0.198   192.168.0.198                20


224.0.0.0                       240.0.0.0                       92.168.0.198     192.168.0.198                20


224.0.0.0                       240.0.0.0                       192.168.0.133   192.168.0.133                1


255.255.255.255            255.255.255.255            192.168.0.198   192.168.0.198                1


 


Default Gateway:     192.168.0.133


 


 


Porém a solução não poderia estar completa se não fosse automatizada para todos os clientes, até mesmo porque nunca sabemos qual o cenário que o cliente vai se deparar. Para automatizar esta configuração foi então utilizado o utilitário CMAK (Connection Manager Administration Kit). Através deste utilitário é possível passar um arquivo de texto como parâmetro para atualização da tabela de roteamento, conforme mostra a janela abaixo:


 


 


 


Figura 2 – Tela do CMAK com a opção de passar o arquivo de rotas.


 


Nesta tela dizemos o nome do arquivo TXT que por sua vez deverá ter um conteúdo semelhante ao mostrado abaixo:


 



ADD 192.168.0.0 MASK 255.255.255.0 default METRIC default IF default


 


Note que a sintaxe do comando para adicionar rotas não é diferente para o comando que usamos na console. Ao usar a palavra chave “default” antes da métrica estamos assumindo o IP recebido pela VPN e ao usar o valor “default” após a métrica estamos dizendo que este valor deverá ser 1. Para maiores referencias acerca deste comando veja a documentação do CMAK na sessão “Including Routing Table Updates”.


 


6. Conclusão


 


Este foi um cenário que poderia ser considerado complexo caso não tivéssemos a certeza que o problema estava relacionado a tabela de roteamento. Também foi possível concluir com isso o poder que a ferramenta CMAK tem para permitir uma maior personalização no acesso remoto de clientes.


 


Até a próxima.


 



 

Comments (2)

  1. Anonymous says:

    Olá Rodrigo,

    Obrigado por acessar nosso blog e nos estimular com este feedback. Espero que sempre tenhamos conteúdo para fazer com que você continue retornando, lendo e divulgando nosso trabalho.

  2. rodrigo says:

    Sei que não é o canal correto, porém sem alternativas quero expressar o quão é fantástico esse blog.

    Todos merecem honras por publicar tão bem problemas não tão corriqueiros.