2

Я должен провести семинар в огненной среде, которая мешает мне показать все, что я хотел бы, и я ищу обходной путь.

Я буду демонстрировать программное обеспечение, которое работает на Windows. Ожидается, что во время семинара участники подключатся к этому программному обеспечению со своих телефонов с помощью браузера.

    Windows                        Phone           
+-------------------+          +------------------+
|                   |          |                  |
|  Demo software    |          |                  |
|                   |          |                  |
|                   |          |                  |
|             :8080 | <--------+  Browser         |
|                   |          |                  |
|                   |          |                  |
+-------------------+          +------------------+

Проблема в том, что все машины мастерской защищены огнем, и невозможно (из-за жесткости организации, где я работаю в мастерской) открыть отверстие в брандмауэре.

Поэтому я думал запустить какой-нибудь прокси (к счастью, это разрешено) на каждой машине мастерской. Этот прокси-сервер будет подключаться к какому-то внешнему серверу, регистрироваться с каким-то автоматически сгенерированным идентификатором и начинать ждать данных.

Затем телефон подключится к http://server.xxx/proxyid и сервер направит свой запрос соответствующему прокси-серверу на основе идентификатора прокси-сервера (через уже установленное соединение, чтобы данные могли проходить через брандмауэр). Затем прокси связывается с веб-сервером в демо-версии программного обеспечения, получает ответ и передает его обратно на сервер, который пересылает ответ на телефон.

                       Firewall                                       
                           +                                          
                           |                                          
   Windows                 |                                          
+---------------------+    |                                          
|                     |    |                                          
|   +-------------+   |    |        server.xxx                        
|   | Demo SW     |   |    |     +------------------------+           
|   |             |   |    |     |                        |           
|   |       :8080 |   |    |     |                        |           
|   +--------+----+   |    |     |                        |           
|            ^        |    |     |                        |           
|            |        |    |     |                        |           
|   +--------+----+   |    |     |                        |           
|   | Proxy       |   |    |     |                        |           
|   |             +------------> |:80                     |           
|   |         ID  |   |    |     |                        |           
|   +-------------+   |    |     +------------------------+           
|                     |    |                      ^                   
+---------------------+    |                      |                   
                           |                      |                   
                           |                      |                   
                           +                      |                   
                                    Phone         |                   
                                 +-----------------------------------+
                                 |    Browser     |                  |
                                 | +--------------+----------------+ |
                                 | | http:://server.xxx/ID         | |
                                 | |                               | |
                                 | +-------------------------------+ |
                                 +-----------------------------------+

Существуют ли какие-либо строительные блоки, которые позволили бы мне соединить этот обходной путь, чтобы мне не пришлось его программировать? Желательно, чтобы серверная часть тоже работала в Windows (какой-то тип Linux тоже подойдет).

2 ответа2

2

Это не совсем то, что вам нужно, и, может быть, я подумаю о чем-то еще, но это то, что вы должны знать.

Переадресация порта SSH

Вам нужно получить SSH-сервер, работающий на компьютере B. Так что вы можете сделать это из комп А

SSH похож на telnet, но с большей безопасностью и функциями перенаправления портов TCP.Вы можете игнорировать аспект Telnet этого

ssh - это инструмент, с которым знакомы системные администраторы, но также и технические специалисты.

Вы можете установить SSH через Cygwin в Windows.

A$ssh user@compB

скажем, вы можете сделать это.

А находится за брандмауэром. В порядке.

----------- Б

Хотя за брандмауэром можно установить исходящее соединение

запустить это из А

A$ssh -R 1234:127.0.0.1:5678 -R 2345:127.0.0.1:5642 user@compB

это можно сделать одной командой или разбить на две отдельные команды A$ssh -R 1234:127.0.0.1:5678 user@compB

а также

A$ssh -R 2345:127.0.0.1:5642 user@compB

-R 1234:127.0.0.1:5678

-R означает открытый порт в comp назначения (compB), и к CompB можно подключиться через порт 5678, он перейдет в CompA и будет перенаправлен на порт 1234 (все еще в CompA).

