Как работают динамические адреса провайдера ? #513991

вопрос для расширения кругозора Берем некоего провайдера, который выделяет "динамические" IP адреса своим клиентам из диапазона 201.201.201.1... 201.201.201.255 но клиентов у провайдера гораздо больше 255 и если вечером все клиенты засядут за свои компы, получается один адрес будет у нескольких клиентов ? "динамический" IP подразумевает, что зная его, мы можем "достучаться" до него к клиенту, как же это возможно ? на каком этапе я ошибаюсь в рассуждениях ?

Ну так маска у провайдера не 255.255.255.0, наверное. А как по динамическому адресу определить человека - так ведь "у меня все ходы записаны".

на каждом адресе по несколько и каждый может видеть тот же

Ну начни рассуждать что конец может быть и не 201.201.201.255 а к примеру 201.201.255.255.

мы все в матрице...

не может. не бывает таких адресов у хостов.

если на каждом адресе несколько клиентов и на каждом клиенте открыт порт 5900 VNC сервера, то введя в клиенте адрес, на какую машину я попаду ?

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

Динамические адреса практиковались только в пору ДвуЛапа, тогда было ограничение - число "момедов" равно числу адресов, а вот какой адрес - это зависело от "момеда". Сейчас "динамический IP-адрес" это разновидность фиксированного IP-адреса, то есть каждому подписавшемуся на услугу клиенту предоставляется какой-то фиксированный IP-адрес, а через остальные лазят те, кто адреса не запрашивал, но через NAT (то есть обратной связи нет). Если провайдер честный, то число клиентов, запросивших фиксированный IP, меньше числа IP-адресов, выделенных провайдеру. При этом, правда, провайдер может запросить дополнительные адреса у кого угодно, пробросив их через VPN-тунель до себя. То есть когда кончатся все адреса 201.201.201.XXX следующий адрес может быть выдан 193.XXX.XXX.XXX просто потому, что адрес выдать необходимо, ну или клиент получит "отлуп". Никакого выделения одного IP-адреса нескольким клиентам быть не может. Хотя, никто не обещает, что с выделенного вам адреса не будут ходить другие клиенты (причём даже одновременно с вами). Система трансляции адресов позволяет выходить с одного адреса нескольким клиентам, а на вход использовать адрес только для одного. P.S. поэтому лучше покупать фиксированный IP-адрес, тогда он гарантированно будет вашим.

Как ни странно динамические IP и сейчас не исчезли. Практически все ADSL абоненты получают динамический "белый" IP, уникальный на каждую сессию. Часть провайдеров которые для подключения к интернету используют VPN, тоже дают динамический IP. По этому поводу существует несколько версий. Основная в том, что абонент за фиксированный IP дожен платить провайдеру баксов 2-5, что тоже хлеб. Статику по умолчанию обычно дают корпоративным клиентам.

"Практически все ADSL абоненты получают динамический "белый" IP, уникальный на каждую сессию" - вот это-то и интересно, у какого-нибудь Стрима миллион абонентов, весь миллион выходит в сеть и получается, у стрима должно быть миллион белых IP, пусть и выделяемых динамически среди клиентов ? так ?

Хочешь провайдером в коммуналке стать? :)

По VPN чаще всего вообще дают "кривой" локальный IP, а вот по модемному соединению "по традиции" дают реальный IP. Собственно, ADSL-подключение ничем не отличается от любого другого модемного подключения, так как есть модем у клиента и модем на станции, к которому мы подключаемся. При желании, можно легко и быстро настроить Proxy-фильтр, чтобы он нескольким абонентам выдал один и тот же IP. При этом, Proxy должен будет запомнить каждое установленное соединение от каждого клиента, чтобы приходящие по нему пакеты отсылать тому клиенту, который это соединение установил. Тут есть несколько сложностей: 1) При входящем соединении из интернета пакет не попадёт ни к одному клиенту, так как неизвестно кому его отправлять  - как вариант - первому, но остальные обидятся. Хотя, некоторые рекомендуют заглядывать в таблицу соединений, и если запрос пришёл со стороны сервера, к которому подключался один из клиентов, то запрос адресуется именно ему. Также можно запрос послать всем и сразу, а ответить от имени одного из клиентов, который ответил положительно на запрос соединения. 2) При исходящем соединении будет происходить трансляция портов, так как два клиента могут посылать пакеты от имени, например, 5678 порта, а на Proxy такой порт только один, соответственно, для одно из клиентов будет произведена замена локального порта - какие-то программы, которые используют локальные порты, этого не перенесут. 3) При достаточном числе клиентов могут закончиться все порты, так как их всего 65536 на всех. Однако, такая система немного удобнее раздачи "кривых" локальных IP-адресов, так как для многих программ локальный адрес совпадает с адресом в интернете, а для "знакомых" протоколов типа ftp вообще можно сделать "прозрачную" замену причём так, что абонент, получивший такой адрес, не узнает, что он не один.

