Сохраняйте локальный SSH, когда хост использует исходящий VPN

Небольшой сервер Linux использует исходящий VPN для размещённого приложения, а администратор по-прежнему хочет попадать на него по SSH с соседнего стола. Это разумное требование, и обычно оно не требует ни проброса портов, ни адреса провайдера, ни дыры в туннеле. Нужен ему путь управления, спроектированный намеренно, а не унаследованный от того, что клиент VPN сделал с таблицей маршрутизации.

Шаги ниже предполагают, что администратор находится в той же сети LAN.Удалённое администрирование — другая задача с другим ответом.

Привяжите SSH к адресу, которым пользуются администраторы

Начните с прослушивателя.ss -ltnp | grep :22 показывает, к чему привязан sshd, а прослушиватель на 0.0.0.0 принимает подключения с каждого интерфейса, включая туннель. Привязка к адресу LAN уже и делает намерение видимым:ListenAddress 192.168.10.20 в sshd_config, затем проверка конфигурации и перезагрузка. Опечатка в этом адресе заметнее шаблона, потому что sshd отказывается запускаться, когда адреса не существует.

Оставьте проверку ключа хоста и аутентификацию каждого пользователя точно такими, какие они есть. «Это же просто локальная сеть» — не метод аутентификации, а канал управления, который пропускает проверку ключа из-за короткого маршрута, это канал управления, ждущий злоупотребления. Резервирование DHCP или статический адрес делают цель предсказуемой, не превращая её в публичную идентичность сервера.

Держите маршрут LAN вне туннеля

У хоста с адресом в 192.168.10.0/24 есть подключённый маршрут для этого префикса, а более конкретный маршрут побеждает маршрут по умолчанию VPN в той же таблице. Поэтому локальный SSH часто продолжает работать сам по себе, когда туннель поднимается. Проверьте это, а не предполагайте:ip route get 192.168.10.50 называет интерфейс и адрес источника, которые использовало бы ядро, и ответом должно быть устройство LAN, а не туннель. Повторите проверку и с машины администратора, ведь именно её собственная таблица решает, дойдут ли пакеты вообще. Два хоста на одном проводе могут расходиться во мнениях о том, какое направление доступно.

Допущение ломается в двух местах. Правило маршрутизации на основе политики может отправить трафик в таблицу, маршрут по умолчанию которой указывает в туннель, прежде чем будет просмотрена основная таблица. Клиент VPN с функцией блокировки или kill switch тоже может блокировать трафик, не входящий в туннель, независимо от того, что говорит таблица маршрутизации.

Маршрутизируемые VLAN управления — это другой случай. Если администратор сидит в 192.168.50.0/24 за локальным маршрутизатором, серверу нужен явный маршрут для этого префикса через 192.168.10.1, и этот маршрут должен переживать переподключение. Держите исключение конкретным для префикса управления; широкое исключение для частных диапазонов сводит на нет смысл туннеля.

Сделайте исключение в межсетевом экране таким же узким, как правило

Если на хосте работает межсетевой экран, разрешайте SSH только из источника управления и только на интерфейсе LAN. Правило, разрешающее порт 22 отовсюду, шире требования и его труднее обосновать на проверке. На хосте с nftables правило относится к входной цепочке с совпадением интерфейса и источника; на хосте с iptables эквивалент — пара совпадений по -i и -s. Прокомментируйте правило группой администраторов, которой оно служит, чтобы следующему аудиту не пришлось гадать, почему порт 22 открыт.

Проверьте и собственный фильтр клиента VPN. Некоторые клиенты устанавливают правила, которые по замыслу отбрасывают локальный трафик, а правильное правило межсетевого экрана поверх отбрасывания на уровне клиента ничего не меняет. Прочитайте конфигурацию клиента, прежде чем править межсетевой экран хоста, потому что два фильтра подряд дают сбой, не похожий ни на один из них.

Проверьте оба состояния

Запустите тест дважды: один раз с подключённым туннелем и один раз с отключённым. В каждом состоянии подтвердите прослушиватель, маршрут и реальный вход по SSH с машины администратора. Путь, который работает только пока туннель поднят, не является локальным путём управления; это совпадение.

Затем перезапустите туннель, пока сеанс SSH открыт. Сеанс, который выжил, доказывает, что маршрутизация стабильна; сеанс, который оборвался, говорит вам, что клиент при переподключении переписывает маршруты или фильтры, и это стоит знать до инцидента, а не во время него.

Запишите адрес источника, с которого вы тестировали, потому что правило, написанное для 192.168.10.50, тихо отказывает, когда ноутбук администратора переезжает в другую подсеть.

Запишите путь восстановления в runbook

Решите сейчас, что произойдёт, если исходящий VPN сломает локальный путь. Доступ через консоль, второй адрес управления или документированная процедура остановки клиента — всё это законные ответы, и любой из них лучше, чем обнаружить проблему в тот момент, когда нужно войти. Если сервер удалённый, локального пути не существует, и правильный проект — отдельный одобренный путь удалённого доступа или бастион, а не выставленный публичный порт.

Держите две роли раздельно в документации: локальный SSH для администратора, который находится рядом, и исходящий туннель для трафика приложения. Когда эти роли записаны, у будущего изменения любой из них есть очевидное место для проверки, и следующему человеку не нужно заново открывать, почему сервер с VPN всё ещё отвечает на своём адресе LAN.