ip маршрутизация , обратный маршрут

[HighMan]

Здравствуйте, Господа!
Хотелось бы прояснить один момент, который как-то выпал из познаний и, соответственно, понимания.
Извините за много цифр, понимаю, что они затрудняют понимание и часто приводят к путанице, но иначе не могу объяснить суть вопроса.
Есть компьютер, с адресом 192.168.0.2 в локальной сети. Default gateway 192.168.0.1
Он выходит в сеть провайдера через wi-fi роутер. Адреса роутера 192.168.0.1 для локальной сети и 10.10.0.100 для сети интернет провайдера. Для него default gateway 10.10.0.1 адрес подъездного роутера.
Ip gateway провайдера (конечный роутер провайдера в internet), допустим... 1.1.1.1
Вот я со своего домашнего компьютера хочу залезть на forum.sources.ru...
Как мой запрос доходит до "исходников" более-менее понятно. Интересно, как ответ доходит до моего компьютера.
В ip пакете есть 2 поля: source и destination. Выходя с моего компьютера source=192.168.0.2, destination= ip "исходников". Если я правильно пониманию, то проходя через мой wi-fi роутер, source ip изменяется на 10.10.0.100 и дальше пошёл по "инстанциям".
Вот теперь я хочу понять как пойдёт пакет от "исходников" достигнет моего компьютера, не имеющего "белого" ip.
Для простоты будем считать, что между маршрутизатором провайдера (1.1.1.1) и исходниками нет промежуточных маршрутизаторов.
Вопрос преобразования forum.sources.ru в ip опустим. Это дела DNS и все понятно, кроме опять же обратного маршрута от сервера DNS к компьютеру с серым ip.

[Akina]

Цитата HighMan @ 26.11.16, 19:36

В ip пакете есть 2 поля: source и destination.

Угу. Вот только общение происходит на по абстрактному IP, а по вполне конкретному TCP. А там адресов чуть больше, чем два...

[HighMan]

Цитата Akina @ 26.11.16, 20:40

Угу. Вот только общение происходит на по абстрактному IP, а по вполне конкретному TCP. А там адресов чуть больше, чем два...

М... Ну ладно. Об этом я как-то не подумал. Не принял в расчёт TCP.
Замнем для ясности.
А как тогда работает udp?
В первоначальной задаче меняем "исходники" на некий сервер с адресом 2.2.2.2 с открытым udp портом. Как до него достучаться - понятно. Но как ответ обратно доходит? Неужели udp тянет за собой весь хвост адресов маршрута?
И, вообще, tcp - лишь надстройка на ip.
Вот я и хочу понять, как это работает на уровне ip.

[grgdvo]

Работает NAT (Network Address Translation).
Пара адрес:порт мапируется на другую пару адрес:порт.
Если первая пара локальный адрес (локальная сеть), то обычно называют Source NAT (подстановка/замена адреса отправителя).
При этом отслеживается обратный трафик и автоматически выполняется обратное преобразование.
В вашем случае вполне вероятно может выполняться двойное преобразование, пока трафик "выйдет на уровень Интернета".