по поводу варианта "При входящем соединении "..."можно запрос послать всем и сразу, а ответить от имени одного из клиентов, который ответил положительно на запрос" 1. известно ли доподлинно, что какие-то операторы такое применяют ? 2. получается такая схема грозит утечками - к кому то из клиентов приходит запрос на сессию по порту 5900 VNC, ее перехватывает чужая машина (отвечает раньше той машины, которой пакет предназначался) и затем, с данными о пароле ломимся снаружи и получаем доступ к серверу ?

"Весь миллион одновременно выходит в сеть" А вот и нет. Благодаря закону больших чисел, часть абонентов в любой момент времени не подключена к интернету. Сейчас этот параметр стал похуже, т.к. распространились точки доступа которые сидят в онлайне постоянно, хоть и компьютер абонента выключен. Раньше же вообще классно было, когда использовался режим бриджа. Экономия была процентов  40% айпишников.

по поводу "рекомендуют заглядывать в таблицу соединений, и если запрос пришёл со стороны сервера, к которому подключался один из клиентов, то запрос адресуется именно ему" прога для dindns/noip-подобных сервисов периодически стучится на свои серверы. Но если одним и тем же сервисом пользуются больше одного клиента на одном динамическом адресе, у обоих будет отказ или раздача не тому клиенту ?

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

Ну, десять лет назад данная проблема обсуждалась при настройке IpTables в Linux. Была высказана идея - и люди её опробовали - в принципе - влетело. Только входящие запросы посылались последнему обращавщемуся по данному IP. Теперь немного о том, как устанавливается соединение. Сначала посылается пакет запроса установки соединения, где указан адрес получателя и порт, в который соединяемся. Клиентская машина получает этот запрос и смотрит в TCP-стек, есть ли кто-то "слушающий" данный порт, то есть ожидающий соединения на него. Если есть, то ему передаётся запрос на входящее соединение. Если нет, то посылается ответ "reject", то есть этот порт никому не сопоставлен. Когда клиентский процесс готов ответить, от "подключает" входящее соединение - запрашивающему отсылается пакет подтверждения о соединении. После этого запрашивающий посылает пакет готовности соединения и начинается двусторонний обмен данными. То есть мы установили TCP-соединение и только после этого будет отправляться какой-то пароль и другие данные. Для UDP немного проще - посылается сразу пакет и ответ будет только после его получения или неполучения. В случае "разделения" IP-адреса TCP-пакеты мы можем направлять нескольким клиентам, так как в этом случае мы может узнать, кто из них готов принять соединение на указанный порт - только он ответит положительно (хотя, есть большая вероятность, что их будет несколько). UDP-пакеты мы должны направлять только одному пользователю, так как в них имеются данные, которые он получит - если направить данные нескольким абонентам, то они смогут ответить вместе, что будет "некорректно" с точки зрения протокола, так как вопрошающий получит несколько ответов, вместо одного. Использовать динамический IP-адрес для простой авторизации нельзя даже если гарантировано, что он даётся одному клиенту, так как за время установления соединения клиент может отключиться и будет подключен другой. Поэтому, для авторизации используется метод с проверкой подлинности получателя. То есть сначала обе стороны соединения убеждаются, что они именно те, кем являются, а уже потом устанавливается соединение. При современных протоколах безопасной авторизации считывание пароля "случайным" перехватчиком невозможно - так что бояться нечего. А вот если "перехватчик" получит также сертификаты для подписи, то тогда действительно, он сможет выступить от имени серверной части.

