Ping verkar, men SSH feilar over VPN: kva trinn braut saman?
Eitt detaljert forsøk skil TCP-nåbarheit, SSH-transport, vertsidentitet, brukarinnlogging og sesjonstilgang, slik at du sluttar å gissa på tunnelen.
Ping-svar og ei avvist SSH-innlogging kan begge vere sanne samtidig, og paret peikar ikkje på tunnelen. Ekkosvar og ei TCP-tilkopling til port 22 er ulike testar med ulike selektorar, ulike retningslinjer og ofte ulike mål. Ta opp eitt medvite SSH-forsøk, og nemn deretter det siste trinnet det nådde. Den eine artefakten erstattar eit dusin spekulative konfigurasjonsendringar.
Ta opp eitt forsøk, ikkje ei økt med pirking
Køyr klienten éin gong med detaljert diagnostikk, deling av tilkopling slått av og ei avgrensa tilkoplingstidsgrense. Å slå av deling har noko å seie fordi ei tidlegare autentisert hovudtilkopling elles svarar for det nye forsøket og skjuler feilen du jagar.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Hald på målet, adressefamilien, tidsstempelet og den siste ikkje-hemmelege feilen. IPv4-flagg betyr òg at dette forsøket ikkje seier noko om ein IPv6-rute til same namnet, så ikkje generaliser frå det. Noter kvar forsøket vart gjort frå. Ein sjekk på VPN-porten er ikkje same ståstad som ein laptop bak han, og dei fleste motsetningane i desse sakene kjem av å blande dei to.
Trinn éin og to: TCP før SSH
Den første grensa er nåbarheita til sokelen: ei adresse, ein port og ei rute som pakken faktisk følgjer. Viss TCP-tilkoplinga aldri vert fullført, finst det enno ingenting over henne, og vertsnøklar og kontoar er irrelevante.
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'Korreler opptaket med klientforsøket. Ein SYN som går ut og ingenting som kjem tilbake peikar på filtrering, selektorar eller ei manglande rute i den fjerne enden; eit svar med reset peikar på noko som aktivt avviser i staden for å droppe. Den andre grensa er sjølve SSH-protokollutvekslinga. Ei TCP-tilkopling som vert fullført og så stoppar, har passert nåbarheita og gått inn i forhandling, serversvar eller pakkehandtering. Det er ei anna undersøking, og det er der storleiksrelaterte problem først vert sannsynlege.
Trinn tre: kven sin nøkkel svara
Når transporten er oppe, verifiserer klienten vertsnøkkelen til serveren. Ei avvising her er ei utsegn om identitet, ikkje om kryptografi: motparten presenterte ein nøkkel som retningslinjene dine ikkje godtek. Sjå på det som ein stoppbetingelse og verifiser utanfor bandet, mot konsollen eller operatøren som bygde opp verten på nytt. Å sletta den hugsa oppføringa for å fjerna åtvaringa er den eine snarvvegen du bør avvise, fordi han øydelegg beviset for at noko svara uventa.
Viss verten verkeleg vart bygd opp på nytt, fjern den gamle oppføringa først etter at det nye fingeravtrykket er stadfesta, og noter dato og årsak. Den neste ingeniøren møter same åtvaringa og treng den konteksten.
Trinn fire og fem: konto kontra tilgang
Autentisering er den fjerde grensa. Avviste legitimasjonar betyr at serveren vurderte forsøket og avviste det; kontroller kontoen, typen legitimasjon serveren godtek, og serveren si eiga retningslinje i staden for VPN-passordet. Den femte grensa er autorisasjon etter vellukka innlogging. Ein autentisert brukar kan framleis nektast eit skal, ein kommando, eit undersystem eller vidaresending, og desse avvisingane ser ut som feil for nokon som berre les den siste lina til klienten.
| 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 |
Stopp etter eit par mislukka passordforsøk. Gjentekne gjettingar gjev utelåsingar som deretter ser ut som ein andre, urelatert feil og kostar meir tid enn den opphavlege saka.
Tilbakerulling og registreringa du held på
Endre éin ting om gongen, og skriv ned kva du endra før du testar på nytt. Viss ei endring gjer forsøket verre, rull henne tilbake med ein gong i staden for å stable nok ei retting oppå. Gjenta den opphavlege operasjonen frå den opphavlege klienten og konteksten. Ei vellukka innlogging frå ein annan maskin, på ein annan adressefamilie, er ikkje ein reproduksjon og beviser ikkje rettinga.
Sanitér det du deler. Detaljert klientutdata kan bera interne namn, kontomerke, nøkkelstiar og identifikatorar for offentlege nøklar, så publiser den trinnvise konklusjonen i staden for eit rått spor.