Так что вы можете сделать

-R 80:127.0.0.1:8080

Дело в том, что вы хотите что-то с удостоверением личности, и я не уверен в этом

Хотя я могу сказать, что вы можете открыть несколько портов на CompB

так что не просто порт 80

порт 81, порт 82

и поэтому порт 81 на CompB может пересылать на порт 1234 на CompA

порт 82 на CompB мог перенаправить на порт 4252 на CompA

так далее

И вы можете сказать -gR или -R *:80 ...., поскольку без -g порт, который открывается на CompB, будет разрешать соединение только с CompB, т.е. он будет слушать только 127.0.0.1, поэтому используйте - g в вашем случае, потому что вы хотите, чтобы клиент с другого компьютера [«телефонный» компьютер] подключался к CompB .. т. е. -g is, потому что вы хотите, чтобы клиентская программа с другого компьютера подключалась к CompB(и была перенаправлена на CompA), а не клиентская программа на CompB для подключения к CompB(и перенаправления в CompA).

Одна точка, хотя .. Вы подключаете ssh.exe от компа за брандмауэром (CompA) к compB.

На CompB открывается порт ... для нового тайм-соединения, через которое необходимо провести контрабанду. Ваш http или любой другой клиент подключается к CompB, затем он достигает CompA, с которого вы запустили ssh.exe. Затем вы можете переслать любой понравившийся вам комп.

Когда вы пишете -R 1234:127.0.0.1:5678 Этот 127.0.0.1 может быть изменен на другой компьютер. Так что запрос клиента будет перенаправлен на другой компьютер

-R противоположна -L, хотя вам не нужен -L.

SSH -D

Дело в том, что ... судя по всему, вашим конечным пунктом назначения является веб-сервер.

Поскольку вы ожидаете пересылки только на один конкретный сайт, вы можете использовать -R

Но есть также опция -D, о которой вы должны знать, что делает SOCKS прокси, который может обрабатывать HTTP

Небольшое препятствие это -D локально .. т.е. это немного похоже на -L в этом смысле.

Но что вы можете сделать, это сделать SOCKS Proxy на CompA,

А из A сделать ssh -R в compB. Таким образом, любой, кто подключается к B, перенаправляется на SOCKS-прокси на A, а затем может получить доступ к любому веб-серверу, который он хочет.

ответ по этой ссылке пытается использовать SSH Reverse socks tunnel, но (по состоянию на момент написания) помещает прокси socks на неверный компьютер. Этот ответ делает это правильно.
https://stackoverflow.com/questions/842021/ssh-d-port-usernameserver-com-but-in-reverse

Но тогда вы не получаете разные веб-серверы для разных людей.

Для этого придерживайтесь -R

Комбинация -R с -D может быть ненужной в вашем случае, если вы действительно не хотите получать доступ к другим веб-сайтам, в этом случае вам нужны прокси-сервер SOCKS (-D) и -R

И в любом случае, ничего из этого не связано с идентификатором ..., но с другими портами, порт которых определяет, какой IP:PORT будет переадресован, когда он достигнет компа, находящегося за брандмауэром [comp], с которого вы запустили ssh.exe.

0

Для решения этой проблемы мы всегда будем использовать способ удаленного рабочего стола Microsoft для демонстрации. Демонстрационная среда работает на компьютере в вашем офисе, который подключен к Интернету, и все необходимые порты открыты. Это означает, что люди могут использовать свой веб-браузер на любом устройстве, чтобы подключиться к веб-интерфейсу вашего сервера.

Чтобы показать демонстрацию, вы можете использовать RDP-клиент (у каждой ОС есть хотя бы один) для подключения и входа в систему на вашем демонстрационном ПК / сервере и просмотра окон Windows вашего сервера.

Обычно им даже не нужно открывать порт на своем брандмауэре, если у них нет строгих правил (только несколько открытых портов для исходящего трафика, таких как порты 80 и 443). Но RDP (3389) обычно является одним из немногих портов, которые уже открыты.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .