Bloqueado fora do seu servidor VPN: mantenha uma segunda via de entrada
Um túnel quebrado não deve tirar também a sua capacidade de reparar o servidor. Planeje, teste e revise uma via administrativa independente antes de precisar dela.
Você abre o console, altera uma regra de firewall e o túnel pelo qual estava conectado desaparece. A mudança estava correta, a recarga não, e agora a única rota de volta à máquina é a que você acabou de quebrar. Uma segunda via de entrada é uma decisão de projeto, e ela precisa existir antes da queda, não durante.
Reveja o que você ainda tem
Comece pela tela do console à sua frente e liste as vias que não dependem do túnel. Um console web do provedor com uma sessão serial ou VNC é uma. Uma interface de gestão numa rede separada é outra. O acesso físico é a terceira, e é aquela cuja falta as pessoas descobrem no pior momento.
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
Leia a terceira coluna como uma lista de falhas e não como uma abstração. Duas dessas vias costumam falhar pelo mesmo motivo. A tabela é como você percebe isso antes que uma queda lhe explique.
Independência é uma questão de dependências
Uma conta de recuperação não é independente se a senha dela estiver guardada num serviço que você alcança pelo túnel. Uma segunda VPN no mesmo host, na mesma porta e com a mesma política de firewall também não é independente, porque a mudança que quebrou a primeira quebra as duas.
Desça pela cadeia e nomeie o que cada passo precisa. Alcance de rede, resolução de nomes, uma fonte de autenticação e o próprio serviço de gestão são quatro dependências separadas, e uma via que compartilhe qualquer uma delas herda essa falha.
A via que nunca foi testada merece a sua própria desconfiança. Um console que não é aberto há meses pode exigir redefinição de senha por e-mail, e essa caixa de correio pode estar hospedada na máquina que você não alcança. Teste a via enquanto tudo funciona e você descobrirá isso numa tarde tranquila.
Use a segunda via para uma mudança controlada
Pelo console, tire um snapshot ou copie a configuração que você vai editar. Mude uma coisa. Recarregue o serviço e leia o resultado antes de tocar em qualquer outra coisa, porque duas mudanças de uma vez transformam uma recuperação num experimento.
Mantenha a sessão de recuperação aberta enquanto faz isso. Todo o valor da segunda via é que ela sobrevive ao que você está mudando, então fechá-la primeiro remove a única propriedade que a tornava útil.
Verifique pela via de recuperação, não pela memória
A verificação que importa é se a via normal volta, e a sessão de recuperação é onde você confirma isso em ordem:
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
Leia primeiro o estado do serviço, depois o ouvinte, depois as regras, depois o registro. Um serviço que roda sem ouvinte aponta para a configuração do serviço, enquanto um ouvinte sem regras alcançáveis aponta para a filtragem. A ordem importa porque cada passo estreita o seguinte, e pular para o registro costuma significar ler erros que descrevem o sintoma e não a causa.
A documentação do systemctl cobre o comportamento de estado e reinício usado aqui, incluindo como uma recarga que falha deixa o processo anterior em execução. Restaurar uma revisão coerente é melhor do que reconectar repetidamente de um cliente que não consegue reparar o servidor. Se a condição de reversão definida antes da mudança foi cumprida, restaure e pare.
Mantenha o inventário atualizado
Revise a lista de acesso quando as pessoas ou a infraestrutura mudam. Teste a via de recuperação enquanto tudo funciona. Aposente as contas que ninguém usou desde a última reorganização. Duas contas obsoletas e um certificado vencido são uma pequena limpeza numa terça e uma queda num domingo.
Registre quem pode usar cada via, o que ela permite e como as credenciais são rotacionadas. Uma via de recuperação sem dono torna-se uma entrada esquecida, que é um tipo de falha diferente de ficar trancado fora.