LINUX.ORG.RU

Использование обратных туннелей для доступа к устройствам за NAT

 ,

Использование обратных туннелей для доступа к устройствам за NAT

0

2

frp — это утилита для создания обратных туннелей. Она позволяет получить доступ к локальному ресурсу за NAT через промежуточный сервер.

Многие знают про существование сервисов типа ngrok и localtunnel, которые позволяют делать нечто подобное. У них есть бесплатные тарифные планы, которые имеют ограничения по ежемесячному трафику и количеству подключений. Поэтому (и не только) в ряде случаев использование self-hosted-решений, таких как frp, оказывается более предпочтительным.

Установка

Установка ручками

Так как frp написана на языке программирования Go, то для «установки» достаточно распаковать архив, содержащий исполняемые файлы. Они тащат с собой рантайм, а поэтому не требуют каких-либо системных зависимостей.

Скачиваем последнюю версию:

wget https://github.com/fatedier/frp/releases/download/v0.59.0/frp_0.59.0_linux_amd64.tar.gz

Распакуем архив:

tar -xvf frp_0.59.0_linux_amd64.tar.gz

В распакованной директории будут два исполняемых файла: frps (сервер) и frpc (клиент). Переместим их в /usr/local/bin:

mv frp_0.59.0_linux_amd64/frp{s,c} /usr/local/bin

Arch Linux:

# сервер
yay -S frps-bin

# клиень
yay -S frpc-bin

NixOS:

nix-env -iA nixpkgs.frp

Настройки сервера

Создайте конфигурационный файл для сервера frps. Например, /etc/frps.ini, он должен содержать что-то типа этого:

[common]
bind_port = 7000

# Доп. настройки, которые могут быть полезны

# Токен доступа для аутентификации клиентов
# token = <your_secure_token>

# Ограничение скорости до 10 МБ/с для каждого соединения
bandwidth_limit = 10MB

# можно так же запустить веб-админку
dashboard_port = 7500
dashboard_user = admin
dashboard_pwd = admin123

Этот файл конфигурации указывает серверу frps прослушивать порт 7000 для входящих соединений. На 7500 порту будет висеть Dashboard, где можно посмотреть, например, трафик.

Далее настройте systemd для автоматического запуска сервера frps. Пример содержимого файла /etc/systemd/system/frps.service:

[Unit]
Description=FRP Server Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/frps -c /etc/frps.ini
Restart=on-failure
RestartSec=15s

Для активации и запуска сервиса выполните:

systemctl daemon-reload
systemctl enable --now frps

Проверим статус сервиса:

systemctl status frps

Если не знаем или не помним ip сервера:

curl -s https://ifconfig.me
curl -s https://api.ipify.org
curl -s https://ipinfo.io

Настройка клиента

Создайте конфигурационный файл для frps:

/path/to/frpc.ini

# Основные настройки
[common]
server_addr = <server_ip>
server_port = 7000

# ssh - это имя, которое выдумываешь сам и таких пользовательских сегментов может быть сколько угодно
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 10022

Замените <server_ip> на IP-адрес вашего сервера. Эта конфигурация позволяет пробросить локальный SSH-сервер (порт 22) на внешний порт 10022 на сервере.

Запустите клиент frp с указанной конфигурацией:

frpc -c /path/to/frpc.ini

Использование конфига аналогично запуску такой команды:

frpc tcp -n 'ssh' -s <server_ip> -P 7000 --local_ip=127.0.0.1 --local_port=22 --remote_port=10022

Проверка

После этого можно подключиться к домашнему ПК через SSH с использованием команды:

ssh -p 10022 user@server_ip


Проверено: hobbit ()
Последнее исправление: rtxtxtrx (всего исправлений: 13)

Ответ на: комментарий от MOPKOBKA

