Проброс порта Natter пытается поддерживать NAT-сопоставление и передавать соединение локальной службе. Публичный адрес из STUN ещё не доказывает доступ разрешённого внешнего клиента к аутентифицированной службе. Здесь используются Ubuntu 24.04 LTS x64, Python 3.12, Natter 2.2.1 и один TCP-узел; полного авторского испытания на реальной сети не проводилось.

Ключевые выводы

Проверяйте только разрешённые сеть, службу и собственный внешний клиент.

Публикуйте фиксированный нечувствительный ответ с взаимным TLS, не интерфейс управления.

Сохраняйте правило для одного источника и проверку сертификатов.

Останавливайте службу и отзывайте доступ: прекращение keepalive не стирает NAT-состояние мгновенно.

Что доказывает проброс порта Natter?

STUN сообщает адреса, которые наблюдает сервер. Сопоставление и фильтрация — отдельные свойства и могут различаться в зависимости от назначения и сети; RFC 8489 не гарантирует универсальный входящий доступ или совместимость с CGNAT.［3］

Определите доступ и очистку по плану ответственности за собственную сеть. Объяснение общего публичного адреса и диагностика домашнего NAT помогают понять предпосылки, но не подтверждают доступность.

Для исходящей приватности сравните выход VPN с входящим пробросом; публикация службы добавляет другую ответственность. Эта лаборатория не дает гарантии обхода, статистики успеха у провайдеров или сканирования чужих устройств.

Общий обзор VPN объясняет исходящий доступ, а не доступность этого endpoint.

Каковы требования NAT для Natter и условия восстановления?

Нужны выделенный Ubuntu-хост в LAN и отдельный разрешённый клиент в другой сети. Зарезервируйте 192.168.50.10, TCP 58961 для Natter и loopback TLS 8443; реальный LAN-адрес замените везде. Запишите маршруты, IPv4/IPv6, слушатели, правила и публичный источник внешнего клиента.

Сохраните проверенный канал управления, независимый от проброса. Пример требует уже активной UFW-политики владельца с запретом непрошеного входящего трафика, без конкурирующего менеджера правил. Не включайте UFW вслепую через SSH, не очищайте правила, не отключайте защиту и не меняйте производственный NGINX. Если базовых условий нет, подготовьте выделенный хост и остановите эту попытку.

Нужны допустимые TCP STUN/keepalive и совместимое поведение NAT. Несколько уровней NAT и зависимость от назначения могут блокировать внешний доступ. Частный WAN-адрес маршрутизатора — подсказка, а не доказательство всей топологии провайдера. Не исправляйте отказ DMZ, UPnP или публикацией NAS, RDP и базы данных.

Шаг 1: Подготовьте краткоживущую службу с аутентификацией TLS

Используйте свежий выделенный хост без установленного NGINX, его конфигурации, службы и маски; иначе остановитесь. Пакет Ubuntu обычно запускает сайт по умолчанию. Сначала заблокируйте запуск новой службы маской, затем установите пакеты из доверенных репозиториев. Запишите добавленные пакеты и версии.［8］［9］

sudo systemctl mask nginx.service
sudo apt update
sudo apt install nginx openssl curl python3
systemctl is-enabled nginx.service
systemctl is-active nginx.service
ss -ltnp 'sport = :80 or sport = :8443 or sport = :58961'
readlink /etc/nginx/sites-enabled/default

Ожидаются masked и inactive (эти команды состояния возвращают ненулевой код). Все перечисленные порты должны быть свободны. При ошибке установки или запуске NGINX остановитесь и выполните очистку. Только если readlink показывает созданную этой установкой ссылку на /etc/nginx/sites-available/default, удалите её командой sudo unlink /etc/nginx/sites-enabled/default; иначе остановитесь. Не удаляйте файлы другого сайта.

Через ip route get 127.0.0.2 подтвердите локальный маршрут loopback. TLS использует 127.0.0.2: Natter 2.2.1 заменяет точную цель 127.0.0.1 своим LAN-адресом. Цель и слушатель должны совпадать.［7］ Следующие команды создают закрытый CA на два дня и временные сертификаты.［5］［6］

