Ping virker, men SSH fejler over VPN: hvilken fase gik i stykker?
Et enkelt udførligt forsøg adskiller TCP-rækkevidde, SSH-transport, værtsidentitet, brugerlogin og sessionstilladelse, så du holder op med at gætte på tunnelen.
Ping-svar og et afvist SSH-login kan begge være sande på én gang, og parret peger ikke på tunnelen. Ekkosvar og en TCP-forbindelse til port 22 er forskellige tests med forskellige selektorer, forskellige politikker og ofte forskellige destinationer. Optag ét bevidst SSH-forsøg, og navngiv derefter den sidste fase, det nåede. Det ene artefakt erstatter et dusin spekulative konfigurationsændringer.
Optag ét forsøg, ikke en session med prikkeri
Kør klienten én gang med udførlig diagnostik, deling af forbindelse slået fra og en begrænset forbindelsestimeout. At slå deling fra betyder noget, fordi en tidligere godkendt hovedforbindelse ellers svarer på det nye forsøg og skjuler den fejl, du jager.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Behold destinationen, adressefamilien, tidsstemplet og den sidste ikke-hemmelige fejl. IPv4-flaget betyder også, at dette forsøg intet siger om en IPv6-rute til det samme navn, så generaliser ikke ud fra det. Notér, hvor forsøget blev gjort fra. En kontrol på VPN-gatewayen er ikke samme synspunkt som en laptop bag den, og de fleste modsigelser i disse sager kommer af at blande de to.
Fase et og to: TCP før SSH
Den første grænse er socketens rækkevidde: en adresse, en port og en rute, som pakken faktisk følger. Hvis TCP-forbindelsen aldrig fuldføres, findes der endnu intet oven over den, og værtsnøgler og konti 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'Korrelér optagelsen med klientens forsøg. Et SYN, der forlader, og intet der vender tilbage, peger på filtrering, selektorer eller en manglende rute i den fjerne ende; et svar med et reset peger på noget, der aktivt afviser i stedet for at droppe. Den anden grænse er selve SSH-protokoludvekslingen. En TCP-forbindelse, der fuldføres og derefter går i stå, har passeret rækkevidden og er gået ind i forhandling, serversvar eller pakkehåndtering. Det er en anden undersøgelse, og det er der, størrelsesrelaterede problemer først bliver sandsynlige.
Fase tre: hvis nøgle svarede
Når transporten er oppe, verificerer klienten serverens værtsnøgle. En afvisning her er en udtalelse om identitet, ikke om kryptografi: modparten fremviste en nøgle, som din politik ikke accepterer. Behandl det som en stopbetingelse, og verificér uden for båndet, mod konsollen eller den operatør, der genopbyggede værten. At slette den huskede post for at fjerne advarslen er den ene genvej, du bør afvise, fordi den ødelægger beviset for, at noget svarede uventet.
Hvis værten virkelig blev genopbygget, skal du først fjerne den forældede post, når det nye fingeraftryk er bekræftet, og notere dato og årsag. Den næste ingeniør møder samme advarsel og har brug for den kontekst.
Fase fire og fem: konto kontra tilladelse
Godkendelse er den fjerde grænse. Afviste legitimationsoplysninger betyder, at serveren vurderede forsøget og afviste det; kontrollér kontoen, den type legitimationsoplysninger serveren accepterer, og serverens egen politik i stedet for VPN-adgangskoden. Den femte grænse er autorisation efter vellykket login. En godkendt bruger kan stadig nægtes en shell, en kommando, et undersystem eller videresendelse, og de afvisninger ligner fejl for nogen, der kun læser klientens sidste linje.
| 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 |
Stop efter et par mislykkede adgangskodeforsøg. Gentagne gæt skaber lockouts, som derefter ligner en anden, uafhængig fejl og koster mere tid end den oprindelige sag.
Tilbagerulning og den registrering, du beholder
Ændr én ting ad gangen, og skriv ned, hvad du ændrede, før du tester igen. Hvis en ændring gør forsøget værre, skal du straks rulle den tilbage i stedet for at stable endnu en rettelse ovenpå. Gentag den oprindelige handling fra den oprindelige klient og kontekst. Et vellykket login fra en anden maskine, på en anden adressefamilie, er ikke en gengivelse og beviser ikke rettelsen.
Sanitér det, du deler. Udførlig klientoutput kan bære interne navne, kontomærker, nøglestier og offentlige nøgleidentifikatorer, så offentliggør den faseopdelte konklusion i stedet for et råt spor.