tunnel
1.0.0
Безопасный мультиплексированный переадресатор портов TCP/UDP с использованием конвейерного сервера @nwtgck в качестве ретранслятора. Разработан в основном для p2p-соединений между узлами за (несколькими) NAT/брандмауэрами.
Особый случай IPFS см. в #examples ниже.
Идентификатор: каждому узлу присваивается уникальный идентификатор (base64).
tunnel -iИдентификатор привязан к оборудованию (MAC-адресу) и переменным среды USER, HOME и HOSTNAME. Поделитесь этим со своими сверстниками раз и навсегда. Примечание. Двум пользователям на одном компьютере присваиваются отдельные идентификаторы узлов, поскольку их переменные USER и HOME различаются.
Режим сервера: откройте доступ к своему локальному порту узлам, с которыми вы делитесь какой-либо секретной строкой.
tunnel [options] [-u] [-k < shared-secret > ] < local-port >Режим клиента: перенаправьте ваш локальный порт на открытый локальный порт узла -
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > Если с помощью опции -b не указан локальный порт, tunnel использует случайный неиспользуемый порт. Используемый порт всегда указывается в стандартном выводе.
Опция -I удобна, когда клиент работает на ноутбуке, который время от времени подключается к локальной сети, в которой находится сервер. Когда сервер можно найти в локальной сети с частным IP = <IP> , tunnel подключается через локальную сеть.
Клиент и сервер должны использовать один и тот же секрет, чтобы иметь возможность соединяться друг с другом. Секретную строку также можно передать с помощью переменной среды TUNNEL_KEY . Секрет, переданный с -k имеет приоритет.
Флаг -u означает использование UDP вместо TCP по умолчанию. Если он используется, он должен использоваться обоими узлами.
По умолчанию все журналы находятся на stderr. Однако с опцией -l <logfile> можно запустить tunnel в фоновом режиме ( режим демона ) с сохранением журналов в <logfile> . Идентификатор процесса демона отображается пользователю во время запуска, чтобы он мог в любое время уничтожить демон с помощью
tunnel -K < procID >Параметры:
Полный список параметров см. в разделе: tunnel -h
Скачать с:
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelСделайте его исполняемым:
chmod +rx ./tunnelЗатем установите общесистемную команду:
./tunnel -c install Если у вас нет привилегий sudo , вы можете установить их локально:
./tunnel -c install -lЧтобы обновиться в любое время после установки:
tunnel -c update Эта программа представляет собой просто исполняемый сценарий bash , зависящий от стандартных инструментов GNU, включая socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 и т. д., которые легко доступны в стандартных дистрибутивах Linux.
Если в вашей системе отсутствует какой-либо из этих инструментов и у вас нет прав sudo необходимых для его установки из собственного репозитория пакетов (например, sudo apt-get install <package> ), попробуйте загрузить переносимый двоичный файл и установить его локально по адресу ${HOME}/.bin .
СШ :
Узел A предоставляет локальный порт SSH —
tunnel -k " ${secret} " 22Узел B подключается -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost ИПФС :
Пусть узел A имеет IPFS-peer-ID: 12orQmAlphanumeric . Ее демон IPFS прослушивает TCP-порт 4001 по умолчанию. Она предоставляет его с помощью -
tunnel -k " ${swarm_key} " ipfs swarm_key — это просто любая секретная строка, которую одноранговый узел A может использовать для контроля того, кто может подключиться к ней с помощью tunnel .
Пир B теперь соединяется с узлом A для обмена файлами, pubsub или p2p.
tunnel -k " ${swarm_key} " 12orQmAlphanumericЭтот последний командный рой подключается к узлу A через реле конвейерного сервера и продолжает групповое соединение каждые несколько секунд в фоновом режиме, чтобы поддерживать соединение.
tunnel запускает демон IPFS в фоновом режиме, если он еще не активен.
Путь к репозиторию IPFS можно передать с опцией -r . В противном случае переменная среды IPFS_PATH или путь по умолчанию ~/.ipfs используется как обычно. Пример: tunnel -r ~/.ipfs -i дает идентификатор узла IPFS.
Удаленная оболочка :
Предположим, вам нужно будет регулярно запускать команды на рабочем месте Linux с домашнего компьютера. И вы по какой-то причине не хотите/не можете использовать SSH через tunnel .
На рабочем компьютере откройте какой-нибудь случайный локальный TCP-порт, например 49090, и подключите оболочку к этому порту:
tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 'Вернувшись к себе домой:
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000Использование rlwrap не является необходимостью. Но это, безусловно, делает процесс более приятным, поскольку он использует GNU Readline и запоминает историю ввода (доступна с помощью клавиш со стрелками вверх/вниз, аналогично вашим локальным сеансам bash).
Редис :
Вам нужно подключиться к удаленному экземпляру Redis, размещенному у партнера или у вас самих? На удаленном хосте откройте TCP-порт, на котором работает redis-server (по умолчанию: 6379), с помощью tunnel .
На локальном компьютере используйте tunnel для перенаправления TCP-порта на удаленный порт. Направьте свой redis-cli на перенаправленный локальный порт.
Ниже приведены некоторые случайные варианты использования tunnel , которые я мог бы придумать. Вообще говоря, все, что связано с обходом NAT/брандмауэра (например, WebRTC без TURN) или подключением к удаленной локальной сети, должно найти полезным tunnel . Некоторые из следующих идей довольно схематичны, вообще не проверялись и могут не работать, но, тем не менее, они задокументированы здесь, по крайней мере на данный момент, просто ради вдохновения. Если вы нашли что-то из этого полезным или бесполезным, или вы нашли совершенно новые приложения для tunnel , пожалуйста, напишите об этом в обсуждениях. Те случаи, которые я опробовал, имеют пометку «рабочие».
tunnel .tunnel в Heroku (бесплатно) и перенаправьте порт, хранящийся в переменной среды PORT на ваш локальный порт, который вы хотите открыть. И у вас есть общедоступный URL-адрес: https://your-app-name.herokuapp.com.tunnel . tunnel шифрует весь трафик между узлом и ретранслятором с помощью TLS, если ретранслятор использует https. Между самими узлами сквозного шифрования как такового не существует. Однако утверждается, что реле конвейерного сервера не требует хранения данных .
Клиентский узел может соединиться с обслуживающим узлом только в том случае, если они используют один и тот же секретный ключ (TUNNEL_KEY). Ключ в основном используется для обнаружения одноранговых узлов на этапе ретрансляции. Для каждого нового подключения к перенаправленному локальному порту клиент отправляет случайный сеансовый ключ обслуживающему узлу. Затем одноранговые узлы формируют новое соединение в другой точке ретрансляции на основе этого случайного ключа для фактической передачи данных. Аутсайдеры, т. плохие актеры, не знающие TUNNEL_KEY, не смогут нарушить этот поток.
Однако злоумышленник может сделать следующее. Поскольку он знает TUNNEL_KEY и идентификатор узла обслуживающего узла, он может выдавать себя за последнего. Таким образом, данные от ничего не подозревающего подключающегося узла будут перенаправлены имитатору, что приведет к истощению настоящего сервера. Будущие обновления/реализации tunnel должны справиться с этой угрозой с использованием шифрования с открытым ключом. [В этом случае случайный сеансовый ключ, генерируемый для каждого нового пересылаемого соединения, будет расшифрован только подлинным сервером].
Учитывая, что tunnel по сути является транспортным уровнем, приведенные выше моменты не должны разочаровывать, поскольку большинство приложений, таких как SSH и IPFS, шифруют данные на уровне приложений. Сквозное шифрование tunnel для всех передач данных только увеличит задержку. Однако вы всегда можете создать SSH-туннель после установления низкоуровневого пиринга с помощью tunnel , если захотите.
Реле по умолчанию, используемое tunnel , — https://ppng.io. Вы также можете использовать какой-либо другой общедоступный ретранслятор из этого списка или разместить свой собственный экземпляр на бесплатных сервисах, например, предлагаемых Heroku. Излишне говорить, что для соединения два узла должны использовать один и тот же ретранслятор.
Если вы того пожелаете, вы также можете написать собственное реле, которое будет использоваться tunnel используя простые инструменты, такие как sertain. Просто убедитесь, что ваша служба ретрансляции имеет тот же API, что и конвейерный сервер. Если ваш код реле имеет открытый исходный код, вы можете представить его на обсуждениях.
гсокет; ipfs p2p с включенным релейным соединением; идти-трубопровод-дуплекс ; Pipeto.me ; восходящая линия связи; локальныйхост.run; нгрок; локальный туннель; sshreach.me ( бесплатная пробная версия только на ограниченный период времени ); более
Примечания:
tunnel и конвейерного сервера вы можете просто развернуть свой собственный экземпляр реле, раз и навсегда поделиться его общедоступным URL-адресом со своими коллегами, export то же самое, что и TUNNEL_RELAY в .bashrc , и все готово. Кроме того, для резервирования доступны несколько общедоступных конвейерных серверов.IPFS (Готово):
Подключиться к IPFS будет гораздо проще:
tunnel -k <secret> ipfs для раскрытия и tunnel -k <secret> <IPFS_peerID> для подключения.
Они запустят демон IPFS самостоятельно, если они находятся в автономном режиме. Последняя команда будет неоднократно подключаться к данному узлу с интервалом в 30 секунд. IPFS-peer-ID будет использоваться в качестве идентификатора узла, поэтому узлам больше не нужно будет разделять идентификаторы своих узлов отдельно. Пути репозитория IPFS, отличные от стандартных, можно передать с опцией -r . или IPFS_PATH .
СШ:
Создать SSH-туннель между локальным и одноранговым портом будет так же просто, как:
tunnel -k <secret> ssh для раскрытия &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> для создания.
Обратите внимание, что при подключении больше не нужно вводить имя для входа. ${USER} обслуживающего узла по умолчанию используется в качестве имени входа. Однако при необходимости имя для входа, отличное от заданного по умолчанию, всегда можно передать с помощью переменной или параметра среды.
ГПГ:
Виртуальные машины, например, используемые облачными оболочками и динамометрами, не имеют постоянных уникальных аппаратных адресов. Поэтому идентификатор узла продолжает меняться от сеанса к сеансу для такой виртуальной машины. В будущем tunnel будет опция -g , которая будет передавать в tunnel закрытый ключ GPG. Идентификатор узла будет генерироваться на основе отпечатка этого ключа, аналогично тому, что делает IPFS. Это также сделает tunnel более безопасным.
Аргон2:
Опция [ -a ] для использования argon2 для хеширования TUNNEL_KEY перед использованием, чтобы более слабый секрет не был слишком уязвим.
Пожалуйста, сообщайте об ошибках в вопросах. Публикуйте свои мысли, комментарии, идеи, варианты использования и запросы функций на обсуждение. Дайте мне знать, как это вам помогло, если вообще помогло.
Также не стесняйтесь писать мне напрямую обо всем, что касается этого проекта.
Если этот небольшой сценарий будет вам полезен, звезда будет для меня очень воодушевляющей.
Спасибо ! ?
