Utilizador de gateway no Access Server: encaminhar a LAN da filial de um cliente

Pode fazer ping ao endereço de túnel de um cliente OpenVPN e mesmo assim não chegar a nenhum host na LAN por trás. O Access Server atribui ao cliente um endereço do pool VPN, e o endereço do pool é tudo o que o servidor sabe que possui. O prefixo da filial é um facto separado que tem de ser declarado, e mesmo assim a filial precisa de um reencaminhador e a sede de um caminho de retorno. Uma rota escrita no lugar errado parece uma correção e não muda nada.

Dois endereços, duas reivindicações de propriedade diferentes

Quando um cliente se liga, o Access Server atribui-lhe um endereço do pool VPN configurado, por exemplo 10.90.0.0/24. Essa atribuição é um aluguer para um único host. Nada na ligação diz que o mesmo cliente também está à frente de 10.60.0.0/24, e o servidor não vai adivinhar: um prefixo LAN só é alcançável através de um cliente concreto se um administrador o declarar.

É por isso que uma rota estática noutra máquina não serve. A rota diz envie 10.60.0.0/24 para este endereço, mas se o endereço pertence a um cliente que nunca foi marcado como gateway, o servidor não tem motivo para entregar ali esses pacotes, e a pilha do cliente pode descartá-los. A declaração e a rota são duas metades do mesmo mecanismo.

O que a definição de gateway instala realmente

Na interface de administração a declaração é uma propriedade de utilizador: ative Configure VPN gateway no utilizador conector e introduza o prefixo real da filial em Network on the VPN client side. Esse utilizador autentica-se como qualquer outro, por isso precisa de uma política de credenciais adequada a um dispositivo sem supervisão, e o seu perfil de início automático é um segredo.

Atrás dessa caixa o servidor trata o prefixo como alcançável através do endereço de pool desse cliente, e a configuração de encaminhamento em Access Controls decide o que é anunciado aos outros clientes: as rotas enviadas aos clientes comuns e as regras de acesso que permitem tráfego das redes da sede para endereços e sub-redes de clientes. Ative o encaminhamento para as redes que devem chegar à filial e mantenha curta a lista permitida.

Uma diretiva ao estilo Community colada num ficheiro gerado não participa neste modelo. O produto é dono da tabela de encaminhamento que envia; uma linha editada à mão é substituída ou ignorada.

Complete os caminhos de retorno das duas redes

Um plano concreto: sede 10.40.0.0/24, filial 10.60.0.0/24, pool VPN 10.90.0.0/24, e Access Server acessível num endereço privado do lado da sede. O router da sede precisa de rotas para o prefixo da filial e para o pool, ambas para o Access Server. Sem elas o túnel leva o pedido e a resposta sai pelo gateway predefinido, o que produz a clássica ligação semiaberta.

Na filial o conector tem de reencaminhar os pacotes que não lhe são endereçados: reencaminhamento IP no seu sistema operativo mais uma autorização limitada às interfaces do túnel e da LAN; no Linux é net.ipv4.ip_forward=1 com as regras da cadeia forward, no Windows é routing and remote access. Depois os hosts da filial precisam de um caminho de retorno: ou o conector é o seu gateway predefinido, ou o gateway existente transporta rotas específicas para os prefixos da sede e do pool.

A tabela de encaminhamento do conector não reconfigura todos os hosts da LAN da filial. Se os hosts apontam para outro router, as rotas de retorno pertencem a esse, e este tem de aceitar que o endereço de origem que vê não é um vizinho da sub-rede local.

Leia uma falha como um caminho, não como uma permissão

Teste por ordem fixa. Primeiro um serviço permitido do Access Server para um host da filial, depois o mesmo serviço a partir de um host comum da sede, depois o sentido inverso se a política o permitir. Se o primeiro passa e o segundo falha, o problema são as rotas enviadas ou as regras de acesso. Se ambos passam mas não chegam respostas, examine o reencaminhamento na filial e a rota de retorno na sede.

A firewall do host é o suspeito seguinte, porque com acesso encaminhado o destino vê como origem um endereço da sede ou do pool. Uma regra escrita para a sub-rede local não corresponderá e o pacote é descartado.

Dois desenhos exigem mais. Prefixos sobrepostos entre locais tornam o destino ambíguo e exigem renumeração ou tradução, e um Access Server em cluster exige que cada nó tenha um caminho funcional para o conector da filial, não um só nó a deter a rota. Aplique alterações pelo caminho normal de gravação e atualização, reconecte o conector e verifique de novo dos dois lados; reiniciar por completo cada máquina não faz parte do procedimento.

O tutorial site-to-site do Access Server lista as mesmas definições pela ordem do produto; vale a pena segui-lo uma vez antes de adaptar o desenho aos seus prefixos.