Зберігайте локальний 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.