Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Здравствуйте, Qulac, Вы писали:
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Не смогут. За устройством с NAT может быть сто таких серверов. Откуда устройство с NAT поймёт, на какой именно внутренний адрес надо перенаправлять входящие пакеты? Если настроишь port mapping, то без проблем. Есть способы пробивать NAT, но они не всегда надёжные.
Здравствуйте, Qulac, Вы писали:
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Клиенты не смогут подключиться. Клиент отправляет запрос на подключение к адресу "внешний", порту 5000.
Хост с адресом "внешний" получает этот пакет и отвергает его, потому что на хосте "внешний" никто не слушает порт 5000
Порт 5000 слушает хост с адресом "внутренний", находящийся за NAT
Чтобы подобные запросы , полученные хостом "внешний" уходили на хост "внутренний", нужно на "внешнем" настроить трансляцию порта с адреса "внешний":5000 на "внутренний":5000. Это типичный путь.
Есть еще нетипичный путь, в общем случае называющийся "пробивание NAT", который обычно используется программами вроде торрент-клиентов, скайпа, софтовых телефонов и прочего p2p. Пробив делается множеством способов, партизанских и нет, с помощью UPnP, STUN и TURN, вши красной, вши жолтой, усениц, мышек, крысок и иных тварей. Надеюсь, когда-нибудь внедрение IPv6 прикончит всё это безобразие.
Здравствуйте, vsb, Вы писали:
С>>Надеюсь, когда-нибудь внедрение IPv6 прикончит всё это безобразие. vsb>Чтобы не ухудшать безопасность в сравнение с NAT, любой адекватный IPv6 роутер, имхо, будет блокировать все входящие подключения на компьютеры, которые за ним. Каким образом тут поможет IPv6? Так же, либо лезть в веб-интерфейс роутера и разрешать входящие подключения на такой-то адрес с таким-то портом, либо такими же хаками пробивать дырку в фаерволе.
Да, отучить Ватсона от трубки будет сложно. Но я думаю, что добрым словом, а также дубинкой и пистолетом, фашизмом и железной палкой удастся:
1) Отучить администраторов тупо запрещать всё то, что не их ума дело, как оно и было во времена до NAT.
2) Научить администраторов гибко настраивать роутеры, прилагая к тому время и силы, как оно и было во времена до NAT.
3) Заставить работодателей этих администраторов платить оным администраторам нормальную зарплату, не требуя обслуживать сразу 5000 хостов в рамках экономии, консолидации, девопса и кроилова — директору на новый мерс. Чтобы у администраторов было время и силы на нормальную настройку, за те же, а то и бОльшие деньги. Как оно и было во времена до NAT, когда программист, знающий три слова на Си, за год зарабатывал на квартиру в Москве.
Это плохая идея, посылать пакеты веером сразу на 1000 портов. У NAT'ов вполне конечный размер таблиц, и когда таблица переполняется, может быть все, что угодно — вплоть до зависания роутера. Роутеры "за 50 баксов из ближайшего компьютерного супермаркета" особенно этим страдают, а большинство роутеров именно такие.
Здравствуйте, Qulac, Вы писали:
Q>Да ни чего особенного, соединить один ком с другим через интернет. Проблема в том, что у меня только один комп для тестирования, в этом случае мне лучше положиться на какую ни будь библиотеку или использовать стандартные настройки для этого. Вот не знаю, вот эта настройка решит мои проблемы или нет?
Сетевый проблемы лучше решать отдельно от кода приложения.
Если нельзя настроить port mapping на входящем раутере, то лучше решать кардинально по-другому.
Конкретно, для надежной связи желательно настроить NAT-free внутреннюю VPN сеть. Это исходящее VPN от PC за NAT (любого их количества) и внешний сервер, который держит VPN сервер и обеспечивает routing.
Это называется hub & spoke, hub это центральный VPS, spoke — это клиенты
Здравствуйте, Qulac, Вы писали:
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Читайте про port mapping, его нужно настроить на устройстве, осуществляющем трансляцию сетевых адресов (nat).
Здравствуйте, sn175, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
S>Читайте про port mapping, его нужно настроить на устройстве, осуществляющем трансляцию сетевых адресов (nat).
Т.е. в моём примере клиенты не смогут подключиться?
Здравствуйте, Слава, Вы писали:
С>Надеюсь, когда-нибудь внедрение IPv6 прикончит всё это безобразие.
Чтобы не ухудшать безопасность в сравнение с NAT, любой адекватный IPv6 роутер, имхо, будет блокировать все входящие подключения на компьютеры, которые за ним. Каким образом тут поможет IPv6? Так же, либо лезть в веб-интерфейс роутера и разрешать входящие подключения на такой-то адрес с таким-то портом, либо такими же хаками пробивать дырку в фаерволе.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Qulac, Вы писали:
Q>>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
vsb>Не смогут. За устройством с NAT может быть сто таких серверов. Откуда устройство с NAT поймёт, на какой именно внутренний адрес надо перенаправлять входящие пакеты? Если настроишь port mapping, то без проблем. Есть способы пробивать NAT, но они не всегда надёжные.
Здравствуйте, Qulac, Вы писали:
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Разместите свой сервис в сети tor и не заморачивайтесь https://blackarch.ru/?p=749
Здравствуйте, Qulac, Вы писали:
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
И основная проблема не в том, что подключающийся клиент тоже может быть за NAT'ом, да и NAT'ы бывают разных типов — некоторые из которых являются несовместимыми комбинациями.
Например, вот что имеет место быть если сервер и клиент оба за «симметричными» сцылка, а ведь могут быть и за «конусами».
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Здравствуйте, Qulac, Вы писали:
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Опиши, что за проблему тебе надо решить?
Здравствуйте, vsb, Вы писали:
vsb> С>Надеюсь, когда-нибудь внедрение IPv6 прикончит всё это безобразие. vsb> Чтобы не ухудшать безопасность в сравнение с NAT,
NAT не должен использоваться рядом со словом "безопасность".
vsb> любой адекватный IPv6 роутер, имхо, будет блокировать все входящие подключения на компьютеры, которые за ним.
Все больший уход в мобильность (ноутбуки, планшеты, телефоны) снижает значимость фаервола на домашнем роутере и необходимость его настройки — поскольку в процессе своей мобильности ты подключаешься к разным недоверенным источникам, то и домашний WiFi так же можно будет считать недоверенным для упрощения. Дополнительно, после пары неудачных попыток подключения к домашнему телевизору / пылесосу / холодильнику / etc (а подобные устройства получают все большее распространение), среднестатистический пользователь просто выключит фаервол на роутере.
P.S. К сожалению из за "законов Яровой" распространение IPv6 в РФ приостановилось (а где-то даже откатилось), но на горизонте лет в 10 (максимум) это все равно уже неизбежность.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Qulac, Вы писали:
Q>>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет? K>Опиши, что за проблему тебе надо решить?
Да ни чего особенного, соединить один ком с другим через интернет. Проблема в том, что у меня только один комп для тестирования, в этом случае мне лучше положиться на какую ни будь библиотеку или использовать стандартные настройки для этого. Вот не знаю, вот эта настройка решит мои проблемы или нет?
Здравствуйте, a7d3, Вы писали:
A>Например, вот что имеет место быть если сервер и клиент оба за «симметричными» сцылка, а ведь могут быть и за «конусами».
Реализации алгоритма на данный момент не существует, то есть все рассуждения в статье — чисто теоретические, надеюсь, однако, что из-за этого не менее корректные.
ваши ссылки застарели
технологию обхода симметричного нат придумали еще так в году 2008 два япошки
техника называется UDP multihole punching
но внешний сервер аля stun(только не совсем стюн) нужен, а для надежности нужен еще и второй внешний
что бы порт предикшин работал лучше и не лажал
потом два хоста пробивают дырочки и общаются через симметричные наты напрямую
пробиваемость около 99% если порт предикшин не сильно рандомный
Здравствуйте, wildwind, Вы писали:
w> AB>NAT не должен использоваться рядом со словом "безопасность". w> Поясни, пожалуйста, что имеется в виду?
NAT — технология преобразования сетевых адресов используемая в качестве хака при недостатке IPv4 адресов. Больше она ни для чего не предназначена и не задумывалась (не является фаерволом, не скрывает внутреннее устройство сети от злоумышленника, и т.д.). Т.е. к обеспечению безопасности отношения не имеет. Это если коротко. Развернуто можно погуглить материалы типа "Why NAT has nothing to do with Security!" (это первое что встретилось) и им подобные.
Здравствуйте, reversecode, Вы писали:
R>ваши ссылки застарели R>технологию обхода симметричного нат придумали еще так в году 2008 два япошки
Я это умел в 2005-м, а Hamachi (это не фамилия человека, а название программы) еще и раньше того. Только мы статей не писали
R>пробиваемость около 99% если порт предикшин не сильно рандомный
Пробиваемость между двумя произвольно выбранными компутерами в интернете — 95-97, если верить ребятам из Hamachi; у них достаточно большая выборка. Сейчас, наверное, чушь лучше, по причине вымирания роутеров с симметричным натом.
R>ну отлично, только без статей статей это всего лишь слова
Никакого почёта нету в том, чтобы пробивать наты имея пару ассистентов снаружи.
Это умели делать и в 2003-2004 годах, причём все, кто не глупее обезьяны.
Важно чтобы топикстартер допёр до сути проблемы и вариаций таковой.
ну да, поэтому дураки придумали TURN
а гугл вообще глупый, вместо того что бы STUN раздавать, мог бы более двух асcистентов раздавать а не жлобиться на TURN
и все бы были в шоколаде вместо того что бы плясать сейчас вокруг webrtc+stun+turn
да и людей я не понимаю которые сначала подсвечивают слова на то что это возможно только в теории
а потом говорят что они это на практике уже сто лет в обед делали
тс-у наверное вообще все это пофиг, он лабу делает, что бы его в сетевики взяли
Здравствуйте, reversecode, Вы писали:
R>ну да, поэтому дураки придумали TURN R>а гугл вообще глупый, вместо того что бы STUN раздавать, мог бы более двух асcистентов раздавать а не жлобиться на TURN R>и все бы были в шоколаде вместо того что бы плясать сейчас вокруг webrtc+stun+turn
С webrtc та проблема, что он является стандартом. А значит, в нем все ходы должны быть расписаны, и он должен опираться на другие стандарты в вопросах, которые не делает сам. Вот он и опирается на stun, turn и ice (еще одно модное слово, которое ты забыл упомянуть).
В реальности, чтобы пробить конический NAT, хватает 2 RTT, потому что получение своего внешнего адреса и передачу пиру приглашения установить соединение можно объединить в один пакет, и еще один RTT понадобится, чтобы подтвердить соединение и взаимно авторизоваться. Со STUN'ом 2 RTT понадобится только на изучение своего NAT'а (да еще и с ужасными 10-секундными ожиданиями пакетов, которые тебе нафиг на самом деле не нужны), еще пару RTT понадобится, чтобы просигналить пиру и обменяться ICE'ными кандидатами, еще примерно столько же, чтобы проверить этих кандидатов, и только потом можно делать взаимную авторизацию. Т.е., если RTT занимает порядка 200 мс, получаем 5 секунд вместо полсекунды на установление соединения в хорошую погоду — телефонисты оценят разницу.
Здравствуйте, Vetal_ca, Вы писали:
V_>Конкретно, для надежной связи желательно настроить NAT-free внутреннюю VPN сеть. Это исходящее VPN от PC за NAT (любого их количества) и внешний сервер, который держит VPN сервер и обеспечивает routing.
Небось, если бы создатели скайпа так рассуждали, фиг бы их купил за бешеные бапки е-бай, а после микрософт.
Здравствуйте, Qulac, Вы писали:
Q>Да ни чего особенного, соединить один ком с другим через интернет. Проблема в том, что у меня только один комп для тестирования, в этом случае мне лучше положиться на какую ни будь библиотеку или использовать стандартные настройки для этого. Вот не знаю, вот эта настройка решит мои проблемы или нет?
Если только оди из них за натом, то можно попробовать через SOCKS прокси
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Если роутер с NATом умеет в UPNP, то прежде чем долбиться в UDP как выше писали, можно попытаться примерно так
Кстати, умеющие в UPNP роутеры обычно позволяют это умение включить/выключить в своих настройках.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Слава, Вы писали:
С>Надеюсь, когда-нибудь внедрение IPv6 прикончит всё это безобразие.
Да хоть IPv9000 — ничто не запрещает сегментировать сети. И нормальные люди будут использовать это сегментирование, как для удобной себе организации сети, так и для уменьшения доступной для атаки поверхности.
Здравствуйте, Pzz, Вы писали:
Pzz>Это плохая идея, посылать пакеты веером сразу на 1000 портов. У NAT'ов вполне конечный размер таблиц, и когда таблица переполняется, может быть все, что угодно — вплоть до зависания роутера. Роутеры "за 50 баксов из ближайшего компьютерного супермаркета" особенно этим страдают, а большинство роутеров именно такие.
А железки противоположного ценового сегмента задетектят это как потенциальную атаку и забанят этот веерный IP.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Vetal_ca, Вы писали:
V_>>Конкретно, для надежной связи желательно настроить NAT-free внутреннюю VPN сеть. Это исходящее VPN от PC за NAT (любого их количества) и внешний сервер, который держит VPN сервер и обеспечивает routing.
Pzz>Небось, если бы создатели скайпа так рассуждали, фиг бы их купил за бешеные бапки е-бай, а после микрософт.
Скайп вполне себе юзает NAT-PMP, и правильно делает. И только если ничего не помогает, тогда уже начинает тупой foreach по диапазону портов (у меня старый DLink в итоге вешался от такого, в логах инкременты портов видны на ура).
