Кой трафик на приложения всъщност пренася 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 е правилната форма, когато много приложения се нуждаят от същия мрежов път. Никое от двете не дава всичко, достъпно от неговата далечна крайна точка.

Подобни статии