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