Ping fungerar men SSH misslyckas över VPN: vilket steg gick sönder?
Ett enda utförligt försök skiljer TCP-nåbarhet, SSH-transport, värdidentitet, användarinloggning och sessionsbehörighet, så att du slutar gissa på tunneln.
Ping-svar och en nekad SSH-inloggning kan båda vara sanna samtidigt, och paret pekar inte ut tunneln. Ekkosvar och en TCP-anslutning till port 22 är olika tester med olika selektorer, olika policyer och ofta olika mål. Fånga ett medvetet SSH-försök och namnge sedan det sista steget det nådde. Den enda artefakten ersätter ett dussin spekulativa konfigurationsändringar.
Fånga ett försök, inte en session av petande
Kör klienten en gång med utförlig diagnostik, avstängd anslutningsdelning och en begränsad anslutningstidsgräns. Att stänga av delning spelar roll eftersom en tidigare autentiserad huvudanslutning annars svarar för det nya försöket och döljer felet du jagar.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Behåll målet, adressfamiljen, tidsstämpeln och det sista icke-hemliga felet. IPv4-flaggan betyder också att detta försök inte säger något om en IPv6-väg till samma namn, så generalisera inte utifrån det. Anteckna varifrån försöket gjordes. En kontroll på VPN-gatewayen är inte samma utsiktspunkt som en laptop bakom den, och de flesta motsägelserna i dessa ärenden kommer av att blanda de två.
Steg ett och två: TCP före SSH
Den första gränsen är socketens nåbarhet: en adress, en port och en rutt som paketet faktiskt följer. Om TCP-anslutningen aldrig fullbordas finns inget ovanför den ännu, och värdnycklar och konton är irrelevanta.
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'Korrelera inspelningen med klientförsöket. Ett SYN som går ut och inget som kommer tillbaka pekar på filtrering, selektorer eller en saknad rutt på andra sidan; ett svar med reset pekar på något som aktivt avvisar i stället för att släppa. Den andra gränsen är själva SSH-protokollutbytet. En TCP-anslutning som fullbordas och sedan stannar har passerat nåbarheten och gått in i förhandling, serversvar eller pakethantering. Det är en annan utredning, och det är där storleksrelaterade problem först blir troliga.
Steg tre: vems nyckel svarade
När transporten är uppe verifierar klienten serverns värdnyckel. En avvisning här är ett uttalande om identitet, inte om kryptografi: motparten presenterade en nyckel som din policy inte accepterar. Behandla det som ett stoppvillkor och verifiera utanför bandet, mot konsolen eller operatören som byggde om värden. Att radera den sparade posten för att bli av med varningen är den enda genvägen du bör avvisa, eftersom den förstör beviset för att något svarade oväntat.
Om värden verkligen byggdes om, ta bort den gamla posten först efter att det nya fingeravtrycket bekräftats, och notera datum och orsak. Nästa ingenjör möter samma varning och behöver den kontexten.
Steg fyra och fem: konto kontra behörighet
Autentisering är den fjärde gränsen. Avvisade uppgifter betyder att servern utvärderade försöket och avvisade det; kontrollera kontot, typen av uppgifter som servern accepterar och serverns egen policy i stället för VPN-lösenordet. Den femte gränsen är auktorisering efter lyckad inloggning. En autentiserad användare kan fortfarande nekas ett skal, ett kommando, ett delsystem eller vidarebefordran, och de avslagen ser ut som fel för den som bara läser klientens sista rad.
| 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 |
Sluta efter ett par misslyckade lösenordsförsök. Upprepade gissningar skapar utelåsningar som sedan ser ut som ett andra, oberoende fel och kostar mer tid än det ursprungliga ärendet.
Återställning och den dokumentation du behåller
Ändra en sak i taget och skriv ned vad du ändrade innan du testar igen. Om en ändring försämrar försöket, återställ den omedelbart i stället för att stapla ännu en rättelse ovanpå. Upprepa den ursprungliga åtgärden från den ursprungliga klienten och kontexten. En lyckad inloggning från en annan maskin, i en annan adressfamilj, är ingen reproduktion och bevisar inte rättelsen.
Sanera det du delar. Utförlig klientutdata kan bära interna namn, kontomärken, nyckelsökvägar och identifikatorer för offentliga nycklar, så publicera den stegvisa slutsatsen i stället för ett råspår.