Использование frp (Fast Reverse Proxy) и SSH с параметром -R (Reverse SSH) решает схожие задачи — доступ к внутренним ресурсам через публичный сервер, но каждый из этих инструментов имеет свои особенности, преимущества и недостатки. Вот чем frp может быть лучше:

1. Многообразие протоколов

  • frp поддерживает не только TCP-туннелирование, как SSH, но и HTTP, HTTPS, UDP и другие протоколы. Это делает его более универсальным, особенно если нужно пробрасывать не только SSH, но и другие типы трафика (например, веб-сервисы).
  • SSH -R ограничен только TCP и в основном используется для проброса SSH и HTTP/HTTPS.

2. Производительность и масштабируемость

  • frp разработан для высоких нагрузок и может обрабатывать большое количество соединений с минимальной задержкой. Он лучше справляется с параллельными запросами и имеет встроенные механизмы балансировки нагрузки.
  • SSH -R не предназначен для масштабных решений. При высоких нагрузках или большом количестве подключений производительность может снижаться.

3. Управление и мониторинг

  • frp имеет встроенные возможности для мониторинга состояния туннелей, логирования и управления через веб-интерфейс. Это упрощает администрирование и отслеживание работы системы.
  • SSH -R таких возможностей не предоставляет, поэтому для мониторинга и управления требуются сторонние инструменты.

4. Безопасность

  • frp может использовать SSL/TLS для шифрования трафика и поддерживает аутентификацию через токены, что добавляет дополнительный уровень безопасности.
  • SSH -R сам по себе уже шифрует трафик, но аутентификация ограничена ключами SSH или паролями, что может быть менее гибким, чем решения frp.

5. Гибкость конфигурации

  • frp позволяет тонко настраивать правила маршрутизации трафика, такие как перенаправление на разные backend-сервисы в зависимости от URL или заголовков запроса.
  • SSH -R не предоставляет таких возможностей. Вы ограничены простыми пробросами портов.

6. Поддержка NAT и сложных сетей

  • frp проще и эффективнее работает в условиях сложных сетей, например, когда обе стороны находятся за NAT или файрволлом. Он специально разработан для обхода таких ограничений.
  • SSH -R также может работать в таких условиях, но требует больше усилий для настройки, особенно в сложных сетевых топологиях.

7. Легкость в использовании и развертывании

  • frp более прост в развертывании и управлении на стороне клиента и сервера. Он требует минимальных зависимостей и легко настраивается.
  • SSH -R требует установки и настройки SSH-сервера на обеих сторонах, а также может требовать дополнительной настройки для обеспечения стабильности соединений.

Заключение

frp лучше подходит для сложных и масштабируемых задач, требующих работы с разными протоколами и высокой производительности. SSH -R является отличным выбором для простых сценариев, особенно если уже настроен SSH-доступ, но для более сложных случаев или при необходимости проброса множества сервисов, frp будет более предпочтительным вариантом.

rtxtxtrx
() автор топика
Ответ на: комментарий от rtxtxtrx

Не говоря уже о настройках типа ограничения трафика. Мне лень рассказывать очевидные вещи.

rtxtxtrx
() автор топика

Раз всё равно нужна машина в диком интернете, чем это лучше поднятия произвольного туннеля? Хоть pptp, хоть openvpn.

yu-boot ★★★★★
()
Ответ на: комментарий от yu-boot

Тут содержится описания одной конкретной утилиты. Она проще в настройке. Ты в одном файлике можешь описать кучу всяких сервисов. Установку openvpn только 10 страниц можно расписать, а настройку туннеля еще на две. Ни к месту тоже замечание

rtxtxtrx
() автор топика

Ещё можно поднимать pptp туннель через ssh сессию и никаких левых утилит на го не нужно.

Хост за нат поднимает ссш подключение и выполняются команды по поднятию pptp клиентов, все это автоматом. Дальше через туннельные интерфейсы все ходит и работает.

kostik87 ★★★★★
()

