Comments 14
Как я понимаю uPNP не будет работать за двумя роутерами?
В частности
ПК IP 192.168.1.100 шлюз 192.168.1.1
Домашний роутер 192.168.1.1, WAN PPPoE IP 10.7.6.2 шлюз 10.7.6.2, uPNP включен, порт 22333 в списке проброшеных виден
Внешний IP 80.90.110.190 (изменен)
Маршрут до 8.8.8.8
1 192.168.1.1
2 80.90.110.190
Снаружи 80.90.110.190:22333 — недоступен
Как я думаю 80.90.110.190 это роутер провайдера там или uPNP не работает или uPNP не работает через 2 роутера.
В частности
ПК IP 192.168.1.100 шлюз 192.168.1.1
Домашний роутер 192.168.1.1, WAN PPPoE IP 10.7.6.2 шлюз 10.7.6.2, uPNP включен, порт 22333 в списке проброшеных виден
Внешний IP 80.90.110.190 (изменен)
Маршрут до 8.8.8.8
1 192.168.1.1
2 80.90.110.190
Снаружи 80.90.110.190:22333 — недоступен
Как я думаю 80.90.110.190 это роутер провайдера там или uPNP не работает или uPNP не работает через 2 роутера.
Мультикаст по умолчанию, грубо говоря, работает в пределах одного Broadcast-сегмента, так что если ваш маршрутизатор не ретранслирует мультикаст до провайдера, то не заработает.
Оборудование уровня Enterprise/ISP как правило не поддерживает UPnP, поэтому вам вряд ли удастся повлиять на маршрутизатор провайдера при помощи описанных в статье протоколов.
Вот, вопрос в тему:
Есть 2 скрипта на питоне, которые гоняют данные через сеть (по tcp или udp — не важно, можно переписать).
Работают они на машинах, каждая из которых за 2 натами (провайдер+роутер), либо одна за 2мя, а вторая за одним (usb-свисток).
За всё время существования проекта перепробовал тучи разных примочек — от ipv6 туннеля и openvpn-на-vps до специализированных сервисов вроде ngrok, но хотелось бы реализовать прямую передачу без костылей с прогоном трафика через сервер.
Кто нибудь может расписать, как сделать udp hole punching «для чайников»? (или что мне подойдёт лучше всего)
Есть 2 скрипта на питоне, которые гоняют данные через сеть (по tcp или udp — не важно, можно переписать).
Работают они на машинах, каждая из которых за 2 натами (провайдер+роутер), либо одна за 2мя, а вторая за одним (usb-свисток).
За всё время существования проекта перепробовал тучи разных примочек — от ipv6 туннеля и openvpn-на-vps до специализированных сервисов вроде ngrok, но хотелось бы реализовать прямую передачу без костылей с прогоном трафика через сервер.
Кто нибудь может расписать, как сделать udp hole punching «для чайников»? (или что мне подойдёт лучше всего)
Наличие сервера (т.е. того, кто слушает порт) обычно предполагает наличие реального IP. Если у вас обе стороны коммуникации находятся за провайдерским натом, причем оба провайдера разные, причем оба не предоставляют сервисов по пробросу портов (либо получению реального IP), то мне сложно представить, как можно организовать их коммуникацию без участия 3 стороны.
Как уже выше обозначили, если 2 компьютера находятся за NAT-ом, то для прямого соединения необходима третья сторона. Не обязательно, чтобы это был ваш выделенный сервер. Достаточно любого IM, например xmpp. Задача: доставить каждой из машин данные для подключения, т.е. IP (белый который NAT, и порт).
Но надо иметь ввиду, что не каждый NAT позволяет провести UDP hole punch. Не стоит его рассматривать как гарантированный канал.
Можно попробовать соединиться с помощью примера icedemo из комплекта PJSIP. После этого понять стоит ли в эту строну копать или нет.
Интересный вариант: организовать канал через toxcore, но в случае с Tox децентрализация дает о себе знать — соединение происходит не мгновенно.
Есть аналог hamachi — ZeroTier, можно глянуть в его сторону, но он, вроде, в альфе еще.
Но надо иметь ввиду, что не каждый NAT позволяет провести UDP hole punch. Не стоит его рассматривать как гарантированный канал.
Можно попробовать соединиться с помощью примера icedemo из комплекта PJSIP. После этого понять стоит ли в эту строну копать или нет.
Интересный вариант: организовать канал через toxcore, но в случае с Tox децентрализация дает о себе знать — соединение происходит не мгновенно.
Есть аналог hamachi — ZeroTier, можно глянуть в его сторону, но он, вроде, в альфе еще.
На своём маршрутизаторе отключил NAT-PMP на всякий случай после того, как в его реализации на многих роутерах нашли уязвимость, позволяющую злоумышленнику перехватывать весь трафик.
На работе торрент-клиентов это, вроде, не сказалось, тот же uTorrent нормально пробрасывает порт при включенном UPnP, но без NAT-PMP.
На работе торрент-клиентов это, вроде, не сказалось, тот же uTorrent нормально пробрасывает порт при включенном UPnP, но без NAT-PMP.
Ссылка: https://www.opennet.ru/opennews/art.shtml?num=40922
(с премодерируемых аккаунтов нельзя вставлять ссылки в первом комментарии, поэтому так)
(с премодерируемых аккаунтов нельзя вставлять ссылки в первом комментарии, поэтому так)
до того, как запросить создание трансляции, Vuze заставил маршрутизатор перечислить все имеющиеся Port Forwarding'и. Для чего это было сделано, я могу лишь догадываться
Могу предположить, это для того, чтобы не создавать уже существующий (не закрытый ранее — например, из-за грохнувшегося приложения) проброс. Тут, правда, возникает вопрос — что лучше, пытаться повторно использовать потенциально чужой проброс или захламлять маршрутизатор всё новыми пробросами.
Могу предположить, это для того, чтобы не создавать уже существующий (не закрытый ранее — например, из-за грохнувшегося приложения) проброс. Тут, правда, возникает вопрос — что лучше, пытаться повторно использовать потенциально чужой проброс или захламлять маршрутизатор всё новыми пробросами.
Прошу прощение за возможно идиотский вопрос — на cisco (ASA и первое поколение роутеров) вообще никак? Попадались мне какие-то tcl-костыли, но не осилил. Может кто знает правильный путь?
Где-то на форумах циски встречался фидбэк от инженера — «несекурно, этого у нас не будет никогда».
Правильный путь — руками прописать статический port-forward, и на торент-клиенте не использовать случайный порт)
Правильный путь — руками прописать статический port-forward, и на торент-клиенте не использовать случайный порт)
Зато Juniper сделал поддержку PCP.
Sign up to leave a comment.
Открываем порты за NAT при помощи NAT-PMP и UPnP IGD