A ping működik, de az SSH nem megy át a VPN-en: melyik szakasz tört el?
Egyetlen részletes kísérlet választja szét a TCP elérhetőséget, az SSH szállítást, a hoszt identitását, a felhasználói bejelentkezést és a munkamenet engedélyét, hogy ne találgasson az alagútról.
A ping válaszok és egy elutasított SSH-bejelentkezés egyszerre is igaz lehet, és a pár nem az alagutat terheli. Az echo válaszok és a 22-es porthoz irányuló TCP-kapcsolat különböző tesztek különböző szelektorokkal, különböző házirendekkel és gyakran különböző célokkal. Rögzítsen egy szándékos SSH-kísérletet, majd nevezze meg az utolsó szakaszt, amelyet elért. Az az egyetlen artefaktum tucatnyi spekulatív konfigurációmódosítást vált ki.
Egy kísérletet rögzítsen, ne egy bökdösésekből álló munkamenetet
Futtassa a klienst egyszer részletes diagnosztikával, kikapcsolt kapcsolatmegosztással és korlátozott kapcsolódási időkorláttal. A megosztás kikapcsolása azért számít, mert egy korábban hitelesített főkapcsolat válaszolna helyette az új kísérletre, és elrejtené a keresett hibát.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Őrizze meg a célt, a címcsaládot, az időbélyeget és az utolsó nem titkos hibát. Az IPv4 jelző azt is jelenti, hogy ez a kísérlet semmit sem mond az ugyanahhoz a névhez vezető IPv6-útvonalról, ezért ne általánosítson belőle. Jegyezze fel, honnan történt a kísérlet. A VPN-átjárón végzett ellenőrzés nem ugyanaz a nézőpont, mint a mögötte lévő laptop, és ezekben a jegyekben a legtöbb ellentmondás a kettő keveréséből ered.
Első és második szakasz: TCP az SSH előtt
Az első határ a socket elérhetősége: egy cím, egy port és egy útvonal, amelyet a csomag ténylegesen követ. Ha a TCP-kapcsolat soha nem jön létre, felette még semmi sem létezik, és a hosztkulcsok meg a fiókok irrelevánsak.
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álja a rögzítést a kliens kísérletével. Egy kimenő SYN, amelyre semmi sem érkezik vissza, szűrésre, szelektorokra vagy egy hiányzó útvonalra utal a túloldalon; a visszaállítással érkező válasz arra utal, hogy valami aktívan elutasít, nem pedig eldob. A második határ maga az SSH-protokoll cserefolyamata. Egy TCP-kapcsolat, amely létrejön, majd megakad, túljutott az elérhetőségen, és tárgyalásba, kiszolgálóválaszba vagy csomagkezelésbe lépett. Az más vizsgálat, és ott válnak először valószínűvé a mérethez kapcsolódó problémák.
Harmadik szakasz: kinek a kulcsa válaszolt
Amikor a szállítás áll, a kliens ellenőrzi a kiszolgáló hosztkulcsát. Az itteni elutasítás identitásról szóló kijelentés, nem kriptográfiáról: a partner olyan kulcsot mutatott be, amelyet a házirendje nem fogad el. Kezelje ezt megállási feltételként, és ellenőrizze sávon kívül, a konzolnál vagy a hosztot újraépítő üzemeltetőnél. Az emlékezett bejegyzés törlése a figyelmeztetés eltüntetéséhez az az egyetlen rövidítés, amelyet el kell utasítani, mert megsemmisíti annak bizonyítékát, hogy valami váratlanul válaszolt.
Ha a hoszt valóban újraépült, csak az új ujjlenyomat megerősítése után távolítsa el a régi bejegyzést, és jegyezze fel a dátumot és az okot. A következő mérnök ugyanazzal a figyelmeztetéssel találkozik, és szüksége van erre a kontextusra.
Negyedik és ötödik szakasz: fiók kontra engedély
A hitelesítés a negyedik határ. Az elutasított hitelesítő adatok azt jelentik, hogy a kiszolgáló kiértékelte a kísérletet és elutasította; ellenőrizze a fiókot, a kiszolgáló által elfogadott hitelesítő adat típusát és magát a kiszolgáló házirendjét, nem a VPN-jelszót. Az ötödik határ az engedélyezés sikeres bejelentkezés után. Egy hitelesített felhasználótól még mindig megtagadható egy shell, egy parancs, egy alrendszer vagy egy továbbítás, és ezek az elutasítások hibáknak tűnnek annak, aki csak a kliens utolsó sorát olvassa.
| 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 |
Álljon meg néhány sikertelen jelszókísérlet után. Az ismételt találgatások zárolásokat okoznak, amelyek aztán egy második, független hibának tűnnek, és több időt visznek el az eredeti jegyénél.
Visszaállítás és a megőrzött feljegyzés
Egyszerre egy dolgot változtasson, és az újratesztelés előtt írja le, mit változtatott. Ha egy módosítás rontja a kísérletet, azonnal állítsa vissza, ahelyett hogy még egy javítást halmozna rá. Ismételje meg az eredeti műveletet az eredeti kliensből és környezetből. Egy másik gépről, más címcsaládban végzett sikeres bejelentkezés nem reprodukció, és nem bizonyítja a javítást.
Tisztítsa meg, amit megoszt. A részletes klienskimenet belső neveket, fiókcímkéket, kulcsútvonalakat és nyilvános kulcs-azonosítókat hordozhat, ezért a szakaszos következtetést tegye közzé nyers nyom helyett.