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:

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”

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

3. Vejamos como fica a conversão:

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.