Допустим, вы находитесь на компьютере A и подключаетесь к компьютеру B, поэтому A инициирует подключение к B .. Скажем, это веб, так что HTTP соединение. Там нет прокси и нет шифрования. Нет SSH, не используется команда SSH. Вы могли бы запустить это соединение через SSH, что включало бы туннелирование и переадресацию портов и, конечно, также получило бы преимущество шифрования, но туннелирование, которое, кстати, всегда использует переадресацию портов, не является самым простым использованием SSH.
У вас может быть SSH без какого-либо "туннелирования", поэтому без инкапсуляции протокола внутри него, например, скажем, вы находитесь на компьютере A и хотите получить доступ к командной строке на компьютере B. Протокол SSH может это сделать. И на самом деле я видел ssh -X, позволяющий просматривать графический интерфейс на компьютере B, где компьютер B работал под управлением Linux. Так что SSH может делать совсем немного, даже без туннелирования. И вы получаете шифрование SSH всякий раз, когда используете SSH.
Что вы также можете сделать, скажем, вы хотите просматривать веб-страницы из интернет-кафе. Вы можете установить SSH-соединение с компьютера A на компьютер B, установив соединение, которое является SSH-туннелем, оно будет инкапсулировать другой протокол, например запросы к HTTP-прокси, а на компьютере B будет работать веб-прокси, извлекать веб-страницу и отправить ее на компьютер А. Все, что видит человек в интернет-кафе, это зашифрованное ssh-соединение между A и B. Динамическая переадресация порта создаст прокси-сервер SOCKS на B, а прокси-сервер SOCKS может выступать в качестве веб-прокси.
Вы можете использовать VNC для перехода от A к B, но сделать это через соединение SSH ... так что это туннелирование / инкапсуляция соединения VNC через соединение SSH.
В SSH существует концепция переадресации локальных портов и переадресации удаленных портов (обратный туннель). То, какая сторона слушает, а какая вперед. Местный типичный. Например. Ситуация с ssh-туннелированием включает в себя следующие элементы: ssh.exe (инициирует ssh-соединение, это ssh-клиент). sshd.exe (ssh-сервер прослушивает ssh.exe для подключения к нему). И клиент и сервер инкапсулированного протокола. например, клиент VNC и сервер VNC. И у вас есть компьютеры, на которых работает каждый из них.
Скажите, что ваши компьютеры A, B, C, D
A-запускает VNC-клиент B, запускает SSH-клиент C, запускает SSH-сервер D, запускает VNC-сервер
B соединяется с C.
A соединяется с B, затем C передает его на D.
Все между B и C зашифровано.
Все, что находится между A и B или C и D, не зашифровано.
Туннель SSH находится между B и C.
Между A и B и между C и D находится инкапсулированный протокол - в данном случае VNC.
Теперь я пойду к тому, что такое обратный туннель, и это полезно ..
Предположим, что A находится за маршрутизатором NAT, а B - за маршрутизатором NAT. Если A хочет подключиться к VNC на B, то B должен выполнить переадресацию портов на своем маршрутизаторе. (это даже без SSH).
Другой способ, хотя, был бы, если бы B мог инициировать соединение с A, позволяя A просматривать B. Таким образом, вы отправляете техническому специалисту joe bloggs исполняемый файл, а затем запускаете его и просматриваете их компьютер. PChelpWare делает это, позволяя вам создать такой исполняемый файл. Но процесс B может соединиться с вами, может быть выполнен с помощью SSH.
Например, в сценарии локального туннеля ssh у вас может быть CompA, запускается VNC-клиент и SSH-клиент CompB, запускается VNC-сервер и SSH-сервер.
Таким образом, туннель и соединение VNC идут в одном направлении.
A подключает свой SSH-клиент (ssh.exe) к SSH-серверу B (sshd.exe). (требует, чтобы B сделал переадресацию портов на своем маршрутизаторе). ssh.exe на A затем создает порт на A - комп, на котором он работает, который прослушивает соединение VNC. Это слушающая сторона туннеля. А также, когда был построен туннель, было определено, что B должен пересылать на любой IP:PORT, B в этом случае. Вот где находится сервер VNC.
CompA/PersonA, соединяет VNC-клиент с портом, который ssh.exe открыл на A. И затем он будет перенаправлен на B.
Но вот проблема с этим, с локальным туннелем ssh. Предположим, Б не знает, как сделать переадресацию портов на своем маршрутизаторе.
Тогда A не может подключить свой SSH.EXE, свой ssh-клиент, к B SSHD.EXE, ssh-серверу B.
Ну, они могли бы сделать обратный туннель SSH
A запускает SSH SERVER, а клиент VNC B запускает SSH CLIENT и VNC Server.
B подключается к A .. командой, которая инструктирует создание обратного туннеля. Таким образом, прослушивание не локально по отношению к тому, где был запущен SSH.EXE (то есть B), но порт прослушивания открыт на A, даже если B запускает ssh.exe, поэтому B подключается к A и устанавливает SSH-соединение. А теперь слушает инкапсулированный протокол.
Затем A подключает своего клиента VNC к порту, который открыт на A, и просматривает B.
B не должен был делать переадресацию портов на своем маршрутизаторе. Поскольку все, что B должен был сделать, было установить соединение .. Не было входящего соединения с Б. Это то, что может сделать туннель SSH.
(обратите внимание, что в настоящее время, когда A хочет просмотреть B, они обычно используют решение, такое как teamviewer, которое, вероятно, включает как установление исходящего соединения)
Но в любом случае это использование обратного туннеля SSH.
Так что использовать ли локальный туннель SSH или обратный, зависит от того, какая сторона блокирует входящие. или какая сторона находится позади устройства, блокирующего вход, которым вы не можете управлять. например, маршрутизатор NAT или межсетевой экран, который вы не можете контролировать.
Динамический туннель, где A подключается к B через SSH, а прокси SOCKS создается в B. Прокси SOCKS подобен универсальному прокси, который может имитировать группу прокси различного типа. Так что он может выступать в качестве веб-прокси. Так что, если вы были в интернет-кафе .. Вы можете использовать динамический туннель. Подключитесь к CompB, и это все, что видит человек, управляющий интернет-кафе. Дело в том, что веб-прокси не перенаправляет на один компьютер, в противном случае вы получите только один веб-сайт. Он пересылается на любой веб-сервер, который вы запрашиваете, позволяя вам просматривать веб-страницы.
Чтобы выполнить SSH с переадресацией локального порта, то есть для локального туннеля ssh выполните SSH -L PORT:IP:PORT user@sshserver -p 22
где PORT:IP:PORT первый "порт" - это порт, который будет выполнять ssh.exe. создать локально для вашего клиента VNC, например, для подключения. и IP:PORT - это IP:PORT, например, VNC-сервера. тогда у вас есть sshserver -p 22 sshserver - это IP-адрес сервера ssh, к которому вы подключаетесь, а -p 22 означает подключение к нему через порт 22. Вы можете вместо PORT:IP:PORT, скажем, IP:PORT:IP:PORT, где первый IP-адрес 0.0.0.0 или *, означает, что любой компьютер может подключиться.
SSH, но с обратным туннелем ssh, переадресация портов локально. Таким образом, вы делаете SSH -R PORT:IP:PORT, где первый PORT - это порт на конце sshd.exe, который прослушивает. И IP:PORT - это IP:PORT, например, VNC-сервера, но это CompA, то есть комп, на котором запущен ssh.exe. И это также SSH -R PORT:IP:PORT user@sshserver -p 22
Динамический SSH будет иметь вид ssh -D 8080 <username>@192.168.1.1
Есть случай, когда кто-то делает обратную версию ... обратный SSH -D. https://stackoverflow.com/questions/842021/ssh-d-port-usernameserver-com-but-in-reverse Он запустил SSH-сервер и хотел, чтобы его друг имел доступ к своему SSH-прокси. Так что его друг запускал ssh -D username@server.com Но он не хотел, чтобы у его друга тоже была консоль SSH. Нет сомнений, что есть лучший способ предотвратить это, но то, что он сделал .. или попросил сделать ... Был ли Он устанавливает соединение SSH со своим другом, но затем пусть его друг получает доступ к своему прокси-серверу SSH SOCKS. Таким образом, у его друга есть прокси для доступа к его SOCKS прокси! Таким образом, он (человек А-человек, настраивающий свой компьютер, чтобы его друг мог получить доступ к своему прокси-серверу (А)), ssh -R 24680:localhost:12345 remotehost
А затем выполните команду ssh -D 12345 localhost
Это ssh -R означает первый указанный порт (24680) откроется на CompB. И все, что получено на этом (где B подключает свой веб-браузер), будет отправлено на A и перенаправлено на порт 12345, где A запускает свой SOCKS-прокси. И самое забавное в том, как настроен прокси-сервер SOCKS, как прокси-серверы SOCKS с SSH, так как для этого требуется собственное ssh-соединение. Это не туннелирование SSH через SSH .. Запросы SOCKS транслируются через SSH. Но соединение ssh, которое делает прокси-сервер SOCKS, является отдельным соединением, которое поступает от А, подключающегося к его собственному серверу ssh через порт 22. (в дополнение к соединению SSH, которое А подключается к В). Последний пример, обратный ssh -D - очень сложное использование SSH! Другие применения (локальное, обратное и нормальное -D) все еще сложны, но не так сложны, как пример обратного -D. Я просто добавил это для большей полноты.