Очень интересно: а что если промежуточный сервер не вариант? Есть ли респектабельные (а не наколенные, вроде слушать какой-то сервис за натом через на предмет поступления команды «поднять соединение до x.x.x.x») решения для таких ситуаций?

Smacker ★★★★★
()

а что насчет восстановления туннеля после обрыва? пример, на клиенте достать кабель из сетевухи на 1 секунду/10 секунд/1 минуту/2 минуты, что будет? как быстро восстановится туннель? на ssh -R все таймауты можно хорошо затюнить (клиент+сервер), а frp?

Bers666 ★★★★★
()

Скачиваем последнюю версию:

wget...

Что ж, окажется в репозитории может и посмотрю, пока что какая-то васяновская поделка

ya-betmen ★★★★★
()

После этого можно подключиться к домашнему ПК через SSH с использованием команды:

ssh -p 10022 user@server_ip

Так а можно же ssh-м так же порт пробросить, Нафиг оно нужно?

pihter ★★★★★
()
Ответ на: комментарий от rtxtxtrx

Ты мне и с «русским» помочь не сможешь)), но я постараюсь пережить 😀

Твоя статья практически полностью бесполезна

PRN
()

mv frp_0.59.0_linux_amd64/frp{s,c} /usr/bin

Не надо так делать, для этого есть /usr/local/bin

Radjah ★★★★★
()
# Доп. настройки, которые могут быть полезны

# Токен доступа для аутентификации клиентов
# token = <your_secure_token>

# Доп. настройки, которые могут быть полезны

# Токен доступа для аутентификации клиентов
# token = <your_secure_token>

Тут вроде одно и то же 2 раза прописано - надо поправить.

u5er
()
Ответ на: комментарий от ya-betmen

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

rtxtxtrx
() автор топика

Ты написал много, но забыл сказать самое главное: где должен размещаться сервер, и где размещается клиент.

Xintrea ★★★★★
()
Ответ на: комментарий от rtxtxtrx

Но ты же написал про self-hosted решение. Self-хостинг - это сервер под кроватью. «Твоя машина» - это компьютер пользователя или смартфон за NAT. «Удаленный сервер», согласно понятию о селф-хостинге, это тоже домашний компьютер, а значит он тоже за NAT (но, обычно, в другой локации). Так как вся эта связка должна работать?

Xintrea ★★★★★
()
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от Xintrea

self-hosted

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

rtxtxtrx
() автор топика
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Я все никак не могу вытянуть от тебя как от автора опуса, где должен находиться сервер. У него должен быть белый IP и он должен светиться напрямую в интернет?

Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

Удаленный сервер нужен для того чтобы через него могли подключиться к твоей машине за nat. Пользователь -> сервер в интернете -> твоя машина

rtxtxtrx
() автор топика
Ответ на: комментарий от rtxtxtrx

Пользователь -> сервер в интернете -> твоя машина

Фак мой мозг, значит уже не две а три сущности?

Ты только что говорил про «клиент - это хост (твоя машина), сервер - это удаленный сервер». Что ты теперб подразумеваешь под «пользователь»?

Xintrea ★★★★★
()
Ответ на: комментарий от rtxtxtrx
  1. Безопасность frp может использовать SSL/TLS для шифрования трафика и поддерживает аутентификацию через токены, что добавляет дополнительный уровень безопасности. SSH -R сам по себе уже шифрует трафик, но аутентификация ограничена ключами SSH или паролями, что может быть менее гибким, чем решения frp.

Ну что за детский сад? SSH поддерживает передовую криптографию, включая пост-квантовые алгоритмы обмена ключей, а так же механизмы разделения ресурсов и изоляции подпроцессов — это весьма безопасный, выверенный годами код.

А frp основан на SSL/TLS, где решето на решете, не говоря уже о массе устаревших алгоритмов, а пост-квантовых и вовсе нет, по крайней мере в стандартных реализациях.

Bircoph
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.