Связка белый+серый ip оператора мобильной связи уникальна или нет?

Question

[Mofazu]

Оператор мобильной связи, для доступа в интернет назначил белый ip адрес 31.173.81.179

При этом для моего смартфона назначен серый ip адрес 10.190.161.107

Но если белый ip адрес (в данном случае 31.173.81.179) могут кроме меня делить другие абоненты.
То правильно ли я понимаю, что серый ip адрес(в данном случае 10.190.161.107) уникален в привязке к белому адресу?

Т.е не может одновременно существовать 2 абонентов в сети, с белым адресом 31.173.81.179 и серым адресом 10.190.161.107.
Так ли это на самом деле или я ошибаюсь?

Если это так, то какие преимущества даёт уникальный серый ip адрес в рамках одного белого?

Comments

[pfg21]

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

[aleks-th]

спроси у оператора, кроме него тебе никто этого не скажет

[Артём]

pfg21,

на твой "белый" ип могут натится порты серых ip.

Не просто могут, а 100% натятся другие абоненты.
Никто из провайдеров не держит за абонентом целый белый IP, если он ему не принадлежит полностью

[pfg21]

Артём, самое странное но мне ростелеком периодически вместо сотой сети выдает я так понимаю белый ипв4 адрес. жаль отловить сейчас нет возможности. роутер слишком тупой и самого ломает. но периодически в веб-интерфейсе замечаю адреса не из 100.*.*.* и как следствие входящие торрент-соединия появляются...

[Алекс]

Артём, на RT был период в целых пять лет, для того что-бы скинуть адрес приходилось танцевать с бубуном, выключил ждешь 10 минут, включешь изменений нет, выключаешь ждешь 30 минут, изменений нет и так период мог увеличиваться до часов 12-24, пока другой абонент не освободит адрес

Answer 1

[Пума Тайланд]

да, в рамках одного NAT-шлюза серый адрес обязан быть уникальным в конкретный момент — иначе трансляция privateIP:port → publicIP:port сломается, NAT не поймёт кому роутить обратный пакет. Дело не в "конфликте адресов" как таковом, а в том, что таблица трансляций держится именно на этой уникальности.

Но она локальная и временная: тот же серый адрес может достаться другому абоненту после разрыва/переподключения мобильной сессии, а за другим белым IP или NAT-шлюзом точно такая же связка вполне может повторяться параллельно.

Answer 2

[Akina]

Связка белый+серый ip оператора мобильной связи уникальна или нет?

В общем случае - нет. Представь себе каскад из двух NAT на серых адресах.

У обоих клиентов один и тот же локальный серый и один и тот же внешний белый. А трассы - разные. И NAT-2 прекрасно разруливает их трафик, ибо для него у трафиков разные узлы назначения.
PS. Максимум, что я видел своими глазами у провайдера - пять последовательных серых NAT. Вернее, у провайдера четыре, и пятый мой..

Answer 3

[Артём]

Так ли это на самом деле или я ошибаюсь?

Так.
Преимущества уникального серого IP в отсутствии конфликта адресов

Comments

[Akina]

Преимущества уникального серого IP в отсутствии конфликта адресов

Отсутствие конфликта не гарантирует отсутствия совпадения. L2-маршрутизатору плевать на совпадающие L3-адреса, они для такого маршрутизатора просто не существуют, ибо он так высоко не смотрит.

Answer 4

[pfg21]

если ты купил белый ип - то он полноценно твой.
если не купил - то у оператора рязвязаны руки по любому использованию этого адреса.

и думаю это не белый ип :) это просто адрес сервера, который NATит твои потоки в тырнетик.
входящий поток проходит ??

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

Answer 5

[Zerg89]

Нет, не уникальна, уникалными можно счиать только связки параметров (источник)srcip:port:(точка назначения)dstip:port
Nat работает порт в порт с подменой ip при исходящем трафике меняется адрес назначения чтобы было понятно куда ответ слать, при входящем меняется ip адрес источника, и так происходит на каждом узле ната, в таблице ната записаны эти параметры (srcip:port:dstip:port) на каждом нате будет(может) менятся и порт каскадом тоесть(1.1.1.1:444:2.2.2.2:555-> 2.2.2.2:555:3.3.3.3:567-> 3.3.3.3:567:4.4.4.4:8888 стрелкой обозначен переход на каждом нат узле порты скорее всего выше в диапазоне от 1024 они зарезервированы под определенные сервисы)

