Um cliente VPN em roaming pode hospedar um serviço para o escritório?

O portátil do escritório pode ligar-se de casa e ainda assim fornecer algo de que o escritório precisa, mas apenas quando três decisões separadas se alinham. O túnel é transporte, o endereço interno é o destino e a política decide quem pode bater à porta. Tratar qualquer uma delas como a resposta completa produz a queixa conhecida: o host responde a pings mas a aplicação nunca se liga. Os papéis não são iguais, e a diferença está exatamente onde vive o trabalho de conceção.

O sentido da ligação não diz nada sobre o sentido do serviço

Quando um cliente inicia um túnel, abre um caminho que ambos os sentidos podem usar depois de existir. Se uma nova ligação pode entrar do concentrador em direção a esse cliente é uma questão de política do gateway, não uma propriedade de quem se ligou. Num concentrador OpenVPN encaminhado, por exemplo, o servidor precisa de uma rota para o endereço interno do cliente e de encaminhamento que permita a relação entre pares.

Imagine um sistema de inventário que consulta um agente em portáteis em roaming, ou um programador que precisa de uma API de teste a partir de uma estação de trabalho em casa. Ambos querem que o lado do escritório inicie a conversa, o que é o inverso do padrão habitual cliente-servidor.

Os produtos de acesso remoto alojados variam neste ponto, e a variação não é um erro. Algumas VPN de serviço gerido bloqueiam deliberadamente ligações não solicitadas para clientes ligados porque o seu modelo é cliente-para-recurso e não recurso-para-cliente. Leia a arquitetura documentada do produto antes de prometer a um colega que o portátil dele pode funcionar como servidor.

Siga o caminho de retorno antes de abrir uma porta

O caminho tem três partes: uma rota no gateway que aponta para o endereço interno do cliente, uma política que permite o chamador concreto e um serviço à escuta no alvo. Cada parte falha de forma diferente, por isso «a VPN está ativa» quase não diz nada.

A boa notícia é que o caminho interno não precisa de reencaminhamento de portas no router de casa do cliente. É esse o sentido de publicar o serviço no endereço do túnel em vez do endereço WAN de casa, onde a exposição e as regras NAT seriam completamente diferentes. Um router doméstico também pode recusar fazer hairpin de uma ligação que chega do escritório, pelo que a rota WAN falha por motivos alheios à sua VPN. Manter o tráfego dentro do túnel evita os dois problemas ao mesmo tempo.

Verifique também o lado do alvo. Um serviço ligado apenas a 127.0.0.1 não pode aceitar uma ligação que chegue pela interface do túnel, por mais corretas que sejam as rotas do gateway. Uma regra de firewall do host que permita a porta apenas a partir da sub-rede local também descartará o tráfego do escritório, e essa regra é independente da política VPN acima.

Nomes e endereços são decisões de conceção

Um endereço dentro do túnel não é automaticamente um nome. Um registo DNS privado que controla é mais claro do que esperar que um protocolo de descoberta atravesse o túnel, porque a resolução de nomes por multicast de ligação local fica no segmento local e não se torna DNS entre sub-redes.

A estabilidade do endereço importa tanto como o resto. Se os clientes VPN retirarem de um conjunto com concessões curtas, o endereço interno do portátil muda entre sessões e cada marcador, âmbito de firewall e verificação de monitorização construídos sobre ele quebram em silêncio. Use uma reserva ou um caminho documentado de atualização dinâmica.

Combine o nome com quem é dono da identidade VPN, para que o registo, a atribuição de endereço e a política de acesso mudem em conjunto em vez de em três tickets separados.

Teste o serviço, não a pertença

A partir do alvo, confirme o que está à escuta e em que endereço, e depois confirme a visão do gateway do caminho de retorno:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Agora teste do lado do escritório com um pedido real em vez de um eco. Um curl bem-sucedido contra o serviço prova a rota, a política e o ouvinte ao mesmo tempo, enquanto um ping bem-sucedido só prova que o ICMP é permitido. Se o pedido falhar, recue pelas três partes em vez de alargar a firewall e esperar.

A disponibilidade pertence à mesma conversa. Um portátil dorme, transita entre redes e desliga-se ao fim do dia. Um serviço que tem de responder a qualquer hora pertence a um host sempre ligado, enquanto um serviço de melhor esforço pode ficar no cliente com essa limitação registada.

Publique o recurso deliberadamente, com um nome, uma lista de chamadores autorizados e um proprietário, e o dispositivo remoto torna-se um serviço suportado em vez de um servidor acidental.