Задржете го локалниот 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 адреса.