Я использую переадресацию портов SSH для ретрансляции HTTP-трафика с персональных компьютеров доверенных удаленных клиентов на локальный сервер, работающий на компьютере за прокси моей компании. Этот компьютер за прокси-сервером компании недоступен для удаленных клиентов напрямую.
Вот настройка: я настраиваю виртуальную машину Linux с общедоступным IP-адресом и только один порт, открытый для SSH. В целях безопасности я отключил логин root и логин с паролем. Удаленные клиенты отправляют мне свой открытый ключ SSH, и я добавляю их в файл «authorized_keys» на виртуальной машине Linux.
Теперь я прошу клиента использовать переадресацию локального порта SSH для перенаправления одного из их локальных портов (скажем, 453) на порт на виртуальной машине Linux (скажем, 345). Таким образом, они «выгружают» весь трафик, идущий на их локальный порт 453, на порт 345 виртуальной машины Linux. На ПК компании я использую переадресацию удаленного порта SSH для «загрузки» всего трафика с порта 345 виртуальной машины Linux на порт сервера localhost (скажем, 9999).
Таким образом, я могу безопасно ретранслировать их HTTP-трафик, не предоставляя им доступа к моему корпоративному компьютеру. Я протестировал этот подход, и он отлично работает. Я могу получить HTTP-запрос от моего удаленного клиента, и клиент также получит ответ.
Но я думал о случае нескольких удаленных клиентов с разных компьютеров. У каждого клиента будет туннель SSH к одному и тому же порту виртуальной машины Linux. Каждый из них будет «выгружать» HTTP-трафик со своего локального порта 453 на порт 345 виртуальной машины Linux. Итак, возвращая ответ (с моего локального сервера на ПК компании), гарантируется ли, что ответ на конкретный запрос вернется к правильному клиенту, который отправил запрос?
Я читал кое-что о HTTP здесь. Но я не был уверен, подходит ли это для случая SSH с несколькими туннелями от разных клиентов.
Может ли кто-нибудь прокомментировать, скремблируется ли трафик от разных клиентов так, чтобы ответ, который должен был идти клиенту A, действительно шел клиенту B?
Если да, как мне этого избежать?
1 ответ
Несколько подключений к одному концу туннеля будут генерировать несколько подключений с другого конца туннеля. Эти соединения не смешиваются.
Когда клиент подключается к своему концу туннеля, фиксируются IP-адрес и порт конца, а также IP-адрес браузера. Тем не менее их браузер может (и будет) связываться с разные порты при создании этих подключений. Таким образом, соединения будут отлично отличаться друг от друга. Смотрите этот ответ.
Процесс повторяется на виртуальной машине. Различные подключения (от одного и того же или разных клиентов, не имеет значения) будут нацелены на один и тот же IP-адрес и порт удаленного конца вашего туннеля, исходящие с одного и того же компьютера (указанная виртуальная машина), поэтому, вероятно, с одного и того же IP-адреса. ; но даже в этом случае их можно будет различить, по крайней мере, по портам, к которым они привязаны.
И снова на локальном конце вашего туннеля будут установлены разные соединения с HTTP-сервером с фиксированным IP-адресом и портом, но они будут использовать разные порты на своем «исходном» конце.
Таким образом, один и тот же механизм работает трижды независимо в процессе подключения одного клиента к рассматриваемому HTTP-серверу. Каждый раз, когда соответствующая ОС должна назначать ан неиспользованный порт для процесса, который хочет инициировать соединение. (Инструмент, который инициирует соединения, может запрашивать определенный порт и иногда получать его; но в этом случае нет смысла, и соответствующие инструменты, скорее всего, даже не пытаются, они принимают любой «случайный» порт, который им назначает ОС. )
Нет никакого способа зашифровать трафик от (или к) разных клиентов. Откровенно говоря, это было бы нетривиальной задачей его зашифровать. по запросу, по требованию.
Различение только по номеру порта ограничивает количество подключений, которые могут быть обработаны в любой момент времени. Но даже если предел будет достигнут, новые подключения будут отклонены, а не смешаны с уже существующими. Порты, которые больше не используются, можно использовать повторно, поэтому разорванные соединения освободят место для новых.
Боковое примечание: обычно HTTP-сервер может отклонять URL-адреса, которые он не считает своими собственными. Если это проблема и вы не можете перенастроить HTTP-сервер, тогда любой рассматриваемый клиент должен использовать правильный URL-адрес и убедиться, что трафик в любом случае попадает в конец туннеля на их локальном компьютере.