Захавайце лакальны 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.