Acesso remoto ou VPN site a site: qual se encaixa?

Um funcionário em viagem e um escritório filial precisam de túneis diferentes, e a escolha errada produz um desenho que funciona no laboratório e falha na primeira segunda-feira. O acesso remoto liga um dispositivo a um gateway. O site a site liga dois gateways que representam redes. A lista de verificação abaixo decide qual dos dois o requisito realmente descreve.

Quem disca, e o que está atrás de quem disca

No acesso remoto, o software no notebook ou no telefone estabelece o túnel, e o gateway autentica um usuário, um dispositivo ou ambos antes de atribuir um endereço e rotas. No site a site, roteadores, firewalls ou gateways de nuvem estabelecem a conexão, e os dispositivos atrás deles usam roteamento comum em vez de executar um cliente. Essa diferença decide quem é dono da disponibilidade do túnel: o dispositivo de um funcionário no primeiro caso, um equipamento gerenciado no segundo. Ela também decide se a autenticação descreve uma pessoa ou uma rede.

Pare aqui se o requisito é que cada máquina de um escritório alcance outro escritório sem configuração por dispositivo. Isso é site a site, e uma pilha de logins de acesso remoto é um substituto pobre.

Endereçamento e o caminho de volta

Planeje faixas locais e remotas distintas. Dois sites podem usar a mesma sub-rede privada, e o desenho então precisa de tradução ou renumeração antes que o roteamento seja inequívoco. Um roteador doméstico com a mesma faixa da matriz cria o mesmo problema para um trabalhador remoto. A sobreposição é comum o suficiente para que verificá-la pertença à primeira conversa.

O caminho de volta importa tanto quanto o de saída. Um servidor pode receber uma requisição e ainda assim não ter rota de volta para a rede do cliente.

Documente qual roteador conhece o prefixo remoto, especialmente com redes de nuvem e vários gateways. Um ícone verde de túnel não pode responder se um destino tem caminho de volta funcionando, e um ping em um só sentido também não. No acesso remoto o gateway costuma ser dono da rota do pool; no site a site, cada roteador intermediário que carrega o prefixo precisa concordar. A tradução pode esconder uma rota ausente até que uma aplicação que embute endereços quebre.

A saída para a internet é uma decisão separada

A alcançabilidade privada não exige que o túnel carregue a navegação pública. Se o tráfego web comum sai pelo gateway é uma segunda decisão, tomada por desenho e registrada no perfil do cliente ou na configuração do site.

O túnel completo e o túnel dividido são respostas a essa pergunta, não à pergunta acesso remoto contra site a site. Nomes internos precisam de DNS adequado nos dois desenhos, porque um resolvedor público não tem resposta para um nome de host de escritório privado. Enviar um resolvedor e enviar uma rota padrão são ajustes relacionados, e mudar um sem o outro produz falhas que parecem problemas de DNS.

Use a topologia para restringir a falha

Um notebook que circula perde o acesso no cliente, na própria conta ou na rede local. Um escritório filial inteiro perde o acesso em caminhos e gateways compartilhados.

Verifique primeiro o estabelecimento do túnel, depois as rotas, depois o tráfego permitido, depois a resolução de nomes, depois o login na aplicação, e pare no primeiro passo que falhar.ip route get 10.60.8.15 responde à pergunta de roteamento antes que você leia um único log de aplicação. Ajustes de criptografia não corrigem um erro de permissão de compartilhamento de arquivo, e um ping que funciona não prova que uma aplicação está autorizada. Manter a ordem fixa evita as mudanças de configuração aleatórias que transformam uma falha em três.

Por fim, mantenha as definições corretas ao ler material de fornecedores: um servidor comercial de saída para a internet é um serviço diferente do gateway privado de uma empresa e não concede nenhum acesso à rede dessa empresa.