mkdir -m 700 "$HOME/natter-lab"
cd "$HOME/natter-lab"
umask 077
openssl req -x509 -newkey rsa:3072 -nodes -days 2 -keyout ca.key -out ca.crt -subj '/CN=Natter Lab CA'
openssl req -new -newkey rsa:3072 -nodes -keyout server.key -out server.csr -subj '/CN=natter-lab.example'
printf 'subjectAltName=DNS:natter-lab.example\nextendedKeyUsage=serverAuth\n' > server.ext
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 2 -extfile server.ext -out server.crt
openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj '/CN=Owned external client'
printf 'extendedKeyUsage=clientAuth\n' > client.ext
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAserial ca.srl -days 2 -extfile client.ext -out client.crt
sudo install -d -m 700 /etc/nginx/natter-lab
sudo install -m 600 server.key /etc/nginx/natter-lab/server.key
sudo install -m 644 server.crt ca.crt /etc/nginx/natter-lab/

ca.key остаётся на закрытом хосте оператора, не передаётся клиенту. Через существующий аутентифицированный канал скопируйте внешнему клиенту только ca.crt, client.crt, client.key. Сохраните ограниченные права ключа; приватным ключам не место в статье и общей папке.

Через sudoedit сохраните ниже /etc/nginx/conf.d/natter-lab.conf. Добавляется только loopback-слушатель, обязательный сертификат этого CA и фиксированный ответ /check. Не используйте CA, который уже доверяет сертификатам других пользователей.［4］

server {
    listen 127.0.0.2:8443 ssl;
    server_name natter-lab.example;
    ssl_certificate /etc/nginx/natter-lab/server.crt;
    ssl_certificate_key /etc/nginx/natter-lab/server.key;
    ssl_client_certificate /etc/nginx/natter-lab/ca.crt;
    ssl_verify_client on;
    ssl_protocols TLSv1.2 TLSv1.3;
    access_log off;
    location = /check { return 200 "natter-lab-ok\n"; }
    location / { return 404; }
}

До снятия маски изучите весь вывод nginx -T: единственный слушатель — 127.0.0.2:8443 ssl, без сайта по умолчанию и IPv6. При несовпадении остановитесь. Проверьте конфигурацию, снимите маску, отключите автозапуск и запустите вручную; подтвердите слушатель через ss. Первый локальный запрос должен дать фиксированный ответ, запрос без сертификата — не должен. Это ожидаемые проверки, не авторские наблюдения.

sudo nginx -T
sudo nginx -t
sudo systemctl unmask nginx.service
sudo systemctl disable nginx.service
sudo systemctl start nginx.service
ss -ltnp 'sport = :80 or sport = :8443 or sport = :58961'
curl --noproxy '*' --cacert ca.crt --cert client.crt --key client.key --resolve natter-lab.example:8443:127.0.0.2 https://natter-lab.example:8443/check
curl --noproxy '*' --cacert ca.crt --resolve natter-lab.example:8443:127.0.0.2 https://natter-lab.example:8443/check

При отказе примените очистку из шага 4 к уже созданным ресурсам; если маска ещё действует, снимите только маску этой лаборатории через sudo systemctl unmask nginx.service. Сохраняйте срок сертификатов и проверку имени; не используйте curl -k.

Шаг 2: Проверка Natter через STUN с минимальными правами

Скачайте официальный сценарий 2.2.1 в закрытый каталог и изучите его. Запускайте обычным пользователем; управление конфигурацией и брандмауэром требует повышения прав.［1］［2］

В этой версии -i выбирает адрес STUN/keepalive, но socket-пересылка слушает все IPv4-адреса. Это не гарантия привязки входящего слушателя. До запуска изучите sudo ufw status verbose и sudo ufw show raw: требуются запрет входящего трафика по умолчанию на всех интерфейсах и отсутствие широкого допуска к 58961. Иначе остановитесь. Замените OWNED_CLIENT_PUBLIC_IP собственным внешним источником, видимым хосту; разрешите только его и зарезервированный LAN-адрес назначения.［7］

