Bloqueado por um ciclo de novas tentativas VPN: pare o cliente primeiro

Às 02:40 a conta é bloqueada e não há ninguém ao teclado. Um cliente numa prateleira continua a apresentar a palavra-passe que guardou no mês passado, a gateway continua a rejeitá-la, e o contador por trás do bloqueio sobe sem que nenhuma pessoa intervenha. Isto é um ciclo de novas tentativas e não um ataque, e tem de ser parado antes de a conta poder ser recuperada.

Trate-o como dois problemas numa ordem fixa. Pare primeiro o emissor e só depois restaure o acesso, porque fazer o contrário reinicia o ciclo em poucos minutos.

Descubra qual processo está a enviar as falhas

Comece pelas marcas temporais do sistema de identidade e compare-as com cada cliente que tem a conta. Um perfil gerido, um serviço sem supervisão, um telefone numa gaveta e um portátil de reserva com credenciais antigas podem todos autenticar-se como a mesma pessoa. O que falha a cada poucos segundos é o ciclo, e o que falha uma vez por dia costuma ser uma pessoa que se esqueceu. Ambos alimentam o mesmo contador, e é aí que está a armadilha.

Ao observar, distinga uma rejeição de uma gateway inacessível. Um tempo de espera esgotado, uma falha de resolução de nomes ou uma porta fechada normalmente não aumentam um contador de falhas, enquanto uma troca de autenticação concluída que devolve um resultado de credencial inválida aumenta. Misturar as duas produz a correção errada, porque uma exige o cliente parado e a outra exige o caminho reparado.

Três condições que decidem a resposta

Três factos reduzem isto a uma resposta. Primeiro, se o registo mostra uma rejeição explícita ou uma falha de transporte. Segundo, se a identidade é partilhada entre dispositivos ou serviços. Terceiro, se o cliente que repete é um que administra ou um que outra pessoa controla.

Uma rejeição explícita de um único cliente que controla significa parar esse cliente, desbloquear pela via aprovada e fazer um único início de sessão deliberado. Uma identidade partilhada empurra a resposta para o aprovisionamento e não para o desbloqueio, porque o ciclo recomeça no momento em que o outro dispositivo se voltar a ligar. As falhas de transporte apontam para a camada de rede, onde a proteção da conta não é de todo o assunto.

Nenhum desses ramos implica enfraquecer a proteção. Os limiares de bloqueio e os limites de taxa existem porque o mesmo sinal que o incomoda durante uma falha é o sinal que abranda uma tentativa de adivinhar a palavra-passe.

Pare o emissor antes de desbloquear

Pare a unidade ou a ligação que continua a autenticar-se, e pare-a de uma forma que sobreviva a um reinício. Colocar o cliente em pausa não chega quando o serviço está configurado para arrancar automaticamente no arranque.

# which unit is presenting the credential?
journalctl -u openvpn-client@home --since '20 min ago' | grep -i 'auth\|error'

# stop it, and keep it stopped across reboots
sudo systemctl stop openvpn-client@home
sudo systemctl disable openvpn-client@home
systemctl is-active openvpn-client@home

Espere alguns minutos e confirme que o contador de falhas deixa de se mover. Essa pausa é a prova de que encontrou a fonte certa. Se as falhas continuarem, o ciclo vem de outro lugar e o passo de desbloqueio teria sido desperdiçado.

Só então use o processo de desbloqueio ou recuperação documentado do operador, e siga-o com exatamente um início de sessão controlado a partir do dispositivo que pretende manter. Os limiares exatos, os períodos de arrefecimento e a redação da recuperação são específicos de cada serviço, por isso leia-os em vez de adivinhar um número.

Remova a causa para que não regresse

Atualize a credencial guardada onde é propriedade: no porta-chaves do sistema operativo, no perfil do cliente ou na configuração da conta de serviço. Apagá-la de um sítio enquanto outro guarda uma cópia é como o ciclo volta uma semana depois, normalmente quando um portátil que estava offline regressa e reproduz o seu valor em cache.

Dê à automatização uma identidade própria. Uma conta aprovisionada em separado com a sua própria credencial e os seus próprios limites impede que uma falha de máquina deixe uma pessoa fora do correio, e torna a falha atribuível nos registos. Adicione um recuo ao cliente para que uma credencial rejeitada pare as novas tentativas em vez de as repetir, e dispare um alarme em falhas de autenticação repetidas para que o ciclo seguinte seja notado em minutos e não às 02:40.

Quando o relatório vai para o suporte, guarde o identificador da conta, as marcas temporais e o nome do cliente. As palavras-passe e o material de recuperação nunca pertencem a esse registo.