Ping werkt maar SSH faalt over de VPN: welke fase is stuk?
Eén uitgebreide poging scheidt TCP-bereikbaarheid, SSH-transport, hostidentiteit, gebruikersaanmelding en sessietoestemming, zodat je stopt met gissen naar de tunnel.
Ping-antwoorden en een geweigerde SSH-aanmelding kunnen tegelijk waar zijn, en het paar beschuldigt de tunnel niet. Echo-antwoorden en een TCP-verbinding naar poort 22 zijn verschillende tests met verschillende selectors, verschillende beleidsregels en vaak verschillende bestemmingen. Leg één bewuste SSH-poging vast en benoem dan de laatste fase die hij bereikte. Dat ene artefact vervangt een dozijn speculatieve configuratiewijzigingen.
Leg één poging vast, geen sessie van porren
Voer de client één keer uit met uitgebreide diagnostiek, delen van verbindingen uitgeschakeld en een begrensde verbindingstime-out. Delen uitschakelen is belangrijk, want een eerder geauthenticeerde hoofdverbinding antwoordt anders voor de nieuwe poging en verbergt de fout die je jaagt.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Bewaar de bestemming, de adresfamilie, de tijdstempel en de laatste niet-geheime fout. De IPv4-vlag betekent ook dat deze poging niets zegt over een IPv6-route naar dezelfde naam, dus generaliseer daar niet uit. Noteer vanwaar de poging is gedaan. Een controle op de VPN-gateway is niet hetzelfde gezichtspunt als een laptop erachter, en de meeste tegenstrijdigheden in deze tickets komen van het door elkaar halen van beide.
Fase één en twee: TCP vóór SSH
De eerste grens is de bereikbaarheid van de socket: een adres, een poort en een route die het pakket werkelijk volgt. Als de TCP-verbinding nooit tot stand komt, bestaat er nog niets boven, en hostsleutels en accounts zijn irrelevant.
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'Correleer de opname met de clientpoging. Een SYN die vertrekt en niets dat terugkomt wijst op filtering, selectors of een ontbrekende route aan de andere kant; een antwoord met een reset wijst op iets dat actief weigert in plaats van te laten vallen. De tweede grens is de SSH-protocoluitwisseling zelf. Een TCP-verbinding die tot stand komt en dan blijft hangen, is voorbij de bereikbaarheid en in onderhandeling, serverantwoord of pakketafhandeling beland. Dat is een ander onderzoek, en daar worden groottegerelateerde problemen voor het eerst plausibel.
Fase drie: wiens sleutel antwoordde
Zodra het transport staat, verifieert de client de hostsleutel van de server. Een weigering hier is een uitspraak over identiteit, niet over cryptografie: de tegenpartij presenteerde een sleutel die jouw beleid niet accepteert. Behandel dat als stopvoorwaarde en verifieer buiten de band, via de console of de operator die de host herbouwde. Het opgeslagen item wissen om de waarschuwing weg te krijgen is de enige snelkoppeling die je moet weigeren, omdat die het bewijs vernietigt dat er iets onverwachts antwoordde.
Is de host echt herbouwd, verwijder het verouderde record dan pas nadat de nieuwe vingerafdruk is bevestigd, en noteer datum en reden. De volgende engineer krijgt dezelfde waarschuwing en heeft die context nodig.
Fase vier en vijf: account tegenover toestemming
Authenticatie is de vierde grens. Geweigerde inloggegevens betekenen dat de server de poging beoordeelde en weigerde; controleer het account, het type inloggegevens dat de server accepteert en het eigen beleid van de server in plaats van het VPN-wachtwoord. De vijfde grens is autorisatie na een geslaagde aanmelding. Een geauthenticeerde gebruiker kan alsnog een shell, een opdracht, een subsysteem of doorsturing worden geweigerd, en die weigeringen lijken op storingen voor wie alleen de laatste regel van de client leest.
| 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 na een paar mislukte wachtwoordpogingen. Herhaalde gissingen veroorzaken blokkades die er daarna als een tweede, ongerelateerde fout uitzien en meer tijd kosten dan het oorspronkelijke ticket.
Terugdraaien en het verslag dat je bijhoudt
Wijzig één ding tegelijk en schrijf op wat je hebt gewijzigd voordat je opnieuw test. Maakt een wijziging de poging erger, draai die dan onmiddellijk terug in plaats van er nog een correctie bovenop te stapelen. Herhaal de oorspronkelijke handeling vanaf de oorspronkelijke client en context. Een geslaagde aanmelding vanaf een andere machine, in een andere adresfamilie, is geen reproductie en bewijst de oplossing niet.
Sanitiseer wat je deelt. Uitgebreide clientuitvoer kan interne namen, accountlabels, sleutelpaden en identificaties van openbare sleutels bevatten, dus publiceer de gefaseerde conclusie in plaats van een ruwe trace.