Comments

[Akina]

Нет, не уникальна, уникалными можно счиать только связки параметров (источник)srcip:port:(точка назначения)dstip:port

Если вы говорите об одном маршрутизаторе, то да. Да и то с буквоедскими оговорками (ну не в каждом протоколе есть порт).

А вот если вы говорите о всём пути, со всеми промежуточными узлами, то это неверно. См. мой ответ - что там изменится, если добавить номера портов? Да ровным счётом ничего... ну кроме весьма малой вероятности столь точного совпадения номеров клиентских портов на практике - но ведь мы сейчас теоретизируем.

[Zerg89]

Akina, изменится то что можно сделать так:
1.1.1.1:444:2.2.2.2:555-> 2.2.2.2:555:3.3.3.3:5567-> 3.3.3.3:5567:4.4.4.4:8888
и так
1.1.1.1:445:7.7.7.7:555->
7.7.7.7:555:8.8.8.8:5555-> 8.8.8.8:5555:9.9.9.9:8888
И за одним белым ип влезет дохрена клиентов, то для чего нат и был придуман

Белый ip если он его купил у него прямая трансляция портов будет порт в порт через поля replaysrc и replaydst на конечных маршрутизаторах тоесть но внутри сети провайдера порты будут такими как удобно провайдеру во избежание колизий
1.1.1.1:8888:7.7.7.7:555->
7.7.7.7:555:8.8.8.8:5555-> 8.8.8.8:5555:9.9.9.9:8888

[Zerg89]

Akina,

ну не в каждом протоколе есть порт

в тех которые либо инкапсулируются внутрь l3 пакета, либо работают по мультикаст/броадкаст, им порт не нужен так как идет рассылка по свему сегменту сети по маске, кто должен услышит и натирует/перешлет куда надо, icmp инкапсулируется в l3 пакет и адреса у него изначльно адрес отправителя(пк) и адрес получателя(точка назначения) зтем адрес отправителя меняется на адрес маршрутизатора и так на каждом маршрутизаторе с регистрацией с какого ip:port этот пакет получен чтобы вернуть обратно ответ с правильным адресом отправителя, иначе(если не вернуть ип отправителя) этот пакет будет отброшен так как это не я отправлял(точнее это не мне, так как обратный трафик меняет dstip) этот пакет мне не нужен

[Akina]

Zerg89,

изменится то что можно сделать так

Тут я как-то вообще не понял, что вы имеете в виду. Ну то есть я знаю, что в пакете есть адрес/порт узла-источника, текущего узла-приёмника (шлюза, ближайшего маршрутизатора) и узла назначения. Но вот с какого перепугу у вас на каждом (а главное - на первом) хопе меняется адрес (дефолтного) шлюза - для меня натурально загадка.

в тех которые либо инкапсулируются внутрь l3 пакета

Да я как бы на ICMP намекал, который сам по себе L3 и ни в какой L3 не инкапсулируется.

[Zerg89]

Но вот с какого перепугу у вас на каждом (а главное - на первом) хопе меняется адрес (дефолтного) шлюза - для меня натурально загадка.

а кто сказал что до 9.9.9.9 вы можете достучатся через основной шлюз представте что на каждую /24 сеть выделен свой маршрутизатор первый выходной с публичными ip имеет сеть 1.1.1.1 остальные каскадом на две-три ветки 2.2.2.2 за которым сответственно 3.3.3.3, 4.4.4.4 и 7.7.7.7 за которым 8.8.8.8, 9.9.9.9 и еще есть 5.5.5.5 за которым 6.6.6.6, но не это важно, принцип в том что разные порты на одном ip маршрутизируются клиентам разных сетей и все работает так
1.1.1.1:444:2.2.2.2:555-> 2.2.2.2:555:3.3.3.3:5567-> 3.3.3.3:5567:4.4.4.4:8888
и так
1.1.1.1:445:7.7.7.7:555->
7.7.7.7:555:8.8.8.8:5555-> 8.8.8.8:5555:9.9.9.9:8888

Про icmp почитайте чем отличается заголовок ip пакета от icmp пакета и какие у них различия