Који саобраћај апликација заиста носи 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 прави облик када многим апликацијама треба исти мрежни пут. Ниједно не даје све што је достижно са његовог удаљеног краја.

Повезани чланци