Ping работи, но SSH се проваля през VPN: кой етап се счупи?
Един подробен опит разделя достъпността по TCP, транспорта SSH, идентичността на хоста, влизането на потребителя и разрешението за сесията, за да спрете да гадаете за тунела.
Отговорите на Ping и отказаното влизане по SSH могат да бъдат верни едновременно и двойката не обвинява тунела. Отговорите на ехо и TCP връзката към порт 22 са различни тестове с различни селектори, различни политики и често различни дестинации. Уловете един умишлен опит за SSH, после назовете последния етап, който е достигнал. Този единствен артефакт заменя дузина спекулативни промени в конфигурацията.
Уловете един опит, а не сесия от ръчкания
Стартирайте клиента веднъж с подробна диагностика, изключено споделяне на връзката и ограничен таймаут за свързване. Изключването на споделянето е важно, защото предварително удостоверена главна връзка иначе ще отговори за новия опит и ще скрие повредата, която търсите.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Запазете дестинацията, семейството адреси, времевия печат и последната несекретна грешка. Флагът IPv4 също означава, че този опит не казва нищо за път IPv6 към същото име, така че не обобщавайте от него. Запишете откъде е направен опитът. Проверка на VPN шлюза не е същата гледна точка като лаптоп зад него и повечето противоречия в тези заявки идват от смесването на двете.
Етапи едно и две: TCP преди SSH
Първата граница е достъпността на сокета: адрес, порт и маршрут, който пакетът наистина следва. Ако TCP връзката никога не се осъществи, над нея още не съществува нищо и ключовете на хоста и профилите са без значение.
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'Съпоставете записа с опита на клиента. SYN, който излиза и нищо не се връща, сочи към филтриране, селектори или липсващ маршрут от другата страна; отговор с ресет сочи към нещо, което активно отказва вместо да изпуска. Втората граница е самият обмен по протокола SSH. TCP връзка, която се осъществява и после заклинва, е преминала достъпността и е влязла в преговори, отговор на сървъра или обработка на пакети. Това е друго разследване и точно там проблемите, свързани с размера, за пръв път стават вероятни.
Етап три: чий ключ отговори
Щом транспортът е вдигнат, клиентът проверява ключа на хоста на сървъра. Отказът тук е твърдение за идентичност, не за криптография: партньорът е представил ключ, който вашата политика не приема. Третирайте го като условие за спиране и проверете извън канала, чрез конзолата или оператора, който е преустроил хоста. Изтриването на запомнения запис, за да се изчисти предупреждението, е единственият пряк път, който трябва да откажете, защото унищожава доказателството, че нещо е отговорило неочаквано.
Ако хостът наистина е бил преустроен, премахнете стария запис само след като новият отпечатък е потвърден, и отбележете датата и причината. Следващият инженер ще срещне същото предупреждение и се нуждае от този контекст.
Етапи четири и пет: профил срещу разрешение
Удостоверяването е четвъртата граница. Отхвърлените идентификационни данни означават, че сървърът е оценил опита и го е отказал; проверете профила, типа идентификационни данни, който сървърът приема, и собствената политика на сървъра, а не паролата за VPN. Петата граница е оторизацията след успешно влизане. Удостоверен потребител все още може да бъде лишен от шел, команда, подсистема или препращане и тези откази изглеждат като повреди за човек, който чете само последния ред на клиента.
| 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 |
Спрете след няколко неуспешни опита за парола. Повтарящите се догадки създават блокировки, които после изглеждат като втора, несвързана повреда, и струват повече време от първоначалната заявка.
Връщане назад и записът, който пазите
Променяйте по едно нещо наведнъж и записвайте какво сте променили, преди да тествате отново. Ако промяна влоши опита, върнете я веднага, вместо да натрупвате още една поправка. Повторете оригиналната операция от оригиналния клиент и контекст. Успешно влизане от друга машина, в друго семейство адреси, не е възпроизвеждане и не доказва поправката.
Изчистете това, което споделяте. Подробният изход от клиента може да носи вътрешни имена, етикети на профили, пътища до ключове и идентификатори на публични ключове, затова публикувайте поетапното заключение, а не сурова следа.