TL; DR
Remote (т.е. программное обеспечение localtunnel на вашем компьютере) инициализирует соединение с ретранслятором (то есть localtunnel.me) действует как мультиплексный прокси-сервер, и когда клиенты (например, веб-браузеры) подключаются,Реле мультиплексирует соединения между удаленными компьютерами и клиентами, добавляя специальные заголовки с информацией о сети.
Browser <--\ /--> Device
Browser <---- M-PROXY Service ----> Device
Browser <--/ \--> Device
Как работают localtunnel, ngrok и Telebit
Я автор Telebit, который предоставляет сервис с аналогичными функциями, которые предоставляют ngrok, localtunnel и libp2p (а также с открытым исходным кодом для удаленного / клиента и ретранслятора / сервера для его запуска самостоятельно).
Хотя яне знаю точные внутренности того, как реализован localtunnel, я могу дать вам объяснение того, как это обычно сделано (и как мы делаем это),и это, скорее всего, почти идентично тому, как они это делают.
Если вы предпочитаете видео preso, я просто выступил по этому вопросу на конференции UtahJS Conf 2018, в которой я говорю всеЭто касается и всех других потенциальных решений: прокси-серверов SSH Socksv5 (которые вы упомянули), VPN, UPnP, DHT, реле и т. д .:
Способность доступа: доступ к вашим устройствам, доступ к немуваш материал
Слайды: http://telebit.cloud/utahjs2018
Волшебство, которое вас интересует, происходит в двух местах: удаленный разъем и мультиплексор.
Как удаленный клиент получает доступ к серверу на моем локальном хосте?
1.Дистанционная розетка
Это довольно просто.Когда вы запускаете «удаленный» (telebit, ngrok и localtunnel все работают почти одинаково в этом отношении), на самом деле это ваш компьютер, который инициирует запрос.
Итак, представьте, что реле(прокси localtunnel в вашем случае) использует порт 7777 для приема трафика от «удаленных» (таких как ваш компьютер), а ваш номер socket (случайно выбранный адрес источника на вашем компьютере) равен 1234:
Devices: [Your Computer] (tcp 1234:7777) [Proxy Server]
Software: [Remote] -----------------------> [Relay]
(auth & request 5678)
Однако клиенты (такие как браузеры, netcat или другие пользовательские агенты), которые к вам подключаются, на самом деле также инициируют запросы с помощью ретранслятора.
Devices: [Proxy Service] (tcp 5678) [Client Computer]
Software: [Relay] <------------------------ [netcat]
Если вы используете порты tcp, то служба ретрансляции сохраняет внутреннее сопоставление, очень похожее на NAT
Internal Relay "Routing Table"
Rule:
Socket remote[src:1234] --- Captures ------> ALL_INCOMING[dst:5678]
Condition:
Incoming client[dst:5678] --- MATCHES -------> ALL_INCOMING[dst:5678]
Therefore:
Incoming client[dst:5678] --- Forwards To ---> remote[src:1234]
Оба соединения являются «входящими», но удаленным соединением на «южном конце»авторизован для получения трафика, поступающего из другого входящего источника (без какой-либо авторизованной сессии кто-либо может требовать использования этого порта или адреса и перехватывать ваш трафик).
[Client Computer] (tcp 5678) [Proxy Service] (tcp 1234) [Your Computer]
[netcat] --------------> <--[Relay]--> <------------ [remote]
2.Мультиплексор
Возможно, вы заметили, что в приведенном выше описании есть критический недостаток.Если вы просто направите трафик как есть, ваш компьютер (удаленный) сможет обрабатывать только одно соединение за раз .Если другой клиент (браузер, netcat и т. Д.) Подключился к соединению, ваш компьютер не сможет определить, откуда поступили пакеты.
Browser <--\ /--> Device
Browser <---- M-PROXY Service ----> Device
Browser <--/ \--> Device
По существу, какой ретранслятор (то есть локальный туннельный прокси) иудаленный (т. е. ваш компьютер) делает, помещает заголовок перед всеми данными, которые должны быть получены клиентом.Он должен быть чем-то очень похожим на протокол PROXY протокола HAProxy, но работает и для нелокального трафика.Это может выглядеть так:
<src-address>,<src-port>,<sni>,<dst-port>,<protocol-guess>,<datalen>
Например,
172.2.3.4,1234,example.com,443,https,1024
Эта информация может быть отправлена точно перед или добавлена к каждому пакету данных, который маршрутизируется.
Аналогично,когда пульт отвечает на ретранслятор, он должен включить эту информацию, чтобы ретранслятор знал, на какого клиента отвечает пакет данных.
Подробные сведения см. https://www.npmjs.com/package/proxy-packer
Sidenote / Rant: Порты против TLS SNI
Первоначальное объяснение, которое я дал, используя порты tcp, потому что это легко понять.Однако localtunnel, ngrok и telebit имеют возможность использовать tls индикатор имени сервера (SNI) вместо того, чтобы полагаться на номера портов.
[Client Computer] (https 443) [Proxy Service] (wss 443) [Your Computer]
[netcat+openssl] --------------------> <--[Relay]--> <------------ [remote]
(or web browser) (sni:xyz.somerelay.com) (sni:somerelay.com)
MITM против p2p
Есть еще несколько разных способов сделать это (и именно здесь я хочу дать бесстыдный плагин для телебита, потому что, если вы находитесь в децентрализации и одноранговой сети, это то, где мы сияем!)
Если вы используете только tls sni для маршрутизации (то есть как localtunnel и ngrok работают по умолчанию по умолчанию в прошлый раз, когда я проверял), весь трафик дешифруется на ретрансляторе .
Другой путь требует интеграции ACME / Let's Encrypt (т.е. Greenlock.js ), чтобы трафик оставался зашифрованным, сквозной , маршрутизируяTLS трафик клиенту, не расшифровывая его.Этот метод функционирует как одноранговый канал для всех практических целей (ретранслятор действует как еще один непрозрачный «коммутатор» в сети Интернет, не подозревая о содержимом трафика).
Кроме того, если https используется как для удаленных (например, через Secure WebSockets), так и для клиентов, то клиенты выглядят так же, как любой другой тип запроса https, и не будетпрепятствует плохо настроенным брандмауэрам или другим суровым / неблагоприятным условиям сети.
Теперь решения, основанные на libp2p также , предоставляют виртуализированное одноранговое соединение, но оно гораздо более косвенное и требует маршрутизации.через ненадежных сторон.Я не фанат этого, потому что это обычно медленнее, и я считаю это более рискованным.Я убежден, что сетевая федерация победит анонимность (например, libp2p) в долгосрочной перспективе.(для нашего варианта использования нам нужно было что-то, что могло бы быть объединено - выполнялось независимо доверенными сторонами - вот почему мы построили наше решение так, как мы это сделали)