dyndns - точно не знаю, но подозреваю, что будет "прописан" последний обратившийся. Если, конечно, они вводят фильтрацию по IP-адресу и не дают нескольким клиентам использовать один и тот же IP-адрес. И не каждый абонент пользуется такими сервисами - их можно "разнести" на разные IP, если запоминать в таблице, какой из абонентов чем пользуется, то можно избегать и "скрещивания" абонентов, которые используют одинаковые порты для входящих соединений. P.S. мне кажется, что на каждый IP-адрес можно выделять только одного абонента, который активно использует входящие соединения, а остальных добавлять "для кучи".

Хм. Подумав. Есть еще один неочевидный плюс. Абонент перестал пользоваться услугами и платить. Статику придется держать в этом случае за абонентом какое то время, теряя на этом деньги. Динамический IP будет свободен с момента отключения. Выгодно. Сколько сейчас абонентов того же стрима убежали с него на других провайдеров не расторгнув договоры? ИМХО, дофига.

Никто не мешает "освободить" IP после прекращения его оплаты через какое-то определённое время. Статический IP - это гарантия, что с этого IP-адреса не будет работать никто другой - вот за это и берутся деньги. Как известно, стрём раз в день рвёт соединение - он в этот момент смело может поменять IP.

вопрос какое это время, а провайдер должен будет платить за аренду этого простающего IP.

может как раз "проблемы" стрима изза повышения использования юзерами кол-ва портов ? раньше например юзали только ИЕ, теперь же куча прог одновременно висит по своим портам в сети не вылезая если так, то стоит ожидать ограничений по одновременно открытым портам ?

Таки он с абонента получил за пользование IP - причём IP просят оплатить сразу за несколько месяцев. Если пол-месяца IP простоит без дела, то ничего страшного. Потом данный IP "пополнит" коллекцию динамических, так как его всегда можно "вернуть" назад, если клиент заплатит. А если не заплатил в течении длительного времени, то договор автоматически расторгается - и IP можно выдавать кому-то другому. Раньше браузеры на каждый запрос открывали новый порт, сейчас соединения с сервером какое-то время живут и по ним можно делать повторные запросы, что изрядно сокращает количество используемых IP-портов.

таким образом, 1. один и тот же внешний IP (динамический) единовременно могут использовать больше одной машины при применении "прокси" провайдера, макс количество машин (которые могут выйти в сеть с исходящими соединениями) складывается из 65К/сумму всех портов, задействованных на машинах 2. при использовании "no-ip" подобного сервиса, стоит пользоваться наименее востребобанным из них, чтобы снизать вероятность использования этого сервиса соседом ? 3. для программ удаленного доступа, которые не используют сертификатов (протоколы RDP, VNC, Radmin) с сервером, , находящимся на "динамическом" адресе есть вероятность, что пароли попадут к чужой машине этого же провайдера, если она будет отвечать подобно серверу до момента получения от клиента извне пароля ? верны ли мои "выводы дилетанта" из твоего поста ?

+ добавлю к 1. "задействованных на машинах единовременно" + какая то машина может получить отлуп не полностью, а по новому открываемому на ней порту

1. Так происходит у всех провайдеров, которые дают "внутренний IP гарантировано", а у "смежников" -  тоже. 2. Если используется такой сервис, то лучше оставить на своей машине "открытый" порт, который отвечает на запрос что-то уникальное, чтобы быть уверенным, что попадаешь к себе, а не соседу. 3. Конечно. У вас порвалась связь, ваш IP выдали соседу. И подключился он. Для предотвращения таких ситуаций у провайдеров вводилось время жизни IP-адреса после отключения, чтобы в течении какого-то времени после разрыва связи IP-адрес оставался "свободным", чтобы его мог получить тот, кто отключился. P.S. насколько я знаю, Stream не использует разделение реально выданных IP-адресов на несколько пользователей. "Расслоением" грешат только домашние сети, так как там действительно есть ограниченное число адресов, а Stream может, при необходимости, запросить адреса из другого региона.

в 1С это не возможно

Она получит не отлуп, а таймаут связи, так как отправленный ею запрос на соединение при отсутствии свободных портов будет поставлен в очередь и ждать освобождения порта в течении какого-то времени, а только потом будет получен отлуп. Если учесть, что реальный пользователь более 100 портов не использует, то 600 пользователей на один IP - это даже для домашних сетей очень "тяжело" - то есть ситуация чисто теоретическая. Например, если все пользователи Москвы зайдут на один сервер, то для него это будет смертельно - порты кончатся.

