Il ping funziona ma SSH fallisce sulla VPN: quale fase si è rotta?
Un solo tentativo dettagliato separa la raggiungibilità TCP, il trasporto SSH, l'identità dell'host, l'accesso dell'utente e il permesso della sessione, così smetti di tirare a indovinare sul tunnel.
Le risposte al ping e un accesso SSH rifiutato possono essere entrambi veri nello stesso momento, e la coppia non incrimina il tunnel. Le risposte echo e una connessione TCP alla porta 22 sono test diversi con selettori diversi, politiche diverse e spesso destinazioni diverse. Cattura un tentativo SSH deliberato, poi nomina l'ultima fase che ha raggiunto. Quell'unico artefatto sostituisce una dozzina di modifiche di configurazione speculative.
Cattura un tentativo, non una sessione di tastatine
Esegui il client una volta con diagnostica dettagliata, condivisione della connessione disattivata e un timeout di connessione limitato. Disattivare la condivisione conta perché una connessione master già autenticata risponderebbe altrimenti per il nuovo tentativo e nasconderebbe il guasto che stai inseguendo.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Conserva la destinazione, la famiglia di indirizzi, il timestamp e l'ultimo errore non segreto. Il flag IPv4 significa anche che questo tentativo non dice nulla su un percorso IPv6 verso lo stesso nome, quindi non generalizzare da esso. Annota da dove è stato fatto il tentativo. Un controllo sul gateway VPN non è lo stesso punto di vista di un portatile dietro di esso, e la maggior parte delle contraddizioni in questi ticket nasce dal mescolare i due.
Fasi uno e due: TCP prima di SSH
Il primo confine è la raggiungibilità del socket: un indirizzo, una porta e una rotta che il pacchetto segue davvero. Se la connessione TCP non si completa mai, sopra di essa non esiste ancora nulla, e le chiavi host e gli account sono irrilevanti.
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'Correla la cattura con il tentativo del client. Un SYN che esce e nulla che torna indica filtraggio, selettori o una rotta mancante sul lato remoto; una risposta con reset indica qualcosa che rifiuta attivamente invece di scartare. Il secondo confine è lo scambio del protocollo SSH stesso. Una connessione TCP che si completa e poi si blocca ha superato la raggiungibilità ed è entrata in negoziazione, risposta del server o gestione dei pacchetti. È un'altra indagine, ed è lì che i problemi legati alla dimensione diventano plausibili per la prima volta.
Fase tre: quale chiave ha risposto
Quando il trasporto è attivo, il client verifica la chiave host del server. Un rifiuto qui è un'affermazione sull'identità, non sulla crittografia: il peer ha presentato una chiave che la tua politica non accetta. Trattalo come condizione di arresto e verifica fuori banda, contro la console o l'operatore che ha ricostruito l'host. Cancellare la voce memorizzata per eliminare l'avviso è l'unica scorciatoia da rifiutare, perché distrugge la prova che qualcosa ha risposto in modo inatteso.
Se l'host è stato davvero ricostruito, rimuovi il record obsoleto solo dopo la conferma della nuova impronta, e annota la data e il motivo. Il prossimo ingegnere incontrerà lo stesso avviso e ha bisogno di quel contesto.
Fasi quattro e cinque: account contro permesso
L'autenticazione è il quarto confine. Credenziali rifiutate significano che il server ha valutato il tentativo e lo ha rifiutato; controlla l'account, il tipo di credenziale accettato dal server e la politica del server stesso invece della password VPN. Il quinto confine è l'autorizzazione dopo un accesso riuscito. A un utente autenticato può ancora essere negata una shell, un comando, un sottosistema o un inoltro, e quei rifiuti sembrano guasti a chi legge solo l'ultima riga del client.
| 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 |
Fermati dopo un paio di tentativi di password falliti. Le supposizioni ripetute producono blocchi che poi sembrano un secondo guasto non correlato e costano più tempo del ticket originale.
Rollback e il registro che conservi
Cambia una cosa alla volta e annota cosa hai cambiato prima di ritestare. Se una modifica peggiora il tentativo, annullala subito invece di impilare un'altra correzione sopra. Ripeti l'operazione originale dal client e dal contesto originali. Un accesso riuscito da un'altra macchina, su un'altra famiglia di indirizzi, non è una riproduzione e non dimostra la correzione.
Ripulisci ciò che condividi. L'output dettagliato del client può trasportare nomi interni, etichette di account, percorsi di chiavi e identificatori di chiavi pubbliche, quindi pubblica la conclusione per fasi invece di una traccia grezza.