Сетевое Устройство	входящий пакет	исходящий пакет
Комп		src=192.168.0.2:XXXX dst=forum.sources.ru:80
ВайФай (NAT #1)	src=192.168.0.2:XXXX dst=forum.sources.ru:80	src=10.10.0.100:XXXX dst=forum.sources.ru:80
Провайдер (NAT #2)	src=10.10.0.100:XXXX dst=forum.sources.ru:80	src=1.1.1.1:XXXX dst=forum.sources.ru:80

Теперь в обратную сторону пойдет пакет

src=forum.sources.ru:80
dst=1.1.1.1:XXXX

который потом через двойное обратное преобразование превратится в

src=forum.sources.ru:80
dst=192.168.0.2:XXXX

Надо обратить внимание на XXXX. Порты могут меняться в процессе прохождения NAT.
В зависимости от того как сетевое устройство транслирует адреса и порты различают четрые вида NAT
Более подробно расписано в википедии

[HighMan]

Цитата grgdvo @ 26.11.16, 22:49

Теперь в обратную сторону пойдет пакет

src=forum.sources.ru:80
dst=1.1.1.1:XXXX

который потом через двойное обратное преобразование превратится в

src=forum.sources.ru:80
dst=192.168.0.2:XXXX

Надо обратить внимание на XXXX. Порты могут меняться в процессе прохождения NAT.
В зависимости от того как сетевое устройство транслирует адреса и порты различают четрые вида NAT
Более подробно расписано в википедии

Малость не сходится. В протоколе ip нет понятия порта. Есть понятие адреса. Порт появляется в udp надстройке. Маршрутизация осуществляется на уровне ip пакетов. Т.е. без портов.
Получается следующее: устройства меняющие source ip, должны некоторое время хранить историю прохождения пакетов. Скорее всего, время хранения, завязано на TTL.
Пакет возвращающийся от "исходников" повторяет не весь маршрут, а лишь "ключевые точки". Т.е. только те маршрутизаторы, которые меняли source ip изначального пакета.
В моём случае, ip меняли маршрутизатор провайдера и мой wifi. Пакет достигший "исходников" имеет source ip = 1.1.1.1, т.е. маршрутизатора моего провайдера. Свой ответ "исходники" отправляет на 1.1.1.1 (destination = 1.1.1.1). Маршрутизатор провайдера выуживает из памяти что на исходники отправлял запрос 10.10.0.100 (т.е. адрес моего wifi роутера) и отправляет пакет ответа ему, подменив destination ip на 10.10.0.100.
Мой wifi проделывает то же самое и destination ip становится 192.168.0.2.
Пакет достиг конечной точки на моём компьютере.
Вот это большего всего похоже на правду.

Я не стал менять вышенаписанное, но закрылось подозрение, что время, которое содержится в памяти маршрут, у маршрутизатора изменившего source ip, не имеет ни чего общего с TTL.
Сервер, получивший запрос, вовсе не обязательно, ответит сразу. Время на выдачу ответа может быть ооочень разным и достигать нескольких часов!
Получается, что маршрут храниться до получения ответа или до перезагрузки маршрутизатора.

Теперь мы подходом к тому, кто должен менять source ip, и ,следовательно, хранить свою часть маршрута.
Получается, что должны хранить маршрут, должны все маршрутизаторы без белых ip, изменивших source ip. И маршрутизатор провайдера, который меняет серый source ip на свой белый.
Внутри серой сети, менять source ip, должны все маршрутизаторы, осуществляющие форвардинг в иной адресный диапазон.

Вот это ещё больше похоже на правду.
Если я вру - поправьте!

Кстати, вопрос обратного маршрута, поставил в тупик ВСЕХ моих знакомых админов. Большинство верно представляло как пакет запроса достигает сервера с белым ip, но "плыло" на обратном маршруте с серыми ip.

Еды палы! Не все так просто! На исходники могли отправлять несколько человек из сети моего провайдера!
Как тогда маршрутизатор провайдера определяет кому переправить ответ? Выходит, что должна ещё сохраняться некая информация, идентифицируются, что ответ предназначен именно мне!
Что это за информация и где она хранится??????

Сообщение отредактировано: HighMan - 27.11.16, 12:37

[Akina]

Цитата HighMan @ 27.11.16, 12:29

Малость не сходится. В протоколе ip нет понятия порта. Есть понятие адреса

Угу. А ещё в нём нет понятия сеанса - и, следовательно, нет и понятия ответа. Ну и одно из следствий - IP сам по себе, без 3 уровня, в принципе не способен пройти за NAT.

Добавлено 27.11.16, 12:50
PS. TTL - это вообще-то НЕ время. Это счётчик.

[HighMan]

Цитата Akina @ 27.11.16, 12:48

Угу. А ещё в нём нет понятия сеанса - и, следовательно, нет и понятия ответа. Ну и одно из следствий - IP сам по себе, без 3 уровня, в принципе не способен пройти за NAT.

Добавлено 16 минут назад
PS. TTL - это вообще-то НЕ время. Это счётчик.

Жжоте напалмом!
IP маршрутизация! Не TCP и даже не UDP!
Именно на уровне IP достигается возможность получения отправителем ответа. Я специально написал "возможность". IP не гарантирует непременного достижения.
Сейчас рою формат IP пакета на наличие поля идентификатора, которое позволяет переправить изменившему source ip, ответ запросившему.
Подозрение падает на IDENTIFICATION.

Цитата

Поле Идентификатор пакета (IDENTIFICATION) занимает 2 байта и используется для распознавания пакетов, образовавшихся путем фрагментации исходного пакета. Все фрагменты должны иметь одинаковое значение этого поля.

Судя по всему, это поле так же меняет и хранит, каждый изменивший source ip. И меняет его так что бы в очереди маршрутов это поле было уникальным для каждого маршрута с повторяющимися source и destination ip.

Цитата

Поле Время жизни (TIME TO LIVE) занимает 1 байт и указывает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи средствами протокола IP. На шлюзах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается также при каждой транзитной передаче (даже если не прошла секунда). При истечении времени жизни пакет аннулируется.

Сообщение отредактировано: HighMan - 27.11.16, 13:29

[Akina]

Цитата HighMan @ 27.11.16, 13:18

IP маршрутизация! Не TCP и даже не UDP!
Именно на уровне IP достигается возможность получения отправителем ответа.

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

Насчёт TTL - та же каша. Ну нелья в 1 байт запихнуть время! Темболее если это байт интерпретируется как беззнаковое целое, а штампы времени в пакете оперируют на три порядка бОльшей точностью. Редчайший случай, когда транзитныйузел отдаёт пакет с уменьшением TTL больше, чем стоимость узла. А посему интерпретация поля НЕ как счётчика есть фикция.

[Pavia]

HighMan

Цитата HighMan @ 27.11.16, 13:18

IP маршрутизация! Не TCP и даже не UDP!
Именно на уровне IP достигается возможность получения отправителем ответа. Я специально написал "возможность". IP не гарантирует непременного достижения.

Ещё раз. В протоколе IP ни сказано про ответ ровным счётом ничего.
Давайте считать, что маршрутизация на уровне IP не имеет дело с NAT.
Такие NAT были во времена DSL- технологий. Сейчас о них можно забыть.

Цитата HighMan @ 27.11.16, 12:29

Еды палы! Не все так просто! На исходники могли отправлять несколько человек из сети моего провайдера!
Как тогда маршрутизатор провайдера определяет кому переправить ответ? Выходит, что должна ещё сохраняться некая информация, идентифицируются, что ответ предназначен именно мне!
Что это за информация и где она хранится??????

Когда за одним IP прячится несколько компьютеров, то их идентифицируют по порту отправления. В обратную сторону он становится портом приемника. И такой тип NAT работает только с протоколами TCP и UDP.

Цитата

Скорее всего, время хранения, завязано на TTL.

Зависит от конкретного воплощения. Но в большинстве случаев не завязано.

Цитата

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

Опять таки зависит от конкретного маршрутизатора. Для защиты от переполнения соединение весящие более 1 часа уничтожается. Поэтому приложениям приходится делать защиту от сбоя. Восстанавливать соединение или периодически слать пакеты.
Во-вторых тут стоит говорить о различиях в работе NAT для TCP и UDP. Для TCP можно отсеивать наличие сессии. Для UDP либо привязка к TTL либо просто время достаточно большое к примеру 8600 секунд = 2 часа.

А если говорить о NAT на уровне IP. То там даётся один внешний IP. Так называемый динамический IP. Тогда каждый клиент имеет свой IP. Но все клиенты одновременно выйти в сеть не могут. Когда внешние IP заканчиваются, то маршрутизатор шлёт клиентом отказ в подключении к интернету. На DSL просто был занят номер. И опять таки привязка шла порядка нескольких часов-дней. А подключение и отключение отслеживалось через стороннии или внешние механизмы. Клиент "телефонную трубку" положил всё IP свободен.

Сообщение отредактировано: Pavia - 27.11.16, 14:50

[HighMan]

Цитата Akina @ 27.11.16, 14:18

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

Насчёт TTL - та же каша. Ну нелья в 1 байт запихнуть время! Темболее если это байт интерпретируется как беззнаковое целое, а штампы времени в пакете оперируют на три порядка бОльшей точностью. Редчайший случай, когда транзитныйузел отдаёт пакет с уменьшением TTL больше, чем стоимость узла. А посему интерпретация поля НЕ как счётчика есть фикция.

Насчёт каши согласен. Но не в моей голове.
Я Вам привёл простейший пример - UDP. Это боле высокий уровень над IP, но ниже TCP. И как тогда достигают точки назначения UDP пакеты? Простейший пример OpenVPN, который прекрасно работает по UDP. И только серверу нужен белый IP. Остальным участникам не обязательно.
А UDP минимальная надстройка над IP. По большому счёту только порт добавляет и упрощает сборку изначального пакета.
Никаких добавок, касающихся маршрутизации, в UDP нет.
Ещё есть ICMP... Тот же ping позволяет Вам, не имя белого IP, получать эхо ответы.

Насчёт TTL... Это я не себя цитировал, если что.
Вы тоже правы. Путаница. Изначательно, TTL был именно временем в секундах, позже он превратился в максимальное кол-во "прыжков".

[Akina]

Цитата HighMan @ 27.11.16, 14:37

А UDP минимальная надстройка над IP. По большому счёту только порт добавляет

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

Забавная терминологическая неувязочка, кстати - IP-маршрутизация в рамках чистого IP невозможна.

[Pavia]

HighMan
Ваша проблема в том что вы пытаетесь учить сети в отрыве от практике.

[HighMan]

Цитата Pavia @ 27.11.16, 14:36

Ещё раз. В протоколе IP ни сказано про ответ ровным счётом ничего.
Давайте считать, что маршрутизация на уровне IP не имеет дело с NAT.
Такие NAT были во времена DSL- технологий. Сейчас о них можно забыть.

Погуглите UDP и ICMP.

Цитата

Когда за одним IP прячится несколько компьютеров, то их идентифицируют по порту отправления. В обратную сторону он становится портом приемника. И такой тип NAT работает только с протоколами TCP и UDP.

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

Цитата

А если говорить о NAT на уровне IP. То там даётся один внешний IP. Так называемый динамический IP. Тогда каждый клиент имеет свой IP. Но все одновременно выйти в сеть не могут. Обычно клиентам просто шёл отказ в подключении к интернету. И опять таки привязка шла порядка нескольких часов-дней. А подключение и отключение отслеживалось через стороннии или внешние механизмы.

Это откуда? Какой ,нафиг, внешний IP??? Как быть с моей самопостроенной сети? Она так же получает внешний IP???

Цитата Akina @ 27.11.16, 14:44

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

На самом деле добавляются всего 2 порта: source и destination. IP адреса наследуются от IP пакета.
И о каком IP Вы говорите? Source | destination?

Цитата

Забавная терминологическая неувязочка, кстати - IP-маршрутизация в рамках чистого IP невозможна.

Не смешите. IP маршрутизация! Где тут TCP/UDP/NetBIOS/HTTP/FTP/etc...?

Цитата Pavia @ 27.11.16, 14:44

Ваша проблема в том что вы пытаетесь учить сети в отрыве от практике.

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

[Pavia]

Цитата HighMan @ 27.11.16, 15:03

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

Всё верно. Просто порт используется не отдельно, а вмести с IP отправителя и получателя.

Цитата HighMan @ 27.11.16, 15:03

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

Не похоже. Тогда мне более 2200 лет. Из них четверть века сисадмин и администратор.

Цитата HighMan @ 27.11.16, 15:03

Не смешите. IP маршрутизация! Где тут TCP/UDP/NetBIOS/HTTP/FTP/etc...?

Цитата HighMan @ 27.11.16, 15:03

Цитата Pavia @ 40 минут назадЕщё раз. В протоколе IP ни сказано про ответ ровным счётом ничего.
Давайте считать, что маршрутизация на уровне IP не имеет дело с NAT.
Такие NAT были во времена DSL- технологий. Сейчас о них можно забыть.
Погуглите UDP и ICMP.

Вот тут у вас путаница. Понятие IP маршрутизация имеет два смысла:
1) в IP маршрутизацию входит Ethernet IP NAT и TCP и UDP. Это администраторы и прочие неучи.
2) в IP маршрутизацию входит Ethernet IP. Научное понятие. Используемое в маршрутизаторах.
Что-бы не было обидно первое можно назвать обобщённым понятием маршрутизации. А второе частным случаем маршрутизации.

