Как сервера взаимодействуют с клиентом если IP адреса не уникальные?

Question

[Holy Molly]

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

Answer 1

[Saboteur]

На устройство с серым айпи нельзя отправить первый пакет.

Но само устройство может отправить пакет на устройство с белым айпи, благодаря маршрутизации. А благодаря технологии NAT на роутере с белым айпи для этого устройства резервируется порт для обратной связи.
Нат обычно и настроен на ближайшем маршрутизаторе.

Либо на маршрутизаторе можно настроить проброс порта (port forwarding) - это статичное резервирование определенного порта на маршрутизаторе для того, чтобы все что идет на этот порт перенаправлялось на нужный порт нужного устройство в подсети маршрутизатора.

Comments

[Holy Molly]

А как тогда работают бессерверные мессенджеры в которых оба устройства одновременно являются и серверами и клиентами?

[Saboteur]

Например, какие такие мессенджеры?

они должны друг друга хотя бы раз увидеть иначе никак.

[Zerg89]

Holy Molly, точно также только нат на стороне провайдера
И если утрировать таких нат'ов на всем пути может быть не больше чем прыжков в трасерт
Или используется что-то типа igdrasil

[Holy Molly]

Zerg89, то есть, два серых устройства всё таки можно связать через айпишники.

[Zerg89]

Igdrasil работает как торрент(dht) а связь идёт напрямую только адресное пространство ipv6, и я с ним не работал так что конретней не скажу, но и в ipv4 тоже похожая тема есть hamachi

[Saboteur]

Holy Molly, просто так нельзя. Нужно настроить проброс портов на тех устройствах, которые имеют белые айпишники и прямой доступ в локалку с устройством. Либо на всем следовании маршрута.

[Zerg89]

Saboteur, и как ты на всем следовании маршрута до США наты настраиваешь? Когда до google vps стучишся?

[Zerg89]

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

[Василий Банников]

Zerg89, так и не нужно на всём маршруте. Достаточно только до сети своего провайдера дойти - он на своей стороне nat уже настроил, чтобы у тебя всё работало.
Тебе же остаётся настроить только свой роутер.

+ Проблема не такая очевидная, если используется ipv6

[CityCat4]

Zerg89, Задолбали уже обсуждать этот вопрос. Нет никаких "бессерверных" мессенджеров. Для начального контакта этот "бессерверный" мессенджер все равно стучится на определенный адрес, чтобы получить список активных клиентов.
Есть еще вариант получить этот список через mesh - когда клиент шлет бродкаст, а все получившие его отвечают. Это конечно сработает только в локалке, но у некоторых вдруг могут обнаружиться соседи из других сетей. Но смысла в такой сети - нуль, потому что любой может ответить на бродкаст, не говоря о том, что сообщение, отправленное Васе Петей может добраться до Васи тогда, когда оно ему совершенно не нужно.
Это скорее всего очередной геймо-сетко-строитель :)

[res2001]

Holy Molly, Есть технологии, позволяющие обходить NAT. Смотри, например, STUN.
Любое ПО, которому нужен p2p обмен использует ту или иную технологию обхода NAT. Это все не просто и надо глубоко понимать вопрос, чтоб в этом разобраться.
Любая технология обхода NAT зависит от некоего сервера, имеющего белый известный всем участникам адрес (или должен быть способ узнать этот адрес). Этот сервер нужен только на этапе "установления соединения", дальше обмен идет на прямую.

[Saboteur]

Zerg89, Ну не обязательно до США, можно между своими филиалами по разным подсетям.

Во-вторых, наты до ближайшего белого айпи.

Например у тебя провайдер выдает серый айпи твоему роутеру.
Твой роутер раздает еще один серый айпи по квартире. Вот уже есть нат на роутере и на маршрутизаторе провайдера.

Answer 2

[Василий Банников]

Я так понимаю, что интересен случай ipv4, где многие узлы могут делить один адрес.

В этом случае всё разруоивается при помощи NAT.
1. Когда через поутер проходит какой-то запрос во внешнюю сеть - он подменяет адрес отправителя на свой, а также прописывает в порт отправителя какой-нибудь ещё не занятый порт, чтобы можно было отличить одного клиента от другого.
2. При этом он у себя в памяти сохраняет, кто на самом деле отправил запрос и с каким изначально портом, чтобы можно было отправить обратно.
3. Когда приходит ответ от сервера - в адрес назначения и порт подсовывается то, что было заранее сохранено.
4. При закрытии соединения - запись убирается.

Он работает полностью автономно и по пути следования таких может быть много.

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

Также есть проброс портов - по факту то же самое, но настраивается заранее либо при помощи upnp.