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 защищает транспорт, но сам по себе не делает две сети равноценными. Решите, соответствует ли доверие к частному транзиту данным, прежде чем на него полагаться.