SSH на другому приватному шляху, поки VPN залишається активним

Одна машина дістається іншої через VPN, і тепер комусь потрібна та сама оболонка в приватній мережі провайдера. Маршрут існує, ping проходить, а SSH усе одно відмовляє. Звичайна причина — демон ніколи не слухав на новій адресі, тож підключатися ні до чого. Це проблема прив’язки адреси, а не одразу проблема міжмережевого екрана.

Чому новий маршрут не створює нового слухача

Слухаючий сокет створює процес, який називає адреси, на яких прийматиме з’єднання. Маршрут лише повідомляє пакетам, куди рухатися; він не створює слухача в пункті призначення. Коли sshd налаштований з одним ListenAddress, з’єднання на будь-яку іншу локальну адресу відхиляються, хоча інтерфейс піднятий. Те саме стосується сокет-юніта, якому належить порт, тому перша перевірка завжди — що саме слухає.

Порівнюйте два шляхи за адресою призначення, а не за назвою інтерфейсу. Клієнт підключається до адреси, і ця адреса має бути прив’язана до того, як будь-яке правило міжмережевого екрана стане важливим.

Перелічіть адреси та слухачі

Перш ніж щось змінювати, запишіть адреси на хості та сокети, які існують зараз.

ip -br addr
ss -ltnp | grep ':22'

Список адрес показує, яка приватна адреса справжня і на якому інтерфейсі, а список сокетів — чи щось прив’язано до неї. Слухач на 0.0.0.0:22 уже приймає кожну адресу, тож нова прив’язка нічого не додає. Слухач на одній конкретній адресі одразу пояснює відмову. Якщо порт належить сокет-юніту, а не демону, конфігурація демона — не вся історія.

Додайте прив’язку та збережіть стару

OpenSSH приймає кілька записів ListenAddress, тому шлях VPN може залишатися, поки додається приватний. Перевірте файл перед перезавантаженням.

sshd -t
systemctl reload sshd

Невдала перевірка конфігурації залишає працюючий демон недоторканим, і це саме те, що потрібно, поки ви підключені шляхом, який редагуєте. Збережіть наявний запис, додайте нову локальну адресу й переконайтеся, що служба перезавантажується, не розриваючи поточний сеанс. В інсталяціях із активацією через сокет додайте адресу до сокет-юніта й перезавантажте цей юніт. Потім знову прочитайте список слухачів, бо прив’язка, яка так і не з’явилася, означає, що змінено не той компонент.

Перевірте новий сеанс, перш ніж закривати старий

Підключіться до нової адреси, поки вихідний сеанс ще відкритий, і скористайтеся докладним виводом, щоб побачити, які адреса та ключ використовувалися. Тримайте вихідний сеанс відкритим, доки перевірка не завершиться успішно двічі.

ssh -v [email protected]

Прочитайте рядки налагодження про адресу призначення та наданий ключ хоста. Звірте відбиток ключа хоста зі значенням, якому ви вже довіряєте, замість того щоб приймати невідомий ключ лише тому, що мережу названо приватною. Новому призначенню потрібен власний запис known_hosts, і це очікувано. Старий сеанс керування слід закривати лише після того, як приватний шлях запрацює.

SSH захищає транспорт, але сам по собі не робить дві мережі рівноцінними. Вирішіть, чи відповідає довіра до приватного транзиту даним, перш ніж покладатися на неї.