Які трафік праграм насамрэч перадае SSH-перанакіраванне?

Абалонка, лакальнае перанакіраванне, SOCKS і рэжым тунельнага прыстасавання даюць розныя інтэрфейсы. Назавіце той, які можа выкарыстаць вашая праграма, перш чым параўноўваць яго з маршрутызаваным VPN.

Тэрмінал падключаецца, запыт з’яўляецца, і ўсе згаджаюцца, што доступ па SSH працуе. Потым кліент базы даных на ноўтбуку ўсё яшчэ не можа дасягнуць прыватнага хоста, і вінавацяць сеанс. Пабудавана была абалонка, а гэта адзін з чатырох вельмі розных інтэрфейсаў, якія можа прапанаваць SSH. Спачатку назавіце інтэрфейс, потым праверце, што праграма сапраўды ім карыстаецца. Парадак важны, бо кожны інтэрфейс адмаўляе па-свойму.

Назавіце інтэрфейс, перш чым нешта параўноўваць

Дапаможнік кліента OpenSSH адрознівае чатыры механізмы, якія лёгка зблытаць. Абалонка або аддаленая каманда выконваецца на хосте SSH. Лакальнае перанакіраванне адкрывае слухаючы сокет на кліенце і робіць далейшае злучэнне з аддаленага боку. Аддаленае перанакіраванне робіць наадварот, слухаючы на баку сервера. Дынамічнае перанакіраванне прадастаўляе канцавы пункт SOCKS для праграм, якія ўмеюць ім карыстацца.

  • Абалонка: праграма выконваецца на аддаленай машыне, лакальна нічога не слухае.
  • Лакальнае перанакіраванне: у вашым ноўтбуку ёсць порт, аддалены хост робіць зыходнае злучэнне.
  • Аддаленае перанакіраванне: на аддаленым баку ёсць порт, трафік вяртаецца да вас.
  • Дынамічнае: проксі SOCKS на кліенце, яго выкарыстоўваюць толькі праграмы, якія разумеюць проксі.

Нішто з гэтага не ўсталёўвае маршрут. Праграма, якая ігнаруе налады проксі, або размаўляе па UDP, або сама развязвае імёны, не закранаецца актыўным сеансам SSH. Гэта не памылка SSH; гэта межы абранага вамі інтэрфейсу.

Лакальнае, аддаленае і дынамічнае перанакіраванні розняцца тым, хто слухае

Адрозненне, якое вырашае большасць выпадкаў, — хто валодае слухаючым сокетам. Пры лакальным перанакіраванні слухае кліент, а далёкі бок набірае пункт прызначэння, таму адрас прызначэння развязваецца з пункту гледжання сервера. Пры аддаленым перанакіраванні слухае сервер, а злучэнне пераносіцца назад на ваш бок, і менавіта так вы адкрываеце лакальную службу, не публікуючы яе напрамую.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Першая каманда прывязвае порт 5432 на ноўтбуку і перанакіроўвае яго ў базу даных так, як яна бачная з бастыёна. Другая стварае проксі SOCKS на порце 1080. Трэцяя каманда пацвярджае, якія працэсы сапраўды слухаюць, і гэта адзіны доказ таго, што перанакіраванне існуе, а не моўчкі правалілася з-за канфлікту портаў.

Дынамічнае перанакіраванне заслугоўвае ўласнага папярэджання: яно ахоплівае толькі праграмы, якія паважаюць SOCKS. Браўзер можна накіраваць на яго, інструменту каманднага радка можна сказаць выкарыстоўваць яго, а драйвер базы даных з уласным стэкам злучэнняў звычайна не можа. Меркаванне, што цяпер кожная праграма на машыне выкарыстоўвае тунель, — самая распаўсюджаная памылка ва ўсёй гэтай галіне.

Рэжым тунельнага прыстасавання — адзінае сапраўднае сеткавае выключэнне

OpenSSH таксама падтрымлівае перанакіраванне тунельнага прыстасавання -w, якое перадае двухкропкавы інтэрфейс замест слухача TCP. Гэта сапраўдны сеткавы тунель, і ён наладжваецца свядома, а не як пабочны эфект адкрыцця абалонкі.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Патрэбны адпаведныя нумары інтэрфейсаў на абодвух баках, правільная налада на серверы і дастатковыя правы на кліенце для стварэння прыстасавання. Патрэбны таксама план адрасацыі і маршрутызацыі, бо голы інтэрфейс не нясе палітыкі адносна таго, якія пункты прызначэння павінны яго выкарыстоўваць.

Нават тады тунель сканчаецца на далёкім хосце. Любая ахова, якую даў транспарт SSH, сканчаецца там, а далейшае злучэнне — асобны крок. У шлюза VPN такая ж форма мяжы, таму параўнанне павінна быць пра ахоп і завяршэнне, а не пра тое, які інструмент мацнейшы. Назваць гэтую мяжу ўголас таксама закрывае спрэчку пра тое, ці тунель «шыфруе ўсё», бо ён відавочна не шыфруе.

Праверце, што вашая праграма выкарыстоўвае пабудаваны вамі інтэрфейс

Праверка робіцца для кожнай праграмы, а не для сеансу. Працуючае перанакіраванне даказвае, што порт прывязаны і далёкі бок можа набраць; яно не даказвае, што патрэбная вам праграма падключылася праз яго.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Першая каманда адпраўляе запыт праз канцавы пункт SOCKS з імем хоста, развязаным аддалена, а другая практыкуе перанакіраваны порт базы даных, патрабуючы TLS. Запусціце тыя ж тэсты з спыненым перанакіраваннем, каб пераканацца, што яны правальваюцца, бо тэст, які праходзіць абодвума шляхамі, ніколі не выкарыстоўваў тунель.

Затым параўнайце з маршрутызаваным VPN толькі па важных вымярэннях: якія пункты прызначэння ахоплены, якія пратаколы працуюць, дзе сканчаецца ахова і хто павінен ухваліць доступ. Перанакіраванне адной службы можа быць больш вузкім і лепшым адказам, а VPN — правільнай формай, калі многім праграмам патрэбны адзін і той жа сеткавы шлях. Ні адно не дае ўсяго, што дасягальна з яго далёкага канцавога пункта.

Падобныя артыкулы