если я на клиенте с динамическим IP подниму dindns - адрес, а поверх него OpenVPN с сертификатами, я смогу внутри получившейся VPN сети не переживать за безопасность данных (до поры обнаружения уязвимостей опенВПН и до потери сертификатов, разумеется) ?

Да. В данном случае случайного получения пароля не будет, а случайно полученные данные, даже если они и будут, всё равно зашифрованы.

+ и заработает ли OpenVPN между "динамическим IP + dindns" (т.е. к нему будут обращаться не по IP а по адресу мойдомен.dindns.com) и клиентом без динамического или постоянного IP (серый IP) ?

А в чём проблема - клиент будет знать DNS-адрес, а сервер будет знать, что к нему могут подключиться. Сертификат придётся привязывать не к IP-ардесу, а, может быть, он даже будет самоподписной.

"Stream может, при необходимости, запросить адреса из другого региона" - а зачем ему запрашивать адрес из региона, если "выгоднее" дать "расслоеный"? только из-за качества оказания услуги для клиента ?

, чтож, низкий поклон, за ликбез, спасибо

белый адрес может быть дан хоть сотне клиентов и каждый будет видеть себя этим адресом

а если у всех будет открыт порт 5900 VNC сервера, то введя извне адрес, на какую машину я попаду ?

ни на какую

Абрахамс, не томи - выкатывай ликбез.

да какой там ликбез, он дает каждому один и тот же адрес, по сути с изнего конца "вилан", с наружи тот же адрес виден, но через него никуда не попасть кроме как к провайдеру, все это випиэн

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

, ну это жульничество и не предоставление полноценного внешнего IP

На самом деле, всё определяется договором на услуги связи. Если в договоре есть фраза, клиенту выделяется IP-адрес (и не "внутренний IP-адрес"), то если один и тот же адрес выдан нескольким клиентам, то можно считать это нарушением договора - если слов про IP-адрес нет - то и претензии предъявлять не к кому. Это не жульничество - это тоже самое, что предоставление "внутреннего IP-адреса" (серия 192.168.XXX.XXX, 10.XXX.XXX.XXX и 176.XXX.XXX.XXX), только в этом случае часть программ, которая использует IP-адрес для работы с сертификатами безопасности, работать не будет, так как сервер получит реальный адрес, а клиент будет передавать сертификат для внутреннего IP-адреса. А так - и волки целы (IP-адреса) и овцы сыты (IP-Sec работает)

Ребят, вы бредите, привязанность к проволоке не дает шансов! :))

В чём проблема ? Если активные switch-и, то каждому клиенту можно дать свой IP без проблем - причём, абсолютно любой, а все пакеты разрулить на сервере.

Возникает интересный вопросик, какая железка пондобится, чтоб эту хрень разрулить? Предположим, мы имеем 1000 юзеров на 50IP, из которых 200 активно пользуются торрентом каждый из которых генерит поток в среднем 50kpps. Все умрут?

хм.. ну и кто тебе это позволит?

провайдер сам себе режиссер.

Во-первых, разруливать нужно только пакеты установки связи, а все данные уже идут "по накатанной", во вторых, обрабатывать нужно только заголовки пакета, а не данные. Да и просто маршрутизация пакетов от 1000 пользователей - это уже не просто - их же надо направлять по разным подключениям (у хорошего провайдера не один выход в интернет).

поправить "только заголовки" в потоке в десятки-сотни тысяч ppps это уже очень нехилая задача, проще за сотню баксов докупить айпишников и не парится. Дешевле выйдет. Чего провыайдеры от NAT стали отказываться, нет железок на которых можно прозрачно NATить гигабиты и не париться.

Железо есть, просто это железо "сращивает" реальные IP-точно также, как и транслирует внутренние - поэтому смысла в разгребании нескольких IP- никакого нет. Кроме того, виртуальные IP-адреса позволяют клиентам общаться между собой, минуя провайдера, а использование одного IP-адреса для всех блокирует это "общение". Кстати, посмотрел спецификацию - никто не запрещает для нескольких клиентов использовать не только один адрес, но и один и тот же исходящий порт - главное, чтобы они только к разным серверам обращались - иначе сервер спутает двух клиентов.

P.S. а для Web-протокола вообще проще всего прозрачный Proxy - тогда можно и не думать ни о какой трансляции и использовать один IP-адрес для всех клиентов.