Цитата HighMan @ 27.11.16, 15:03

Это откуда? Какой ,нафиг, внешний IP??? Как быть с моей самопостроенной сети? Она так же получает внешний IP???

Это я немного увлёкся про IP-маршрутизацию на Win-сервере с DSL- подключениями.
Внешний IP?
Как устроен билинг в вашей сети? VPN используете? NetTraffic, UserGaye? Машрутизатор прова на чём построен? Windows, Linux, KWF Cisco, D-Link. А также домашний роутер у вас какой?

Сообщение отредактировано: Pavia - 27.11.16, 15:43

[HighMan]

Pavia
Такс.. Давайте разбираться.
1. Посмотрите формат пакета IP.
Много разных полей, но за отправителя и получателя отвечают всего 2
sourse ip
desination ip
Я предполагаю, что еще identification
2. формат UDP пакета
Добавились source port & destination port
Ну и дополнительная информация не имеющая отношения к маршрутизации
3. ТСР
Что тут добавилось для маршрутизации?

Что-то вроде:

struct ip_packet{
 // Служебная информация не относящаяся к маршрутизации
 DWORD source_ip;
 DWORD destination_ip;
 WORD  identification;
 //Данные
}
struct udp_packet{
 struct ip_packet;
 //Не относящаяся к маршрутизации информация
 WORD source_port;
 WORD destination_port;
 //Не относящаяся к маршрутизации информация
}
struct tcp_packet{
 struct udp_packet;
 //Не относящаяся к маршрутизации информация
}

