Запазете локалния 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 хост правилото принадлежи в input веригата със съвпадение по интерфейс и източник; на iptables хост еквивалентът е двойка съвпадения по -i и -s. Коментирайте правилото с администраторската група, на която служи, за да не се налага следващият одит да гадае защо порт 22 е отворен.

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

Тествайте двете състояния

Изпълнете теста два пъти: веднъж със свързан тунел и веднъж с изключен. Във всяко състояние потвърдете слушателя, маршрута и действителен SSH вход от машината на администратора. Път, който работи само докато тунелът е вдигнат, не е локален път за управление; това е съвпадение.

След това рестартирайте тунела, докато SSH сесия е отворена. Сесия, която оцелее, доказва, че маршрутизацията е стабилна; сесия, която падне, ви казва, че клиентът пренаписва маршрути или филтри при повторно свързване, което си струва да се знае преди инцидент, а не по време на такъв.

Запишете изходния адрес, от който сте тествали, защото правило, написано за 192.168.10.50, се проваля тихо, когато лаптопът на администратора се премести в друга подмрежа.

Запишете пътя за възстановяване в runbook

Решете сега какво се случва, ако изходящият VPN счупи локалния път. Достъп през конзола, втори адрес за управление или документирана процедура за спиране на клиента са все законни отговори и всеки от тях е по-добър от това да откриете проблема в момента, в който трябва да влезете. Ако сървърът е отдалечен, локалният път не съществува и правилният дизайн е отделен одобрен маршрут за отдалечен достъп или бастион, а не отворен публичен порт.

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