curl --fail --location --proto '=https' --proto-redir '=https' -o natter.py https://github.com/MikeWang000000/Natter/releases/download/2.2.1/natter.py
python3 natter.py --version
sudo ufw allow in proto tcp from OWNED_CLIENT_PUBLIC_IP to 192.168.50.10 port 58961 comment 'natter-lab'
python3 natter.py -i 192.168.50.10 -b 58961 -m socket -t 127.0.0.2 -p 8443 -q

Во втором терминале проверьте ss -ltnp 'sport = :8443 or sport = :58961': ожидаются NGINX на 127.0.0.2:8443 и Natter на 0.0.0.0:58961. Брандмауэр должен ограничивать последний одним разрешённым источником и адресом назначения. Не добавляйте IPv6 и ручной проброс маршрутизатора.

-m socket передаёт соединение loopback TLS без установки NAT-правил; -q завершает сеанс при смене отображаемого адреса. Здесь нет -U, демона, цикла повторов, скрипта уведомления и автозапуска. Natter всё равно обращается к своим STUN/keepalive-узлам; используйте только разрешённые сервисы, при запрете политики остановитесь.

Закрыто запишите публичные IP и порт. Внешний порт не обязан быть 58961. Встроенный тест Natter может не пройти из-за намеренного допуска только вашего источника; решающим будет следующий аутентифицированный запрос от него, а не открытие брандмауэра ради автоматической проверки.

Шаг 3: Проверьте собственным внешним клиентом

Используйте клиент в отдельной сети с всё ещё разрешённым публичным источником и закрытыми учётными данными. Hairpin-запросы из той же LAN не подтверждают внешнюю доступность.

Замените PUBLIC_IP и оба вхождения PUBLIC_PORT текущим сопоставлением. --resolve сохраняет TLS-имя natter-lab.example без правок DNS или hosts. --noproxy '*' действует только на этот запрос и не меняет существующую настройку прокси или VPN.

curl --noproxy '*' --connect-timeout 10 --max-time 20 --cacert ca.crt --cert client.crt --key client.key --resolve natter-lab.example:PUBLIC_PORT:PUBLIC_IP https://natter-lab.example:PUBLIC_PORT/check
curl --noproxy '*' --connect-timeout 10 --max-time 20 --cacert ca.crt --resolve natter-lab.example:PUBLIC_PORT:PUBLIC_IP https://natter-lab.example:PUBLIC_PORT/check

Требуйте фиксированный текст при аутентификации и отказ без клиентского сертификата. Проверяйте HTTP-статус и тело ответа: curl может завершиться успешно при HTTP-отказе. Неверный CA или имя вне сертификата должны приводить к отказу проверки идентичности; никогда не отключайте TLS-проверку.

Как трактовать отказы и изменение сопоставления?

Наблюдение читателя	Допустимый вывод	Следующее действие
STUN не сообщает пригодного адреса	Этот STUN-путь недоступен	Проверить разрешённый egress, остановиться при неустранённом сбое
Адрес есть, внешний TCP ждёт тайм-аут	Доступность не установлена	Проверить источник, фильтрацию и уровни NAT
TCP работает, TLS-идентичность не подтверждается	Нужная служба не идентифицирована	Проверить SAN, CA, адрес и срок, не отключать проверку
Оба запроса получают ответ, даже без сертификата	Контроль доступа неверен	Остановить Natter и исправить обязательный клиентский сертификат
Адрес меняется, Natter завершается	Сохранённый endpoint устарел	Проверить сеть и лишь затем вручную перезапустить

Не превращайте отказ в успех: тип NAT нельзя публиковать как удачный результат, если служба не ответила. Адресная информация STUN в браузере отличается от аутентифицированного входящего доступа; ни одно наблюдение не доказывает другое.

