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 |
Зупиніться після кількох невдалих спроб пароля. Повторні здогади створюють блокування, які потім виглядають як другий, не пов'язаний збій, і коштують більше часу, ніж початкова заявка.
Відкат і запис, який ви ведете
Змінюйте по одній речі за раз і записуйте, що змінили, перш ніж тестувати знову. Якщо зміна погіршує спробу, негайно відкотіть її, а не нашаровуйте ще одне виправлення. Повторіть початкову операцію з початкового клієнта й контексту. Успішний вхід з іншої машини, в іншій родині адрес, не є відтворенням і не доводить виправлення.
Очистьте те, чим ділитеся. Докладний вивід клієнта може містити внутрішні назви, позначки облікових записів, шляхи до ключів і ідентифікатори відкритих ключів, тому публікуйте поетапний висновок, а не необроблений слід.