Это не совсем точная, очень приблизительная, схема TCP пакета.
Именно в TCP нет, вообще, ничего, относящегося к маршрутизации.
В UDP тоже. Не уверен что порты участвуют, но пусть будут.
Только в IP есть адреса отправителя и получателя.
Где? Где массив IP до белого маскардинга?
Может присутствует еще некий секретный протокол в котором есть вся эта инфа?
Каким образом, основываясь на каких данных, пакет от "исходников" достигает до моего компа (серый IP)????
tcpdump может показать весь пакет, дошедший до сервера с белым IP. Где там массив ip адресов? Там их 2! Один - белый IP сервера, второй белый IP шлюза провайдера. Еще порты. Где хоть какая-то информации о 192.168.0.2, который является настоящим автором запроса?

Цитата

NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.

Это не протокол. Это МЕХАНИЗМ в TCP/IP.

Не исправляю, написанное, а исправляюсь сам.
Не правильная схема структур. Совсем.

struct ip_packet{
 // Свои служебные поля
 // char data[];
}

В data может находится udp_packet, в data udp_packet - tcp_packet;
Может находится, а может и нет. Начальный уровень - ip_packet. Он может содержать или нет udp_packet. В udp_packet может содержаться tcp_packet.

Сообщение отредактировано: HighMan - 27.11.16, 17:24