Что имеем и зачем всё это
У вас дома крутятся полезные сервисы: Home Assistant, code-server или Nextcloud. Или вы только собираетесь их запустить. Пока вы дома, всё открывается по локальному IP. Но стоит выйти за пределы квартиры, и сервисы пропадают. Причина: провайдер выдал серый IP-адрес, то есть применяет CGNAT. Белый адрес получить либо нельзя (примерно, как советский дефицит), либо он стоит дополнительных денег.
Сначала разберёмся с железом. Если домашний сервер уже есть, отлично. Если только планируете, вот варианты под любой бюджет:
Российские одноплатники. Repka Pi или Элтай ЭсСи (Eltay SC) от новосибирской компании «Элрон» на базе процессора «Скиф». Прямые аналоги Raspberry Pi на отечественной элементной базе.
Китайские одноплатники. Orange Pi, Banana Pi, Radxa. Доступны, имеют активные русскоязычные сообщества, часто предлагают лучшие характеристики за меньшие деньги.
Старый ноутбук или ПК. Самый народный путь. Мощности даже 10–15-летнего устройства с избытком хватит для домашнего сервера. У меня старенький, 14-летний Acer, рука не поднялась выбросить, поцарапанный, со сколами, но старый конь борозды не портит.
Возникает резонный вопрос: почему бы просто не арендовать VPS и не перенести все сервисы туда? Формально можно. Но у домашнего сервера есть преимущества, которых нет у VPS за 300–500 рублей:
Дисковое пространство. На домашнем сервере у вас может быть терабайт фотографий, фильмов и музыки. VPS с таким объёмом диска стоит совсем других денег.
Локальный доступ без интернета. Home Assistant продолжит управлять умным домом, даже если интернет пропадет. А фильмы и музыка будут доступны по локальной сети без задержек и без расхода трафика.
Приватность. Данные лежат у вас дома, а не в дата-центре. Для кого-то это важно, в том числе для меня.
Производительность. Старый ноутбук с i5 может быть мощнее бюджетного VPS с одним vCPU.
Поэтому мы не заменяем домашний сервер, а даём ему публичный адрес через недорогой VPS-бастион. Сам VPS выступает только как прокси и не хранит данные.
Что делаем. Мы арендуем VPS с публичным IP ( можно найти конфигурации за 300–500 рублей в месяц). На самом деле проверяйте актуальные цены у провайдеров, так как рынок очень динамичный. Этот VPS будет точкой входа, или бастионом. Домашний сервер сам установит SSH-соединение с VPS и скажет: «Всё, что придёт на твой порт 8123, пересылай мне на локальный порт 8123». Получается зашифрованный туннель из дома наружу, которому не страшен NAT провайдера.
Моя цель — показать не просто работающий, а безопасный и отказоустойчивый метод. Я расскажу, почему для ключа мы выбираем ed25519 с дополнительными раундами KDF, зачем отключаем пароль для пользователя туннеля, как autossh и systemd вместе держат соединение даже при обрывах сети. Всё это сделано, чтобы туннель не падал каждую ночь и чтобы злоумышленник не мог подобрать пароль или ключ.
Такой подход выгоден по нескольким причинам:
Не нужно открывать порты на роутере.
Трафик между вами и домом шифруется.
Работает с любым провайдером, даже если используется CGNAT.
Мы не зависим от сторонних сервисов (будь то заблокированный Cloudflare или отечественные решения вроде DDoS-Guard или Qrator Labs) и полностью контролируем свои данные.
Как работает обратный SSH-туннель
Механизм простой. Выполняя команду
ssh -R 8123:localhost:8123 tunneluser@vps_ip
домашний сервер просит удалённую сторону (VPS) начать слушать порт 8123 и всё, что на него приходит, отправлять обратно через это же SSH-соединение на локальный порт 8123 домашней машины.
Когда кто-то из интернета стучится на <IP_VPS>:8123, трафик проходит такой путь:
Клиент → VPS:порт 8123 → SSH-туннель → Домашний сервер:порт 8123
Соединение всегда инициируется изнутри дома наружу, поэтому NAT на стороне провайдера не мешает. Чтобы пробросить несколько сервисов, просто добавляют несколько ключей -R. Чтобы туннель сам восстанавливался после обрывов связи, используют autossh. Аutossh это умная обёртка над обычным SSH.
Шаг 1. Подготовка VPS
Подключаемся к VPS по SSH.
Первым делом открываем конфигурационный файл SSH-сервера:
sudo nano /etc/ssh/sshd_config
Нам нужно явно разрешить проброс портов на все сетевые интерфейсы. По умолчанию SSH пробрасывает порты только на loopback (127.0.0.1), и подключиться к ним извне не получится. Ищем или добавляем две строки:
GatewayPorts yes AllowTcpForwarding yes
Настройка sshd_config в редакторе nano
Сохраняем файл и перезагружаем sshd, чтобы настройки применились:
sudo systemctl restart sshd
Теперь создадим отдельного пользователя, от имени которого домашний сервер будет устанавливать туннель. Использовать для этого root или своего обычного пользователя небезопасно: если злоумышленник завладеет ключом, он не должен получить возможность выполнять команды на VPS. Пользователю tunneluser мы это запретим, но пока создадим его с обычной оболочкой, чтобы скопировать ключ.
Создаём пользователя и задаём ему временный пароль:
sudo adduser tunneluser --disabled-password sudo passwd tunneluser
Теперь с домашнего сервера копируем публичный ключ. На домашнем сервере выполните:
ssh-copy-id -i ~/.ssh/id_ed25519.pub tunneluser@<IP_VPS>
После ввода временного пароля ключ будет добавлен. Проверим, что вход работает:
ssh tunneluser@<IP_VPS> hostname
Появится имя VPS и сразу соединение закроется. Если ошибка тогда проверьте права на ~/.ssh и authorized_keys на VPS у пользователя tunneluser.
Теперь, когда ключ скопирован, меняем оболочку на /usr/sbin/nologin, чтобы пользователь не мог выполнять команды. Проброс портов через -R продолжит работать, потому что для этого не нужен shell.
sudo usermod -s /usr/sbin/nologin tunneluser
В некоторых дистрибутивах (включая Ubuntu) /usr/sbin/nologin отсутствует в файле /etc/shells. Тогда sshd при подключении с ключом может отказать, даже если выполняется только проброс. Добавим оболочку в список разрешённых:
echo /usr/sbin/nologin | sudo tee -a /etc/shells
Теперь от имени tunneluser создадим каталог .ssh и выставим правильные права. Временно переключимся в его окружение:
sudo su - tunneluser -s /bin/bash mkdir -p ~/.ssh chmod 700 ~/.ssh exit
Создание каталога .ssh для пользователя tunneluser
Запретим вход по паролю для tunneluser. Снова откроем /etc/ssh/sshd_config и в конец добавим:
Match User tunneluser PasswordAuthentication no
Перезагружаем sshd:
sudo systemctl restart sshd
Теперь tunneluser сможет зайти только по ключу, пароль не сработает.
Также установим пакет psmisc, если его нет. В минимальных образах VPS утилита fuser может отсутствовать, а она понадобится скрипту для освобождения портов после обрыва туннеля.
sudo apt install -y psmisc
Установка пакета psmisc и управление паролем tunneluser
На этом подготовка VPS завершена.
Шаг 2. Настройка домашнего сервера
Все следующие команды выполняются на вашем домашнем устройстве: Raspberry Pi, Orange Pi, старом ноутбуке и так далее.
2.1. Генерируем SSH-ключ
Для аутентификации на VPS без пароля нам нужна пара ключей. Рекомендую использовать алгоритм ed25519: он быстрее и безопаснее, чем RSA, а ключи получаются короткими. Параметр -a 100 задаёт количество раундов KDF (функции формирования ключа). Если вы решите защитить приватный ключ паролем, это значительно замедлит попытки его подбора. В нашем случае ключ будет без пароля, чтобы autossh мог работать автоматически, но привычка указывать -a 100 полезна на будущее.
ssh-keygen -t ed25519 -a 100 -C "home-to-vps-tunnel"
На запрос пароля нажимаем Enter дважды оставляем пустым.
2.2. Устанавливаем autossh
Обычный SSH не умеет перезапускать туннель при обрыве. Если связь пропадёт, порты на VPS останутся «висеть» в занятом состоянии, и новый туннель не поднимется. autossh решает эту проблему: он мониторит состояние соединения и при необходимости перезапускает процесс.
sudo apt update sudo apt install -y autossh
2.3. Список сервисов для проброса
Чтобы не редактировать скрипт каждый раз, когда добавляется новый сервис, заведём отдельный файл конфигурации. В нём просто перечисляются пары портов: удалённый порт на VPS и локальный порт домашнего сервера.
sudo nano /etc/sshtunnels/services.conf
Пример содержимого:
# Home Assistant 8123:8123 # Jellyfin 8096:8096 # code-server 8443:8443 # SSH на домашний сервер (нестандартный порт, чтобы не мешать VPS) 2222:22
Формат: удалённый_порт_на_VPS:локальный_порт_домашнего_сервера. Строки, начинающиеся с #, игнорируются.
Обратите внимание на проброс SSH: домашний сервер станет доступен снаружи на порту 2222. Убедитесь, что на домашнем сервере также настроена аутентификация только по ключу, а вход по паролю отключён.
2.4. Пишем скрипт для запуска туннеля
Создадим скрипт, который будет читать services.conf и формировать команду для autossh.
sudo nano /usr/local/bin/tunnel-manager.sh
Скрипт выглядит так (замените REMOTE_HOST и путь к ключу на свои):
#!/bin/bash REMOTE_USER="tunneluser" REMOTE_HOST="123.123.123.123" # ваш IP VPS SSH_KEY="/home/pi/.ssh/id_ed25519" # путь к приватному ключу SSH_PORT="22" CONFIG_FILE="/etc/sshtunnels/services.conf" FORWARD_OPTS="" while IFS=: read -r remote_port local_port; do # Пропускаем пустые строки и комментарии [[ -z "$remote_port" || "$remote_port" =~ ^# ]] && continue # Убиваем старые процессы на удалённом порту, если туннель упал и порт остался занят ssh -p "$SSH_PORT" -i "$SSH_KEY" "$REMOTE_USER@$REMOTE_HOST" \ "command -v fuser && fuser -k ${remote_port}/tcp 2>/dev/null || true" FORWARD_OPTS="$FORWARD_OPTS -R ${remote_port}:localhost:${local_port}" done < "$CONFIG_FILE" echo "Запускаем туннели к $REMOTE_HOST с параметрами: $FORWARD_OPTS" exec autossh -M 0 \ -o "ServerAliveInterval=30" \ -o "ServerAliveCountMax=3" \ -o "ExitOnForwardFailure=yes" \ -o "StrictHostKeyChecking=no" \ -o "GatewayPorts=yes" \ -N -T \ -i "$SSH_KEY" \ -p "$SSH_PORT" \ $FORWARD_OPTS \ "$REMOTE_USER@$REMOTE_HOST"
Скрипт запуска туннеля tunnel-manager.sh
tunnel-manager.sh. В строках REMOTE_HOST и SSH_KEY замените значения на свои. Поясню ключевые моменты.
command -v fuser && fuser -k ... || true— сначала проверяем, есть лиfuserна VPS. Если нет, ничего не делаем, и код возврата всегда нулевой. Иначе скрипт мог бы упасть при отсутствииfuser.ExitOnForwardFailure=yes— если по какой-то причине не удалось пробросить хотя бы один порт, SSH немедленно завершится. Тогда systemd зафиксирует падение и перезапустит скрипт.StrictHostKeyChecking=no— отключает проверку отпечатка ключа хоста. Мы доверяем своему VPS, иначе при первом подключении система спросила бы подтверждение и скрипт завис. Если хотите усилить безопасность, выполните на домашнем сервереssh-keyscan -H <IP_VPS> >> ~/.ssh/known_hostsи заменитеStrictHostKeyChecking=noнаStrictHostKeyChecking=accept-new. В этом случае туннель примет только сохранённый отпечаток.GatewayPorts=yes— на всякий случай дублирует глобальную настройку, гарантируя, что проброшенные порты будут слушать все интерфейсы.-N— не выполнять никаких команд на удалённой стороне, только проброс портов.-T— не выделять псевдотерминал, что уменьшает накладные расходы.ServerAliveInterval=30иServerAliveCountMax=3— каждые 30 секунд SSH отправляет keepalive-пакет. Если три пакета подряд не получат ответа, соединение считается разорванным, и autossh инициирует переподключение.-M 0— отключает встроенный мониторинговый порт autossh. Мы полагаемся на механизмы keepalive самого SSH и перезапуск через systemd.
Делаем скрипт исполняемым:
sudo chmod +x /usr/local/bin/tunnel-manager.sh
2.5. Создаём systemd-сервис
Чтобы туннель автоматически стартовал при загрузке системы, оформим его как службу systemd.
Пользователям Windows (WSL): стандартная установка WSL не использует systemd. Чтобы команды ниже работали, включите systemd: добавьте в /etc/wsl.conf строки:
[boot] systemd=true
Затем перезапустите WSL командой wsl --shutdown в PowerShell и снова откройте терминал Ubuntu. Если systemd не нужен, просто запускайте туннель вручную через nohup, но тогда он не будет стартовать автоматически при загрузке.
Создаём файл службы:
sudo nano /etc/systemd/system/autossh-tunnel.service
Содержимое:
[Unit] Description=Persistent SSH Reverse Tunnel to VPS After=network-online.target Wants=network-online.target [Service] Type=exec ExecStart=/usr/local/bin/tunnel-manager.sh Restart=always RestartSec=20 StartLimitIntervalSec=0 Environment="AUTOSSH_GATETIME=0" Environment="AUTOSSH_POLL=60" [Install] WantedBy=multi-user.target
Файл службы
Параметры:
After=network-online.target— служба стартует только после полной инициализации сети.Restart=always— перезапускать при любом завершении, кроме явной остановки черезsystemctl stop.RestartSec=20— ждать 20 секунд перед повторной попыткой. Небольшая пауза полезна, чтобы не заддосить VPS при быстро повторяющихся ошибках.AUTOSSH_GATETIME=0— считать первое соединение успешным сразу, без задержки.AUTOSSH_POLL=60— интервал, с которым autossh опрашивает состояние соединения (в дополнение к ServerAliveInterval).
Шаг 3. Запуск и проверка
Перед запуском туннеля на VPS нужно открыть порты, которые мы будем пробрасывать. Иначе туннель установится, но подключиться извне не получится. Выполните на VPS:
sudo ufw allow 8123/tcp sudo ufw allow 8096/tcp sudo ufw allow 8443/tcp sudo ufw allow 2222/tcp sudo ufw enable
Если вы пробрасываете дополнительные порты, откройте и их, например sudo ufw allow 8080/tcp.
Теперь на домашнем сервере активируем и запускаем службу:
sudo systemctl daemon-reload sudo systemctl enable autossh-tunnel sudo systemctl start autossh-tunnel
Проверяем статус:
sudo systemctl status autossh-tunnel
Теперь возьмите телефон, отключите Wi-Fi (чтобы трафик шёл через мобильную сеть) и откройте браузер. В адресной строке введите http://<IP\_VPS>:8123. Должен открыться интерфейс Home Assistant. Аналогично проверьте Jellyfin на порту 8096 и другие сервисы.
Доступ к домашнему серверу через мобильную сеть
Для контроля можно проверить проброс на VPS:
ss -tulpn | grep 8123
Если не работает:
Убедитесь, что на домашнем сервере сервис действительно слушает нужный порт:
ss -tulpn | grep 8123. Еслиssотсутствует, используйтеnetstat -tulpn | grep 8123илиlsof -i :8123.Проверьте, не занят ли этот порт на самом VPS каким-то процессом:
ss -tulpn | grep 8123.Возможно, на VPS включен файрвол ufw, и порты закрыты. Разрешите их, как описано выше.
Если на VPS не найдена утилита
fuser, установите её:sudo apt install -y psmisc. Она нужна скрипту для очистки портов после обрыва туннеля.
Типичная ситуация: если VPS перезагрузился в тот момент, когда туннель был активен, порты на VPS могут на короткое время остаться в состоянии TIME_WAIT. autossh с настройками выше переподнимет соединение, но возможна задержка до минуты. Если порт долго не освобождается, зайдите на VPS и проверьте ss -tulpn | grep <порт>. При необходимости завершите зависший процесс вручную.
Шаг 4. Базовая безопасность
4.1. Файрвол на VPS
Мы уже открыли нужные порты в ufw. Если вы всегда подключаетесь с одного IP (например, с работы), можно дополнительно ограничить доступ к чувствительным сервисам:
sudo ufw allow from <ваш_статический_IP> to any port 8123
После настройки Caddy и переноса сервисов на HTTPS прямые порты рекомендуется закрыть (см. раздел 4.3).
4.2. Регулярная замена ключей
Раз в полгода генерируйте новую пару ключей на домашнем сервере и заменяйте публичный ключ на VPS в /home/tunneluser/.ssh/authorized_keys. Так вы перестрахуетесь на случай, если старый ключ скомпрометируют, то есть попросту угонят.
4.3. HTTPS для сервисов
Пока мы ходим по HTTP, трафик не зашифрован между клиентом и VPS. Чтобы это исправить, нужен обратный прокси с SSL. Самый простой вариант — Caddy, потому что он автоматически получает сертификаты Let’s Encrypt и требует минимум настроек.
Установка на VPS:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update sudo apt install caddy
Конфигурация (/etc/caddy/Caddyfile):
hass.my-domain.ru { reverse_proxy localhost:8123 } jellyfin.my-domain.ru { reverse_proxy localhost:8096 } code.my-domain.ru { reverse_proxy localhost:8443 }
Конфигурация Caddy для HTTPS и обратного прокси
Примечание: для автоматического HTTPS нужен реальный домен, направленный A-записью на IP вашего VPS. Если домена пока нет, Caddy можно использовать как обычный обратный прокси. Минимальная конфигурация для теста:
:80 { reverse_proxy localhost:8080 }
После привязки домена замените :80 на ваш поддомен (например, hass.my-domain.ru) — Caddy сам запросит сертификат и настроит HTTPS.
Перезапуск:
sudo systemctl restart caddy
Проверим локально, что Caddy проксирует запросы:
curl -I http://localhost:80
Проверка работы Caddy
Caddy сам запросит сертификаты, и через минуту ваши сервисы будут доступны по HTTPS с человеческими адресами. После того как Caddy заработал, прямые порты можно закрыть, чтобы сервисы не светились по HTTP:
sudo ufw delete allow 8123/tcp sudo ufw delete allow 8096/tcp sudo ufw delete allow 8443/tcp
Теперь трафик будет ходить только через зашифрованные соединения на 443 порт.
При желании можно добавить запрос пароля на уровне Caddy:
sudo apt install apache2-utils htpasswd -c /etc/caddy/.htpasswd username
И в блок сервиса добавить:
hass.my-domain.ru { basicauth { username $2a$14$... } reverse_proxy localhost:8123 }
Хэш пароля берётся из созданного файла.
Примечание: при использовании обратного прокси все сервисы будут видеть запросы как пришедшие с 127.0.0.1, что может мешать анализу логов. В продвинутых сценариях это исправляется добавлением в конфигурацию Caddy директивы trusted_proxies и пробросом реального IP клиента. Для базовой установки такое поведение обычно не критично.
Шаг 5. Задержка
Добавление VPS в цепочку неизбежно увеличивает пинг, но SSH-туннель вносит минимальный оверхед. Если VPS находится в том же регионе, что и вы, задержка вырастает на 2–8 миллисекунд. Это практически незаметно при работе с веб-интерфейсами и передаче команд.
Альтернативы
Если autossh и ручная настройка кажутся громоздкими, можно посмотреть на утилиты вроде rathole, frp или bore. Они тоже делают проброс портов, но требуют установки своего ПО как на домашний сервер, так и на VPS. Наш метод хорош тем, что на VPS не нужно ставить ничего, кроме штатного SSH-сервера, который уже есть в любой Ubuntu.
Итог
Теперь у вас есть полноценный доступ к домашним сервисам из любой точки мира. Всё, что для этого потребовалось: VPS за 300–500 рублей в месяц и полчаса на настройку. Туннель работает прозрачно и шифрует трафик по пути. Самое важное: мы сделали его устойчивым к обрывам и защищённым от самых очевидных атак. Надеюсь, этот туториал поможет вам наладить свою инфраструктуру без лишней головной боли. Если что-то пошло не так, заглядывайте в логи journalctl -u autossh-tunnel и пишите в комментариях, разберёмся вместе.
Комментарии (129)
ArtemSmit
22.05.2026 12:20Вообще последнее время на хабре засилье статей в духе троллейбусостроения. В данном случае стоило бы назвать статью "Как подключиться к домашнему серверу без белого IP если у вас уже есть VPS". Плюсом - то ли у меня уже взгляд замылен, то ли реально каждая вторая статья нейросетями пишется. Вот это вот перечисление в духе "Если только планируете, вот варианты под любой бюджет..." звучит ну очень нейрослопно.
AriaQA Автор
22.05.2026 12:20Название говорит само за себя "VPS-бастион". Простите, что вам непонятно, что статья будет затрагивать VPS? По поводу "нейрослопа" это не художественная литература и даже не мнение. Это туториал. Люди открывают туториал, садятся и делают. Туториал должен быть максимально понятным. А вам, я так понимаю, сказать по существу нечего вот и прицепились к "нейрослопу".
exeonid
22.05.2026 12:20сказать по существу нечего вот и прицепились к “нейрослопу”
Претензии к материалу на самом деле имеются: может быть поясните зачем вы используете SSH-туннель для того чтобы гонять медиа-трафик? Помимо избыточного оверхеда и проблем с MTU вы еще можете подставить пользователя под блокировку со стороны ТСПУ из-за такого поведения. Данный протокол даже близко не для этого (название как бы намекает). И для решения конкретно этой проблемы лучше использовать что-то типа NetBird или Pangolin, Tailscale / ZeroTier.
Но какой в этом смысл, если вы выступаете в качестве посредника между читателем и GPT. На мои вопросы всё равно ответ будет сгенерирован нейросетью или фаталити-ответ: "это для новичков" / "я так вижу".
Использование нейросетей само по себе не плохо, если вы хотите разобраться в теме глубже, сделать анализ, проверить гипотезы, провести тестирование, получить результат. Но если без понимания материала генерируете нейрослоп говорит только о том, что вы не знаете предметную область, и писать "туториалы" (ещё и не правильные) — не ваш уровень.
Раньше копирайтеры "наливали воды" переписывая чужие статьи, теперь генерируют тонны мусора. Кстати на одном из форумов для копирайтеров видел тему "Должен ли копирайтер разбираться в теме о которой пишет". Были жаркие споры и пришли к выводу, что пока платят за объём и SEO, разбираться в теме необязательно.
guselnikov
22.05.2026 12:20Полностью согласен, да и для доступа из вне в свою сеть для таких задач куда проще VPN по поднять, тем более если хостер Российский то все туннели работают корректно. У меня 2 впс в Росси у разных хостеров и что вг что л2тп что опен впн работаю стабильно. SSH не для этих целей
Serg10
22.05.2026 12:20ВПН часто отваливается, и пока его не переподключишь он не одупляется - пробовал и openconnect и vless. Если есть решение, я был бы рад совету
guselnikov
22.05.2026 12:20Не знаю, у меня в микроте работает l2tp в Европу и WG Москва. Если посмотреть по логам то можно встретить когда пропадает соединение и оно тут же восстанавливается. В Proxmox есть виртуалка в которой поднял клиент AmneziaWG - так же работает стабильно, если упала сама поднялась.
AriaQA Автор
22.05.2026 12:20Претензии к материалу на самом деле имеются: может быть поясните зачем вы используете SSH-туннель для того чтобы гонять медиа-трафик? Помимо избыточного оверхеда и проблем с MTU вы еще можете подставить пользователя под блокировку со стороны ТСПУ из-за такого поведения. Данный протокол даже близко не для этого (название как бы намекает). И для решения конкретно этой проблемы лучше использовать что-то типа NetBird или Pangolin, Tailscale / ZeroTier.
Конкретно для какой проблемы, вы так и не озвучили. У меня проблема, мне нужно не находясь дома, включить бойлер, что бы он нагрел воду к моему приходу. У меня есть домашний сервер и VPS. И какой к чертям собачим MTU и ТСПУ? У меня тут что, видио в 4к гоняются?
Использование нейросетей само по себе не плохо, если вы хотите разобраться в теме глубже, сделать анализ, проверить гипотезы, провести тестирование, получить результат. Но если без понимания материала генерируете нейрослоп говорит только о том, что вы не знаете предметную область, и писать "туториалы" (ещё и не правильные) — не ваш уровень. Раньше копирайтеры "наливали воды" переписывая чужие статьи, теперь генерируют тонны мусора. Кстати на одном из форумов для копирайтеров видел тему "Должен ли копирайтер разбираться в теме о которой пишет". Были жаркие споры и пришли к выводу, что пока платят за объём и SEO, разбираться в теме необязательно.
О чем вы говорите? Уважаемый, в туториале, если вы не заметили, есть подробные скрины с моего реального сервера. Они доказывают, что я лично этот путь прошла от первой команды до работающего туннеля. Так что ваши инсинуации про "нейрослоп" мимо кассы.
Вы ошибаетесь. Это мой личный блог, и мне за него никто не платит. Никаких заказчиков, SEO-метрик и правок от редактора. Я пишу только о том в чем разбираюсь, или о том что изучаю. Вы тут самоутвердится решили с кармой -8? Я так понимаю, вы очень много пользы принесли на Хабре, так много, что люди такую пользу минусовать стали.
exeonid
22.05.2026 12:20с кармой -8
У меня нет проблем с самооценкой, и циферки под комментариями для меня не имеют значения. Сегодня -8, завтра +8.
У вас дома крутятся полезные сервисы: Home Assistant, code-server или Nextcloud. У меня проблема, мне нужно не находясь дома, включить бойлер
Фаталити-ответ: “я так вижу”. Начать с Nextcloud и закончить "просто включить бойлер". Поясните пожалуйста зачем весь этот пердолинг вместо:
sudo apt get install netbirdэтот путь прошла от первой команды до работающего туннеля
Вы и штаны можете через голову надевать
Никаких заказчиков, SEO-метрик и правок от редактора
https://habr.com/ru/articles/1038422/
Видимо это ваш брат-близнец с такой же проблемой и такими же аргументами целесообразности такой схемы
AriaQA Автор
22.05.2026 12:20У меня нет проблем с самооценкой, и циферки под комментариями для меня не имеют значения. Сегодня -8, завтра +8.
Это не вопрос самооценки. Хабравчане не глупые люди, они умеют читать и анализировать. И если ваши "ремарки" и "ценное мнение" сообщество загнало в −8, значит никакой ценности они не представляют. Вы не пишите статей, вообще, только ходите и выражаете "мнение" на чужой труд.
Фаталити-ответ: “я так вижу”. Начать с Nextcloud и закончить "просто включить бойлер". Поясните пожалуйста зачем весь этот пердолинг вместо: sudo apt get install netbird
Вы учите меня, как мне писать статью? Зачем? Напишите просто свою статью, с «правильными вводными», а мы придём и посмотрим, что у вас получилось. :)
Вы и штаны можете через голову надевать
"Штаны через голову" это как раз ваша логика, когда предлагаете развернуть mesh-сеть с координационным сервером. Мой SSH-туннель это штаны через ноги: просто, тупо и работает. А если у вас есть другой, более "правильный" способ надевать штаны через голову, добро пожаловать в личный блог, пишите свою статью. Посмотрим, сколько пуговиц на вашей рубашке останется после вашего собственного пердолинга.
https://habr.com/ru/articles/1038422/
Видимо это ваш брат-близнец с такой же проблемой и такими же аргументами целесообразности такой схемы
Ох нифига... Нет это не мой брат близнец. Но этот человек комментировал мою статью. Ща поиду читать, спасибо.
exeonid
22.05.2026 12:20Напишите просто свою статью, с «правильными вводными», а мы
Кто "мы"? Пользователи хабра стали вашей личной армией? Я не нуждаюсь в покачивании ЧСВ написанием нейрослопа ради плюсиков.
когда предлагаете развернуть mesh-сеть с координационным сервером
Какая mesh-сеть? Какой координационный сервер? Какая чушь!
Посмотрим, сколько пуговиц на вашей рубашке останется после вашего собственного пердолинга
sudo apt get install netbirdПуговицы какие-то... Посчитайте лучше человеко-часы =)
PS Беседа зашла в тупик. Всего хорошего.
anoldman25
22.05.2026 12:20Я сделал немного по другому.
Сначала у меня стоял home assistant и он был доступен извне через https/mqtts. Однако пришел провайдер и сделал CGNAT. Беда. Пришлось покупать белый адрес.
Но потом я узнал, что существует yggdrasil. Он оперирует адресами IPV6. И он доступен извне без всяких серверов. Я проверил, HA сервер доступен извне с мобильного телефона через yggdrasil без проблем. Датчики я в основном использую zigbee. То есть осталось проверить работоспособность MQTT через yggdrasil при помощи zigbee2mqtt. Но мне лень. Больше нравится лежать на диване 8). Но скоро проверю.
Есть одна проблема. Я пробовал, но не смог установить yggdrasil под HA. То есть я установил его, но не могу указать PEERS в конфигурации. Может это локальная трудность, но все же.
Собственно эту проблему я решил установив HA с помощью IOStack. То есть можно установить полноценный HA на машине с Linux.
Я понимаю, что я написал только тезисы. Но если у кого есть вопросы, спрашивайте. Я постараюсь ответить.
yggdrasil rules!
P.S Добавлю, что наверное эту сеть нельзя использовать на большой скорости с большими объемами, но для медленных типа HA, вполне. Трагедия общин.
AriaQA Автор
22.05.2026 12:20Каждому своё. Yggdrasil это для гиков и энтузиастов, которые любят ковыряться. SSH + VPS-бастион для тех, кому нужно просто, надёжно и чтобы работало.
Tirarex
22.05.2026 12:20просто
Текста на 12 минут в статье, море команд и настроек. Это нифига не просто на фоне решений типа tailscale где все ставится одной командой, а из настроек только логин произвести.
Если хочется что то на своем впс то есть netbird, который все еще ставится в 3 клинка, и имеет очень удобный UI и легкую конфигурацию.
typ6o0jiehb
22.05.2026 12:20Рекомендую поднять radvd (IPvA6 RA сервис) для yggdrasil, и все машины в сети будут получать адрес из 300::/8 сети (с вашей /64 маской полученной из вашего 200::/7 адреса).
Таким образом в локальной сети не требуется установка yggdrasil на каждый хост, я так к видеокамерам получаю линк.
anoldman25
22.05.2026 12:20Роскошная идея! Спасибо хороший человек.
Изучив решение (radvd) подумал, что хорошо наверное поиметь router с OpenWRT, там вроде есть поддержка yggdrasil с radvd. Вопрос для исследования.
Еще раз большое спасибо за идею!
K0Jlya9
22.05.2026 12:20А как ты вынуждаешь камеру взять себе какой то конкретный адрес из /64? radvd вроде не умеет так делать.
Если вручную адрес прописал то radvd не нужен.
anoldman25
22.05.2026 12:20Все работает. Еще раз, спасибо!
Поставлю это на очень старый Rapsberri Pi. Ну очень старый, который с 512MB
hafewix
22.05.2026 12:20Если уже есть VPS с белым ip - зачем пробрасывать порты по ssh, когда можно просто установить VPN?
пинг за NAT
AriaQA Автор
22.05.2026 12:20Статья не про "сделать VPN для дома", а про "выглянуть конкретным сервисом наружу, не светя всю сеть". А вообще, думаю можно и VPN поставить вы открываете доступ ко всей домашней сети. По мне так это не безопасно. Но опять же на вкус и цвет фломастеры разные.:) А вопрос хорошии так то. плюс вам поставлю.
ColdPhoenix
22.05.2026 12:20Фаервол просто существует. Учитывая что проброс портов внутрь VPN все равно делать.
И нет, VPN не открывает вашу локалку для всех извне. Без доп настроек максимум для самой VPS только.
AriaQA Автор
22.05.2026 12:20Смотрите. У меня есть сервер, у меня есть VPS. Мне, конкретно мне, проще использовать SSH-туннели они уже встроены в любую систему и делают ровно то, что мне от них нужно пробрасывают порт и работают. Если вы хотите заморочиться, поднять между ними VPN, настраивать его (а там, я так понимаю, морока ещё та) никто вам не запретит, и всё будет работать. Но для меня, подчёркиваю, конкретно для меня, это слишком сложно. Поэтому я сделала как мне проще. Вот и всё.
hafewix
22.05.2026 12:20выглянуть конкретным сервисом наружу, не светя всю сеть
Наружу выглядывает только порт VPN. Больше никакие сервисы снаружи не палятся. А для не-vpn клиентов на vps-ке можно открыть порт с редиректом на нужный сервис внутри vpn-cети.
lartaet
22.05.2026 12:20До конца не дочитал так как много букв написано, а оно при этом все рушится об отключение провайдерами моб. инета
AriaQA Автор
22.05.2026 12:20Если провайдер режет всё подряд, то проблема не в туториале, а в провайдере. SSH-туннель это просто инструмент. Если ваш VPS недоступен с мобильного интернета, это вопрос к хостингу или оператору, а не к технологии.
3aky
22.05.2026 12:20Спасибо, что корректно отвечаете на разные вопросы - приятно читать. Я правильно понял, что вы рассматриваете случай отсутствия параноидального раутера для домашней сети, или периодические сбрасывания туннеля с автоматическим возобновлением считаются частью решения?
AriaQA Автор
22.05.2026 12:20Спасибо на добром слове. По вашему вопросу: да, периодические сбрасывания туннеля с автоматическим восстановлением это часть решения. связка autossh + systemd заложена в архитектуру. Она гарантирует, что туннель переживет кратковременные падения канала и восстановится без моего участия.
Что касается "параноидального роутера", если я вас правильно поняла, никакого "специального" оборудования не нужно. Решение работает на самом обычном домашнем роутере и самом обычном "домашнем сервере" (у меня старый ноут Acer). Именно в этом и была одна из целей статьи показать, что для надежного доступа не нужны ни дорогие железки, ни белый IP от провайдера. Добавлю, что это простое решение для тех, у кого серый адрес есть VPS и нужно зацепиться к домашнему серверу по разным причинам.
3aky
22.05.2026 12:20“параноидальный роутер” у меня стоит дома - иногда мне кажется, что он нас - кожаных мешков - ненавидит. Он в настройках либо вообще не фильтрует трафик, либо раз в несколько дней сбрасывает длинные сессии. Подозреваю, что баг прошивки, но сделать ничего не могу, а переводить его в режим моста и ставить своё железо потом - жабка мешает.
andreymal
22.05.2026 12:20WireGuard проще и практичнее (и нет, «доступ ко всей домашней сети» он не откроет)
AriaQA Автор
22.05.2026 12:20WireGuard его блокируют. Просвещайтесь. А то я как будто Алиса в королевстве кривых зеркал.
andreymal
22.05.2026 12:20Сами просвещайтесь, в пределах страны никакие VPN не блокируют. Или вы очень часто катаетесь по заграницам?
K0Jlya9
22.05.2026 12:20Что за бастион?
Для того что бы пробросить порт с vps надо установить впн соединение, ваиргардом например, и потом просто пробрасывать порты с помощью фаирвола. SSH тут вообще не нужен.
Barnaby
22.05.2026 12:20ssh тормозной, лучше поднять впн, да тот же xray так умеет. Не понятно зачем поднимать https локально и гонять трафик дважды зашифрованным, когда можно поднять https-прокси прямо на vps и уже оттуда забирать http трафик - там же можно записать реальные ip клиентов в заголовки, у вас как я понял их не видно.
select26
22.05.2026 12:20Согласен, что статья похожа на троллейбусостроение. В 2005 году цены бы ей не было. Но в 2026 году, когда есть Cloudflare Tunnel и ZeroTrust, использование ssh это никому не нужная архаика. Да и нет у вас никакого бастиона: ни WAF, ни DDoS protection, которые идут из коробки в Cloudflare. А еще ssh это медленно и ресурсоемко.
Также в вашем варианте придется изгаляться с разными портами на разных сервисах. А Cloudflare позволяет завернуть на домашний proxmox несколько доменов типа nextcloud.domain.ru, paperless.domain.ru, www.domain.ru и все они будут доступны как по 80, так и по 443 порту.
Ну и плюс еще всякие плюшки, типа дополнительной авторизации по email, SMS, TOTP и т.д. Вот это бастион!Вот тут описано, кому интересно: https://developers.cloudflare.com/tunnel/#how-it-works
Barnaby
22.05.2026 12:20Cloudflare Tunnel
Заблокирован в РФ.
DDoS protection
Кто ваш локалхост ддосить то будет, боже мой. Даже если и будут дешевая впска просто упадет или провайдер вас отключит как проблемного, защитив так сказать :)
Aelliari
22.05.2026 12:20Заблокирован в РФ.
Раз уж vps, то можно ещё в сторону pangolin или последних версий netbird посмотреть. Вполне себе реверс-прокси. Ну и есть чистые реверс-прокси без ничего типа rathole.
Netbird еще в первую очередь и p2p mesh vpn для твоих устройств, реверс-прокси в него затащили относительно недавно
Barnaby
22.05.2026 12:20Какие-то обертки над wg, я так и не понял зачем они тут? Дайте промпт иишке и она вам спокойно два конфига для wg и iptables сгенерит, тут сложно накосячить.
Aelliari
22.05.2026 12:20Дайте промпт иишке и она вам спокойно два конфига для wg и iptables сгенерит, тут сложно накосячить.
Если мне нужен только реверс-прокси, зачем мне полноценный туннель между vps и домашним сервером? Rathole поднимается тоже легко. Доступ с vps к серверу будет ограничен только тем, что я разрешу.
Какие-то обертки над wg
В заголовке заявлялся «бастион», а я вижу туннель через ssh, а вот в этих «обертках» я и окошко аутентификации добавлю, и сертификаты они выпустят сами для любого домена, и геофильтр включу кнопочкой. Почитай что там они могут.
Да и в целом, для задачи автора статьи можно и не открывать сервер в интернет. Клиент netbird проковыряет себе дыру в cgnat до домашнего сервера, или сервер выступит релеем если это не получится. Не хочешь ставить клиент - netbird тоже может быть реверс-прокси.
Кстати, развернуть эти "обертки" на vps тоже просто, если использовать их родные установочные скрипты
P.S. Ты выше забраковал cloudflare tunnel с аргументацией о блокировке, и хотя у меня тоже есть ряд претензий, но не все читатели Хабра живут на территории с установленным ТСПУ. Поэтому я мало того что считаю, что такой подход имеет право на существование, так ещё и предложил альтернативы именно для него
FAT
22.05.2026 12:20То есть, мне надо арендовать VPS за 300-500 р. А зачем? Если провайдеры дают выделеный IP за 50-150р?
typ6o0jiehb
22.05.2026 12:20Белый ip - 300 рублей.
Самая дешёвая vps - 90 рублей.
Но ssh тунели как у автора - плохо.
NikaLapka
22.05.2026 12:20Вроде это уже не первая статья про ssh только за эту неделю. Оставьте хоть что-нибудь остальным для нормальной работы, если ваш влесс заблокировали, то зачем плодить копипастные гайды для масс, чтобы и ssh побыстрее заблокировали.
Между прочим, интересный факт, если посмотреть https://atlas.ripe.net/statistics/coverage то на северо-западе есть не единичные случаи, когда в марте-апреле-мае пробочки вышли в оффлайн, именно как раз с ошибкой 'Controller init -p 443 atlas@ctr-dub-sw02.atlas.prod.ripe.net \ 255 controller INIT exit with error', ssh заблокировали.
daledale
22.05.2026 12:20На всю эту простыню, у меня только один вопрос к автору - слышал ли он о слове из 4-х букв: SSTP?
AriaQA Автор
22.05.2026 12:20сравнивать SSTP и SSH туннель это как предложить сесть в танк, когда тебе нужно просто перевезти пакет с молоком через дорогу. Я и на велике (SSH туннель) доеду. тем более что серевер у меня и так есть, для других нужд, почему бы не использовать его.
daledale
22.05.2026 12:20Скорее всего вы что-то недопоняли или простите, возможно, есть пробелы в знаниях. Действительно сравнивать то, о чём написали вы - неправильно как минимум, что собственно я и не делал. Более того, если у вас серый ip за NAT провайдера (это туда, куда нужно подключиться) - никакой SSH вам не поможет, т.к. вы не сможете подключиться, ибо это технически невозможно*.
- исключая тот случай, разумеется, если изначально коннект будет осуществляться из места, где серый ip за NAT, но это редкий частный случай с множеством нюансов.
3aky
22.05.2026 12:20насколько я понимаю - изюминка решения именно в том, что домашний сервер устанавливает все прописанные туннели с vps сам, и держит их открытыми
SchwarzFuchs
22.05.2026 12:20Зачем это всё, если есть бесплатные эмуляторы локальных сетей? А если надо захостить небольшой общедоступный сайт, то есть бесплатные тарифы у некоторых ngrok-подобных сервисов.
AriaQA Автор
22.05.2026 12:20Мне не надо хостить сайт. Я когда еду домой, мне нужно подключиться к своему серверу. Знаете зачем? Чтобы включить бак с нагревом воды. Потому что у нас в Сибири принято отключать горячую воду когда попало. И мне SSH-туннеля для этого хватает с головой. Не нужно мне городить Xray, два прокси и HTTPS с реальными IP клиентов ради одной кнопки "включить бойлер". Работает и отлично. Про эмуляторы знаю. Особенно какие проблемы с ними в России.
hafewix
22.05.2026 12:20Вот это и нужно объяснить первым же абзацем. И не выдумать громкие названия типа "VPN-бастион".
"SSH-пипка на VPS для включения бойлера" - так звучит понятнее.
paul-k-online
22.05.2026 12:20Но если задача просто достучаться к своему серверу за нет, то намного проще и бесплатно установить тот же netbird на сервер и телефон и ходить там как по локалке. Полезности и безопасности явно больше чем с ssh на vpc.
ArtemSmit
22.05.2026 12:20А вообще как по мне - для домашнего сервера все это оверкилл. Сам пользуюсь белым ip от провайдера и купленным доменным именем чтоб заходить удобнее было. Все сервисы проксируются через NPM, из открытых портов только 80 и 443. Все это защищено fail2ban с геоблоком. Вход практически во все сервисы через 2FA. За более чем 3 года - ни разу проблем небыло. Думаю что в целом в масштабе интернета моя домашняя инфраструктура и фоточки с собакой особой ценности ни для кого не представляют и тратить ресурсы на их DDOS или попытки взлома смысла особо нет. А для задач в духе "включить бак с водой" вообще каких-нибудь KeenDNS или их аналогов от конкурентов хватит (я искренне полагаю что на хабре все же большинство гиков, и нормальный роутер ни у кого не вызывает вопросов в духе "зачем" и "это же дорого").
d3d14
22.05.2026 12:20Запретим вход по паролю для
tunneluserтеатр безопасности
AriaQA Автор
22.05.2026 12:20Ну не думайте о безопасности вообще. Что за странная мысль в 2026 году... кому нужен мой сервер? Почитайте, кому нужен.
d3d14
22.05.2026 12:20Театр - это запрет входа по паролю. В уверенности, что ключи якобы безопаснее.
Почитайте. https://habr.com/ru/companies/ddosguard/news/1037240/Aelliari
22.05.2026 12:20Приведу вам цитату сообщения-ответа для вашего комментария в посте по ссылке
пароль < ssh-ключ < запароленный ssh-ключ
А вообще, это разные векторы атак и они требуют разных способов защиты. С тем же успехом расширение украло бы пароль записанный в открытом виде в скрипте доступном для чтения расширению в vscode. А ключи вообще не обязательно хранить в файловой система
AriaQA Автор
22.05.2026 12:20Я поняла вашу логику. Вы говорите "Если уж GitHub взломали через зараженное расширение VS Code, то ваш ключ на домашнем ноутбуке тоже могут украсть". Спорить не буду ключ действительно можно украсть, если целенаправленно атаковать мой комп.. одно дело, защищаться от целенаправленной атаки уровня supply chain и совсем другое от автоматических сканеров, которые долбятся в порт 22 и перебирают пароли. Я стараюсь хотя бы минимизировать. Но если рассуждать в ключе, что даже ололо таких гигантов ломают, то да, можно плюнуть на безопасность.
d3d14
22.05.2026 12:20Не поняли. Github это всего лишь пример. Безопасность ключа, лежащего в конфиге или в переменной окружения равна безопасности файла "пароль.txt" на рабочем столе. Устойчивость к перебору 10-20 символьного пароля не позволит перебрать его за время физического существования сервера. Вместе с тем, парольный доступ к SSH - это везде поддерживаемый и легко переносимый способ. Он не требует плясок с бубном и перегенерации ключей в разных ОС и для разных клиентов/серверов, потому что сервер поддерживает один формат, Putty подавай другой формат, хостер выдал ключи в третьем формате, да еще и не поддерживает какие-то алгоритмы подписи, считая их "устаревшими". Безопасность должна быть разумной. "Театр безопасности" - это бездумное внедрение каких то аспектов безопасности без надлежащего анализа модели угроз.
AriaQA Автор
22.05.2026 12:20Что-то помойму вы не поняли... вы статью то читали? или проскролили?
Вы утверждаете, что безопасность ключа в файле равна безопасности пароля в файле? Но я настроила разницу в правах доступа. (если вы читали)
Если уплывет пароль: Его смогут использовать из любой точки мира, чтобы войти на на мой VPS под полноценной учетной записью и получить доступ к системе. Пароль дает полный доступ.
Если уплывет ключ: В статье для этого ключа создается изолированный пользователь
tunneluserс оболочкой/usr/sbin/nologin. Этот ключ технически не позволяет выполнять команды на VPS или читать чужие файлы. Блокирует намертво командную строку. Максимум, что сможет сделать укравший ключ это пробросить порт, который и так проброшен.Именно поэтому связка "ключ + nologin" в разы безопаснее обычного пароля. Плюс, отключение паролей (
PasswordAuthentication no) наглухо закрывает VPS от круглосуточного брутфорса ботами. Это не "театр" как вы выразились.d3d14
22.05.2026 12:20наглухо закрывает VPS от круглосуточного брутфорса ботами.
Не закрывает )) Пока открыт порт 22, боты и дальше будут пытаться брутфорсить.
uskovvo
22.05.2026 12:20а почему бы не использовать cloudflare tunnel? Очень хорошо проходит через cgnat. Я купил там же домен, который стоит 7 баксов в год и ваще проблем не знаю.
AriaQA Автор
22.05.2026 12:20Видимо вы не живете в России. сloudflare tunnel в России сейчас то открыт, то закрыт по звонку сверху. Формально он работает, технически решение отличное, но с июня 2025 года российские провайдеры по указанию РКН начали массово замедлять и ограничивать трафик к серверам Cloudflare. Желания проверять, насколько там все плохо, у меня нет.
15432
Есть ощущение, что подключить белый IP у провайдера будет дешевле, чем 300-500 рублей за VPS
jaker
180 р Ростелеком
AriaQA Автор
У меня есть VPS, есть потребности, я описываю как я их реализую. В частности случай, когда нет белого IP. Статья будет интересна тем, у кого уже есть VPS и кто озадачился похожими вопросами. В статье я прямо указываю: из платного нужен только VPS. Вот статья тоже там VPS, но это вообще не про IP. https://habr.com/ru/articles/1033472/
Igapu
150 р Ростелеком
AriaQA Автор
У меня нет белого IP, и покупать его отдельно я не хочу. если можно заплатить на 50–100 рублей больше и получить полноценный сервер? На нём и IP работать будет, и пет-проекты можно тестировать, и домашний сервер с данными остаётся в безопасности. Так что кому арбуз, а кому свиной хрящик. Если вы выбрали платить за белый IP у провайдера этот туториал вам ни к чему. :)
g3falsht
А DDNS системы? Почему их не рассматриваете тогда? Можно и в связке с КВН туннелем
AriaQA Автор
DDNS решает проблему динамического белого IP, а не серого. Все попытки достучаться извне через DDNS разобьются о NAT провайдера. У меня так то серый адрес. И я вообще не люблю ничего усложнять. Поэтому выбрала самый простой "дедовский" способ. Я не обзор делаю, я просто решаю свою проблему.
gaussssss
Только вот в реальности часто говорят "такая услуга не предоставляется" и всё
Mixael_sas
Зависит от провайдера. У меня Ростелеком и белый IP.
kukovik
для такой задачи и сторублевого хватит, если еще где можно найти. ну всяко не 300.
RulenBagdasis
У меня был серверок за 210р в Beget, с апреля оказалось что этот дохлый сервачок уже 480р в месяц стоит. При том, что буржуины более мощный инстанс за $3 дают, а тут получается в 2 раза дороже за сервер, который раз в 10 хуже.
И за домен Beget денег в 4 раза больше брал, чем Cloudflare.
Как-то я разочаровался в российских сервисах, в общем…
flowwolf
Есть причина, по которой их сервис остаётся довольно популярен.
RulenBagdasis
Что за причина? Мосэнергосбыт на фиг шлёт пи попытке с их ip зайти )))
LM-ML
держал сайт на разных хостах и РФ и на зарубежных. да, Beget дороговат но самое главное отличие от других хостеров, лично для меня (речь именно о тех на которых я был) что поддержка там реально на высоте. практически любые вопросы решают ЗА тебя, даже те, которые по идее они не обязаны решать. на самое главное это то, что если ты превышаешь лимит по нагрузке, они НИКОГДА не блочат (в смысле доступ к сайту всегда есть) твой сайт а на ВСЕХ других которых я был как только превышалась нагрузка, сайт СРАЗУ становился не доступен. и ВСЕ кроме Бегет хостеры отвечали просто "перейдите на другой тариф" а другой тариф сами понимаете это тариф подороже имеется ввиду. конечно всю жизнь так сказать никто не будет разрешать превышать лимиты, но в тот раз почти месяц (и если честно превышения лимитов у меня еще были, не один раз) меня ддосили и нагрузка на 100%+++ превышала лимит. по итогу они и с ддосом помогли (я сам вообще нихрена в подобных вопросах не понимаю) и даже не заикнулись чтобы я на другой тариф подороже перешел.
riky
Вы описали разницу в типе виртуализации kvm vs openvz
Stanislavvv
Иногда "нет технической возможности" ©
flowwolf
Предположу, что вы не знакомы с расценками на публичные адреса у опсосов. А автор сильно преувеличивает доступность рандомного VPS в реалиях белых списков.
Andrei2025
Да. у них очень дорого, но есть альтернативи, к примеру Contabo, около 4 евро с такой конфигурацией: Description: Cloud VPS 10 SSD (no setup)Disk Space: 150 GBCPU cores: 4RAM: 8 GB
Andrei2025
Проще и самое быстрое решение пробросить туннельт через Cloudflare и DNS, не нужно никаких отдельных VPS в этом случае
vsnikolaev
Инструкцию, пожалуйста!)
Andrei2025
как минимум, у Вас должен быть аккуант в Cloudflare, без него никакая инструкция не поможет и обязательное условие DNS записи вашего домена, там же. А, так вот sudo mkdir -p --mode=0755 /usr/share/keyrings curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null echo “deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main” | sudo tee /etc/apt/sources.list.d/cloudflared.list sudo apt-get update && sudo apt-get install cloudflared , потом авторизуете тунель и все
Mixael_sas
А в РФ будет работать тоннель Cloudflare?
AriaQA Автор
нет.
Andrei2025
Почему нет, работает
AriaQA Автор
Работает? правда? сходила к ним.. https://blog.cloudflare.com/russian-internet-users-are-unable-to-access-the-open-internet/
Kenya-West
https://cheburcheck.ru/check?target=cloudflare.com
Andrei2025
попробуйте
sudo apt update && sudo apt install -y curl ca-certificates &&
sudo mkdir -p --mode=0755 /usr/share/keyrings &&
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null &&
echo ‘deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main’ | sudo tee /etc/apt/sources.list.d/cloudflared.list &&
sudo apt update && sudo apt install -y cloudflared &&
cloudflared tunnel --hello-world
lartaet
Не собираюсь никого продвигать, но пока еще вариантов за +-170 на Ру локации вариантов не мало, не жирных само собой, но будет достаточно
shaev
900 р UTEX Москва в доме где кроме только МТС