O ping funciona mas o SSH falha pela VPN: qual etapa quebrou?
Uma única tentativa detalhada separa a acessibilidade TCP, o transporte SSH, a identidade do host, o login do usuário e a permissão de sessão, para você parar de adivinhar sobre o túnel.
Respostas de ping e um login SSH recusado podem ser verdadeiros ao mesmo tempo, e o par não incrimina o túnel. Respostas de eco e uma conexão TCP à porta 22 são testes diferentes com seletores diferentes, políticas diferentes e muitas vezes destinos diferentes. Capture uma tentativa SSH deliberada e depois nomeie a última etapa que ela alcançou. Esse único artefato substitui uma dúzia de mudanças especulativas de configuração.
Capture uma tentativa, não uma sessão de cutucadas
Execute o cliente uma vez com diagnósticos detalhados, compartilhamento de conexão desativado e um tempo limite de conexão limitado. Desativar o compartilhamento importa porque uma conexão mestre já autenticada responderia pela nova tentativa e esconderia a falha que você está perseguindo.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Guarde o destino, a família de endereços, o carimbo de data e hora e o último erro não secreto. O sinalizador IPv4 também significa que esta tentativa não diz nada sobre um caminho IPv6 para o mesmo nome, então não generalize a partir dela. Anote de onde a tentativa foi feita. Uma verificação no gateway da VPN não é o mesmo ponto de vista que um notebook atrás dele, e a maioria das contradições nesses chamados vem de misturar os dois.
Etapas um e dois: TCP antes do SSH
A primeira fronteira é a acessibilidade do socket: um endereço, uma porta e uma rota que o pacote realmente segue. Se a conexão TCP nunca se completa, ainda não existe nada acima dela, e chaves de host e contas são irrelevantes.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'Correlacione a captura com a tentativa do cliente. Um SYN que sai e nada que retorna aponta para filtragem, seletores ou uma rota ausente do outro lado; uma resposta com reset aponta para algo que rejeita ativamente em vez de descartar. A segunda fronteira é a troca do protocolo SSH em si. Uma conexão TCP que se completa e depois trava passou da acessibilidade e entrou em negociação, resposta do servidor ou tratamento de pacotes. Essa é outra investigação, e é onde os problemas relacionados ao tamanho se tornam plausíveis pela primeira vez.
Etapa três: qual chave respondeu
Quando o transporte está ativo, o cliente verifica a chave de host do servidor. Uma rejeição aqui é uma afirmação sobre identidade, não sobre criptografia: o par apresentou uma chave que sua política não aceita. Trate isso como condição de parada e verifique fora de banda, contra o console ou o operador que reconstruiu o host. Apagar a entrada memorizada para limpar o aviso é o único atalho que você deve recusar, porque destrói a evidência de que algo respondeu inesperadamente.
Se o host realmente foi reconstruído, remova o registro obsoleto somente depois de confirmar a nova impressão digital, e anote a data e o motivo. O próximo engenheiro encontrará o mesmo aviso e precisa desse contexto.
Etapas quatro e cinco: conta versus permissão
A autenticação é a quarta fronteira. Credenciais rejeitadas significam que o servidor avaliou a tentativa e a recusou; verifique a conta, o tipo de credencial que o servidor aceita e a política do próprio servidor em vez da senha da VPN. A quinta fronteira é a autorização após um login bem-sucedido. Um usuário autenticado ainda pode ter negado um shell, um comando, um subsistema ou um encaminhamento, e essas recusas parecem falhas para quem lê apenas a última linha do cliente.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
Pare depois de algumas tentativas de senha malsucedidas. Suposições repetidas produzem bloqueios que depois parecem uma segunda falha não relacionada e custam mais tempo do que o chamado original.
Reversão e o registro que você mantém
Mude uma coisa de cada vez e anote o que mudou antes de testar novamente. Se uma mudança piora a tentativa, reverta-a imediatamente em vez de empilhar outra correção por cima. Repita a operação original a partir do cliente e do contexto originais. Um login bem-sucedido de outra máquina, em outra família de endereços, não é uma reprodução e não prova a correção.
Sanitize o que você compartilha. A saída detalhada do cliente pode conter nomes internos, rótulos de conta, caminhos de chaves e identificadores de chaves públicas, então publique a conclusão por etapas em vez de um rastro bruto.