Здесь только IPv4-слушатель. Независимая публикация другой службы через IPv6 требует собственной проверки; лаборатория не защищает сеть хоста целиком. Сохраняйте существующую защиту и исследуйте только свои ресурсы.

Шаг 4: Остановите, отзовите доступ и проверьте очистку

Нажмите Ctrl+C в терминале, где Natter работает на переднем плане. Удалите только его правило источника, остановите и отключите новый NGINX, удалите лабораторную конфигурацию и учётные данные. Перечисленных слушателей оставаться не должно:

sudo ufw delete allow in proto tcp from OWNED_CLIENT_PUBLIC_IP to 192.168.50.10 port 58961
sudo systemctl disable --now nginx.service
sudo rm /etc/nginx/conf.d/natter-lab.conf
sudo rm /etc/nginx/natter-lab/server.key /etc/nginx/natter-lab/server.crt /etc/nginx/natter-lab/ca.crt
sudo rmdir /etc/nginx/natter-lab
ss -ltnp 'sport = :80 or sport = :8443 or sport = :58961'

Сопоставления могут сохраняться после остановки keepalive. После удаления слушателей и служб повторите аутентифицированный внешний запрос к последнему сопоставлению: лабораторного ответа быть не должно. Тайм-аут или отказ соединения подтверждает недоступность endpoint, но не мгновенное удаление состояния маршрутизатора.

Удалите временные учётные данные на обеих машинах, восстановите только лабораторные изменения и проверьте управление. Сайт по умолчанию оставьте отключённым. Удаляйте только записанные новые пакеты без других пользователей; не запускайте общий autoremove. Если подготовка осталась под маской, остановите новую службу, прежде чем снимать её лабораторную маску. Удаление лабораторного CA и службы не затрагивает посторонние сертификаты.

Перед обновлением сохраните предыдущий сценарий, вызов без секретов, закрытую резервную копию конфигурации и исходное состояние. Повторите проверки успеха, отказа, смены адреса и очистки; не добавляйте бесконечные автоматические повторы.

Итоги

Разделяйте адрес STUN и аутентифицированную внешнюю доступность.
Ограничьте безвредный endpoint сертификатом и одним источником.
Несовместимый NAT и ошибки идентичности — основания остановки.
Удалите слушатель, службу, правило и секреты, затем проверьте внешний отказ.

Часто задаваемые вопросы (FAQ)

Означает ли STUN-адрес доступность порта?

Адрес описывает наблюдение STUN-сервера. Фильтрация и особенности сопоставления могут по-прежнему блокировать доступ нужного внешнего клиента.

Всегда ли Natter проходит через CGNAT?

Из одного обозначения CGNAT универсальный результат не следует. Нужны совместимые сопоставление и фильтрация, разрешённый трафик и реальная внешняя проверка службы.

Зачем взаимный TLS для безвредного ответа?

Фиксированный ответ ограничивает раскрываемые данные, а клиентский сертификат — получателей. Обе границы полезны при проверке интернет-доступного слушателя.

Заменяет ли локальная проверка внешний клиент?

Локальный запрос проверяет службу и обязательность аутентификации. Только клиент из отдельной сети подтверждает заявленную внешнюю доступность.

Почему встроенный тест Natter может не пройти?

Здесь разрешён один собственный внешний источник. Автоматический проверяющий вне этого ограничения может блокироваться даже при успешном запросе вашего клиента.

Исчезает ли сопоставление сразу после остановки?

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

Можно ли вместо этого открыть управление NAS?

Здесь допускается лишь краткоживущий TLS-узел с фиксированным ответом. Интерфейс управления имеет другие риски и разрешения и выходит за рамки лаборатории.

Отказ от ответственности: Работайте только с разрешённой инфраструктурой и сетями. Результаты описаны как ожидаемые проверки, а не измерения автора или статистика успешности у провайдеров.

Источники:

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Проброс порта Natter: безопасная проверка через STUN