Hipervisor do laboratório doméstico inacessível por VPN: onde olhar

O túnel sobe, a página web do hipervisor expira e o cliente diz que está conectado. Essa combinação descarta muita coisa: o handshake da VPN funciona, o cliente tem um endereço e o endpoint é alcançável. O que resta é uma lista curta de questões de roteamento e política, e elas têm uma ordem natural. Trabalhe-as do hipervisor para fora e não do cliente para dentro, porque o próprio estado do hipervisor é o mais barato de confirmar.

Comece pelo segmento de gestão

Confirme o endereço de gestão do hipervisor e o serviço que escuta nele, e confirme que a página carrega a partir de outro host nesse segmento antes de diagnosticar qualquer coisa remotamente. Um teste local que falha não é problema de VPN, e é uma verificação de cinco minutos que poupa uma hora.

Depois os dois caminhos. O cliente VPN precisa de uma rota para a rede de gestão, o que normalmente significa que os AllowedIPs do cliente ou as rotas empurradas incluem essa sub-rede. O hipervisor, ou o seu gateway predefinido, precisa de um caminho de retorno para o pool de endereços dos clientes, a menos que o desenho traduza deliberadamente a origem na entrada. São dois factos separados e a falta de qualquer um produz o mesmo tempo limite. Verifique-os em separado: ip route get 192.168.10.20 no cliente, e uma captura no host do hipervisor que mostre se o pacote chegou.

Permita o administrador remoto real

A autorização é uma questão separada da alcançabilidade. Use política de gateway e de host limitada às fontes e serviços que precisam de acesso de gestão. Uma conta de VPN de convidado que precisa de uma aplicação do laboratório não deve, por isso, chegar ao plano de gestão, e uma regra plana que admite toda a sub-rede do túnel é como isso acontece.

Mantenha ativas a autenticação do próprio hipervisor e as verificações de certificado. Uma rota privada não é motivo para clicar através de um aviso de identidade inesperado.

Vale a pena tratar o aviso como uma constatação e não como um obstáculo. Se o certificado não corresponde ao nome que usou, ou o nome está errado ou o serviço não é o que pensa, e ambas as respostas contam mais numa interface de gestão do que em qualquer outro lugar. Chegue à página pelo nome para o qual o certificado foi emitido, e deixe o DNS apontar esse nome para o endereço do túnel. Um nome privado que se resolve de forma inconsistente entre a LAN e o túnel é uma causa comum de queixas de certificado que parecem falhas de VPN.

Verifique as ligações secundárias

Algumas funcionalidades usam ligações que a página web não usa. Uma sessão de consola, um envio de ISO, um proxy VNC ou SPICE e um canal de migração podem usar, cada um, uma porta diferente ou um endereço de host diferente. Quando a página carrega e uma funcionalidade falha, leia o requisito desse produto em vez de abrir todas as portas do host.

Abrir tudo é como uma interface de gestão se torna numa interface não gerida. Cada porta adicional é mais um ouvinte para manter atualizado, e um hipervisor já expõe bastantes. Identifique a ligação concreta de que a funcionalidade precisa, confirme que é alcançável através do túnel e deixe o resto fechado. Se a funcionalidade insistir numa ligação direta a um endereço de host que não é encaminhável pelo seu túnel, isso é uma restrição de desenho a contornar deliberadamente, não um motivo para encaminhar um intervalo.

Guarde um caminho de volta antes de tocar na rede

Antes de alterar a rede virtual que transporta a sua própria VPN, confirme que tem um caminho de volta local ou independente.

Isto importa mais num laboratório doméstico, porque o endpoint da VPN é frequentemente uma máquina virtual no próprio hipervisor que está a tentar alcançar. Alterar um comutador virtual, uma ponte ou uma regra de firewall remotamente pode remover o caminho que está a usar, e a sessão pode sobreviver o suficiente para o ver acontecer.

Teste de fora do laboratório e não da LAN, e verifique as recusas tal como as permissões. Uma rede que deve permanecer inalcançável a partir do túnel deve continuar a sê-lo depois da sua alteração, e isso é uma afirmação separada do carregamento da página de gestão. Anote ambos os resultados, porque o segundo é o que é omitido e o que importa quando o laboratório cresce.

O registo a guardar é curto: o endereço e o serviço de gestão, a rota de que cada lado precisa, as identidades autorizadas a chegar e o caminho de recuperação. Isso chega para a pessoa seguinte reproduzir o estado funcional sem o deduzir de novo.

Se a página ainda expirar depois de tudo isso, capture no hipervisor e procure o pacote antes de mudar outra regra. Um pacote que nunca chega é uma questão de encaminhamento ou de firewall; um pacote que chega e é recusado é uma questão de serviço ou de política; um pacote que chega e recebe resposta enquanto o cliente espera é uma questão de caminho de volta. A documentação do strongSwan sobre encaminhamento explica como um gateway Linux encaminha o tráfego do túnel para um host interno. Três capturas valem mais do que mais um palpite.