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

[Akina]

Так, стоять... вот когда на элементарные вопросы отвечаешь, думать лень - и такая фигня в итоге получается...

HighMan, твои (да и не только - я в основном по тому же поводу пургу несу) проблемы в том, что во всех рассуждениях не учитываются те адреса, которые входят в Ethernet-пакет на 2 уровне. А их нельзя не учитывать... именно без их учёта и образуется тот недостаток адресов, который зримо не разруливается. Включи их во ВСЕ свои рассуждения - и всё станет легко и приятно.

[Pavia]

Akina
Термины. Я не просто сказал это обобщённое понятие маршрутизации, а это частное. Дело в том что обобщённое всё больше проникает и в интерфейсы маршрутизаторов и в книги.

[HighMan]

Цитата Akina @ 27.11.16, 17:03

Так, стоять... вот когда на элементарные вопросы отвечаешь, думать лень - и такая фигня в итоге получается...

HighMan, твои (да и не только - я в основном по тому же поводу пургу несу) проблемы в том, что во всех рассуждениях не учитываются те адреса, которые входят в Ethernet-пакет на 2 уровне. А их нельзя не учитывать... именно без их учёта и образуется тот недостаток адресов, который зримо не разруливается. Включи их во ВСЕ свои рассуждения - и всё станет легко и приятно.

Погодите. Давайте определимся, что значит "Ethernet-пакет 2 уровня"?
Я, что-то совсем запутался.

[^D^ima]

Фига вы тут развели....

HighMan
Если вы админ со стажем то вам грешно такие вопросы задавать.
Вы должно быть знаете модель OSI, слышали про инкапсуляцию, знаете что в IP пакет запаковывается TCP\UDP. Знаете что в IP есть адрес назначения и адрес отправителя, в TCP\UDP есть порт отправителя и порт получателя. Слышали такую фразу как стек протоколов TCP\IP. Так вот интернет работает на стеке протоколов TCP\IP, TCP\UDP.

Так вот как это работает:
1 Любое приложение которое передает пакет отрывает сокет(это связка IP и порт(не важно TCP или UDP) )
2 Отсылается пакет с этими данными на маршрутизатор(IP\порт отправителя, IP\порт получателя)
3 далее маршрутизатор создает таблицу, где записывает порт\IP источника и порт IP назначения куда дальше маршрутизатор отослал пакет
4 Сервер передает данные в ответ последнему маршрутизатору, где меняется обратно IP\порт отправителя, IP\порт получателя. и так далее
5 Если спустя какое-то время маршрутизатор не заметил прямых\обратных пакетов, то запись в таблице удаляется.

Исходящий порт система выдает приложениям из ещё не занятых 1-65535. Входящий порт как IP адрес публичный. Стандартный 80 для http, 443 для https, 21 ftp и т.д.

[HighMan]

Цитата ^D^ima @ 27.11.16, 17:57

Фига вы тут развели....

HighMan
Если вы админ со стажем то вам грешно такие вопросы задавать.
Вы должно быть знаете модель OSI, слышали про инкапсуляцию, знаете что в IP пакет запаковывается TCP\UDP. Знаете что в IP есть адрес назначения и адрес отправителя, в TCP\UDP есть порт отправителя и порт получателя. Слышали такую фразу как стек протоколов TCP\IP. Так вот интернет работает на стеке протоколов TCP\IP, TCP\UDP.

Так вот как это работает:
1 Любое приложение которое передает пакет отрывает сокет(это связка IP и порт(не важно TCP или UDP) )
2 Отсылается пакет с этими данными на маршрутизатор(IP\порт отправителя, IP\порт получателя)
3 далее маршрутизатор создает таблицу, где записывает порт\IP источника и порт IP назначения куда дальше маршрутизатор отослал пакет
4 Сервер передает данные в ответ последнему маршрутизатору, где меняется обратно IP\порт отправителя, IP\порт получателя. и так далее
5 Если спустя какое-то время маршрутизатор не заметил прямых\обратных пакетов, то запись в таблице удаляется.

Исходящий порт система выдает приложениям из ещё не занятых 1-65535. Входящий порт как IP адрес публичный. Стандартный 80 для http, 443 для https, 21 ftp и т.д.

Ну дык Вы как раз и пересказали то, что предполагал я в сообщ. 5.
Только я не уверен, что в процессе маршрутизации участвуют порты. Моя неуверенность основана на том, что в IP пакете нет полей src port и dst port. Эти порты появляются лишь в UDP. Что же получается? Без UDP надстройки IP пакет не может маршрутизироваться?
Вот смотрите, есть ping. Он отсылает icmp запросы. За ответ ping отвечает какой icmp port?

-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

Эта конструкция позволяет отвечать на пинги.
Тут вроде нет никакого порта. Т.е. порт в маршрутизации не используется. ИМХО.

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

[^D^ima]

Я ещё не сказал что в публичных сетях маршрутизаторы не строят таблицы а передает пакет с неизменным адресом и портом отправителя.
Протоколы не знают что несут за информацию в себе, это как матрешка, каждый уровень не ведает про уровни выше и ниже, ип маршрутизация это всего лишь передача пакета по таблице марршиутизации пока пакет не достигнет назначения, пакет обратно так же проходит глобальную сеть пока не доберется до маршрутизатор за котыр локальрая сеть, там уже действует NAT таблица,которой в ip 6 уже нет

Добавлено 27.11.16, 18:29
NAT - костыль который придумали когда стало ясно что на всех IP4 не хватает, а маршрутизацию как-то делать надо. Придумали частные адреса, NAT и т.п. Изначально все строилось только на IP маршрутизации(TCP и UDP при этом были все равно, т.к. это транспортные протоколы).

Задача IP доставить протокол до нужного интерфейса, tcp\udp до приложения

Добавлено 27.11.16, 18:32
Посмотрите выпуски сами https://www.youtube.com/watch?v=OtY-Z6_PDpU и передайте вашим горе-админам

[HighMan]

Насколько я понимаю

ping sources.ru

Пингует не ip+port а просто ip. При этом он прекрасно маршрутизируется.
И причем тут "мои горе-админы"?
Я, как бы, сам админ.
Про пространство белых ip я и написал, что source ip не меняется, кроме анонимных proxy. Маскардинг (подмена source ip) идёт в серых сетях и только в них нужно хранить куски маршрута.

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

[^D^ima]

Icmp тоже имеет порт по умолчанию, на который напрвляется запрос плюс поставьте wireshark и смотрите пакеты которы отсылаются, вм все станет понятно

[HighMan]

Цитата ^D^ima @ 27.11.16, 18:59

Icmp тоже имеет порт по умолчанию, на который напрвляется запрос плюс поставьте wireshark и смотрите пакеты которы отсылаются, вм все станет понятно

Какой icmp port отвечает за эхо ответы (ping)?
Насколько я помню, ping работает на "сырых" сокетах и при написании ping, порт не используется.

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

[^D^ima]

Я имел в виду что исмт отдельный протокол со своим номером(этоя все про микротик)) )

Добавлено 27.11.16, 19:06
Дети уснут, напишу

[Pavia]

HighMan

Цитата HighMan @ 27.11.16, 16:54

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

Таблица отвечающая за трансляцию адресов находится в ядре маршрутизатора и создаётся динамически. В соответствии с правилами в iptables.

Вот структура из линукса http://people.netfilter.org/rusty/ipchains/
struct masq {
unsigned long expires; /* Expiration timer */
char proto[20]; /* Which protocol are we talking? */
struct in_addr src, dst; /* Source and destination IP addresses */
unsigned short sport, dport; /* Source and destination ports */
unsigned short mport; /* Masqueraded port */
__u32 initseq; /* Add delta from this seq. on */
short delta; /* Delta in sequence numbers */
short pdelta; /* Delta in sequence numbers before last */
};

struct masq_timeout {
int tcp_timeout;
int tcp_fin_timeout;
int udp_timeout;
} timeouts;


IP-routing выполняется после прохождения NAT правил. И без участия портов. Только адрес назначения. На основе правил записанных в таблице route
Применяется маска к адресу назначения и сравнивается с адресом сети. Если сравнение прошло удачно то из строки берётся название интерфейса. Пакет отправляется на интерфейс, для простоты интерфейс это гнездо RJ-45.

[HighMan]

Цитата ^D^ima @ 27.11.16, 19:06

Я имел в виду что исмт отдельный протокол со своим номером(этоя все про микротик)) )

Угу. Канешна! Icmp "отдельный протокол"... Это такая же надстройка над IP, как и UDP.

Добавлено 27.11.16, 19:13

Цитата Pavia @ 27.11.16, 19:08

IP-routing выполняется после прохождения NAT правил. И без участия портов. Только адрес назначения. На основе правил записанных в таблице route
Применяется маска к адресу назначения и сравнивается с адресом сети. Если сравнение прошло удачно то из строки берётся название интерфейса. Пакет отправляется на интерфейс, для простоты интерфейс это гнездо RJ-45.

Ну так сообщение N5.
Я, не зная точно как это работает, стеоретезировал сам, а вы начали спорить.

[Pavia]

^D^ima
ICMP это отдельная песня. Он идёт без порта. Поэтому в масквардинге(MASQ) не участвует. Зато идёт через SNAT. Во вне подменяется адрес отправителя, а на ответный адрес получателя. Отслеживания жизни правил такое же как и у UDP вот тут через TTL.

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

[Akina]

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

Пингует не ip+port а просто ip.

Да ладно... просто ежели просто говорят "пинг", то имеют в виду "ICMP пинг" - что не отменяет возможности пингов иных типов. В т.ч. и TCP/UDP пинг - а там без порта никуда...

Цитата ^D^ima @ 27.11.16, 18:59

Icmp тоже имеет порт по умолчанию

У ICMP нет порта, есть тип. Внутри типа - код. Да, если это назвать портом, беды особой не будет, но и не все поймут, о чём речь.

[Akina]

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

Итак, на его сетевой интерфейс падает некий сетевой пакет.

Первое, что он сделает - это посмотрит адрес назначения (dest) в Ethernet-пакете. МАС-адрес. И если не обнаружит там свой адрес (точнее, адрес, который, по мнению этого узла, является его локальным адресом, а в большинстве реализаций не только локальным, но и привязанным именно к этому интерфейсу), то со спокойной душой он опустит этот пакет в корзину и забудет о его существовании. Да, есть как promiscuous mode, так и всякоразные MitM, но оно требует отдельного рассмотрения. А если обнаружил? тогда он выковырнет из пакета инкапсулированный туда пакет протокола более высокого уровня (IP), и отдаст IP-стеку - разбирайся, мол. И только с этого момента собственно начинается маршрутизация, о которой мы говорим.

Я сознательно опускаю процессы, которые не касаются происходящего в недрах хаба/свича/коммутатора, где пакет не транслируется на более высокие уровни, хотя по некоторым признакам иногда их и можно посчитать маршрутизацией.

И теперь этот пакет свалится на интерфейс (этот или другой) этого узла лишь тогда, когда маршрутизация собственно закончится. Он может быть почти таким же, а может и измениться до полной неузнаваемости (скажем, если узел является VPN-сервером или там HTTPS-проксёй). Но это неважно.

Сообщение отредактировано: Akina - 27.11.16, 20:01

[HighMan]

Цитата Akina @ 27.11.16, 19:29

Да ладно... просто ежели просто говорят "пинг", то имеют в виду "ICMP пинг" - что не отменяет возможности пингов иных типов. В т.ч. и TCP/UDP пинг - а там без порта никуда...

Обратите внимание, что я написал

ping sources.ru

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

[^D^ima]

Цитата HighMan @ 27.11.16, 19:09

Icmp "отдельный протокол"... Это такая же надстройка над IP, как и UDP.

Что значит надстройка?
Ещё скажите что IP надстройка над Ethernet фреймом.

Про ICMP если интересно подробно написано тут о том как он проходит NAT:
http://www.osp.ru/lan/2002/12/135560/

Но это те редкие протоколы, которые не используют TCP\UDP.

Ещё раз подчеркну IP маршрутизации без разницы какие данные каких протоколов она в себе несет.

[Akina]

Цитата HighMan @ 27.11.16, 19:56

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

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

Что примечательно - классически IP-стек не знает, и тем более не учитывает, от какого именно интерфейса (и какого адреса этого интерфейса, ежели их несколько) этот пакет поступил на обработку.

В случае простой маршрутизации стек берёт адрес назначения, и по своим таблицам маршрутизации определяет, через какой интерфейс и какой адрес на этом интерфейсе следует отправить пакет, чтобы он достиг указанного адреса назначения. Определив, он передаст этот пакет драйверу интерфейса, а тот аккуратно упакует пакет IP в пакет Eth, укажет там в качестве адреса источника cвой адрес, в качестве приёмника сообщённый стеком, и вывалит его в среду передачи.

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

Очень показателен как раз случай маршрутизации сквозь NAT. Из-за NAT серый адрес легко отсылает пакет во внешний мир по причине однозначности маршрутизирования, и при этом на маршрутизаторе формируется сеанс, канал, по которому пакеты ходят как оттуда, так и туда, а по совокупности характеристик (адрес+порт) как раз определяется, в какой из каналов следует пихать пришедший ответный пакет, чтобы вернуть его правильному получателю. А если подходящий канал не найден (его нет, или он сброшен по каким-то причинам), то и пакет отправлять некуда - именно поэтому Nat и не проходится снаружи внутрь.

Сообщение отредактировано: Akina - 27.11.16, 20:08

[Pavia]

Цитата HighMan @ 27.11.16, 19:56

Обратите внимание, что я написал

Это вы плохо линукс знаете.

Цитата HighMan @ 27.11.16, 19:56

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

Да ладно не так уж и сложно. В сообщении №5 вы всё описали самостоятельно. Только несколько ошибок.
Осталось исключить исторические казусы. Различие в терминологии. Различия в воплощениях на разных железках и программах.

Учесть что для разных протоколов всё работает несколько иначе. Понять какие решения сделаны для устойчивости системы и для защиты от атак. Не просто понять но и добавить в нашу модель.

И чуть не забыл что надо различать ещё 3 вида NAT: DNAT, SNAT, MASQ

Помимо прочего надо познакомится с iptables.

[HighMan]

Цитата Akina @ 27.11.16, 19:49

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

Итак, на его сетевой интерфейс падает некий сетевой пакет.

Первое, что он сделает - это посмотрит адрес назначения (dest) в Ethernet-пакете. И если не обнаружит там свой адрес (точнее, адрес, который, по мнению этого узла, является его локальным адресом, а в большинстве реализаций не только локальным, но и привязанным именно к этому интерфейсу), то со спокойной душой он опустит этот пакет в корзину и забудет о его существовании. Да, есть как promiscuous mode, так и всякоразные MitM, но оно требует отдельного рассмотрения. А если обнаружил? тогда он выковырнет из IP-пакета инкапсулированный туда пакет протокола более высокого уровня (TCP/UDP/ICMP/etc.), и отдаст IP-стеку - разбирайся, мол. И только с этого момента собственно начинается маршрутизация, о которой мы говорим.

Я сознательно опускаю процессы, которые не касаются происходящего в недрах хаба/свича/коммутатора, где пакет не транслируется на более высокие уровни, хотя по некоторым признакам иногда их и можно посчитать маршрутизацией.

И теперь этот пакет свалится на интерфейс (этот или другой) этого узла лишь тогда, когда маршрутизация собственно закончится. Он может быть почти таким же, а может и измениться до полной неузнаваемости (скажем, если узел является VPN-сервером или там HTTPS-проксёй). Но это неважно.

Да, мы забыли - в том пакете, который пришёл, был ещё один адрес - адрес источника. Но он в обычных условиях никому не нужен и будет благополучно выброшен без рассмотрения при экстракции пакета 3 уровня. Учтён он будет лишь в случае многотабличной маршрутизации - но это отдельная песня.

Мля... Куда Вас снова понесло?
192.168.0.2 посылает пакет на sources.ru и ждёт ответ.
Пакет дошёл до 192.168.0.1/10.10.0.100 и тот поменял в ip пакете source ip, записав туда 10.10.0.100 и запомнил, что 192.168.0.2 лезет на исходники. Дальше он отправляет уже модифицированный пакет на gateway провайдера 10.10.0.1. Дальше, допустим, он сразу передаётся непосредственно в интернет через 1.1.1.1. Тогда шлюз запоминает, что 10.10.0.100 лезет на исходники и запоминает это, исправляет source ip на 1.1.1.1 и отсылает на исходники.
Тут пошла уже белая сеть и ни кто уже не модифицирует адреса.
Пакет доходит до исходников с sources ip 1.1.1.1.
Исходники отвечают на ip 1.1.1.1. Ни о каких 192.168.0.2, 10.10.0.100 он понятия не имеет. Он получил пакет с 1.1.1.1 и ему же ответил.
Пакет приходит на 1.1.1.1 и... Шлюзу он нафиг не нужен. Он смотрит свои сохраненные таблицы и ищет кто же лез на исходники. Находит 10.10.0.100, отсылает ему полученный пакет, заменив destination ip с 1.1.1.1 на 10.10.0.100, после чего удалил эту таблицу. 10.10.0.100 смотрит свои сохраненные таблицы и узнает, что пакет этот нужен 192.168.0.2, отсылает пакет изменив destination ip на 192.168.0.2, и стирает таблицу у себя. Пакет с исходников достиг получателя.

[^D^ima]

HighMan
Просмотрите несколько серий видео что я написал, если будут вопросы, пишите.

[HighMan]

Цитата Pavia @ 27.11.16, 15:38

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

Цитата Pavia @ 27.11.16, 15:38

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

Цитата Pavia @ 27.11.16, 15:38

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

Вроде пришли к тому, что порт в маршрутизации не участвует.
Нет маршрутизации TCP и UDP. Нет маршрутизации ICMP. Есть IP маршрутизация.
То что Linux придумывает TCP и UDP маршрутизацию - это липа. Таким образом он дает Вам возможность прописать различные правила для разных протоколов, являющимися всего лишь надстройками над IP протоколом.
TCP, UDP, ICMP & etc не маршрутизируются. Маршрутизируется лишь IP. Это как грузовик-контейнеровоз. Сами контейнеры никуда двигаться не могут. Их может двигать лишь самоходное транспортное средство. Предположим, что это грузовик-контейнеровоз. Этот грузовик подчиняется правилам движения. Грузовик, а не контейнеры! В нашем случае: грузовиком является ip protocol. И все правила распространяются на него, а не на контейнеры.
Контейнеры может не принять получатель и он не пустит к себе грузовик с контейнерами, а не сами контейнеры. Так же и iptables. Он на основании контейнеров пускает или не пускает ip протокол с надстройками.

Цитата

Помимо прочего надо познакомится с iptables.

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

[Pavia]

Цитата HighMan @ 27.11.16, 20:45

Вроде пришли к тому, что порт в маршрутизации не участвует.

Всё верно. Вот где в таблице маршрутизации порт? А нет его тут.

admin@RT-N10PV2:/tmp/home/root# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.7     netgateway      255.255.255.255 UGH   1      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.30.0    *               255.255.255.0   U     0      0        0 eth0
192.168.0.0     netgateway      255.255.0.0     UG    1      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         netgateway      0.0.0.0         UG    0      0        0 ppp0
default         netgateway      0.0.0.0         UG    1      0        0 eth0

[grgdvo]

HighMan,
Не путайте маршрутизацию и NAT.
Да, действительно классическая машрутизация происходит на сетевом уровне (только протокол IP, порты не учитываются), но маршрутизация (в классическом ее понимании) отвечает только за определение следующего интерфейса на маршуртазаторе, через который пакет должен отправиться дальше по Сети. Все остальное, считайте, это фильтрация и преобразование ПАКЕТОВ (еще правда есть policy routing, qos, и там стока еще наворотили).

Так вот, трансляция адресов это отдельная функция маршрутизатора, которая происходит ДО и/или ПОСЛЕ принятия решения о маршрутизации (то есть, когда станет известно, куда будет направлен пакет), и которая, действительно, знает (следит) за состоянием каждой TCP/UDP сессии (Akina, где-то выше об этом сказал).

Сотоветственно, в прямом направлении на стадии "после маршрутизации" сработает Source NAT (подменили лоакльный адрес источника на 1.1.1.1, так как уже знаем через какой интерфейс пойдет пакет, запомнили эту трансляции в отдельной таблице, которая не связана с таблицей маршрутизации).
В обратно направлении, на стадии "до маршрутизации" произойдет обратная подмена (автоматически адрес получаетля 1.1.1.1 меняем на локальный адрес по имеющейся записи в таблице NAT) и дальше уже пакет маршрутизируется на локальный интерфейс и отправляется вам на компьютер.

Срок жизини записи в таблице трансляции зависит от настроек NAT и он никак НЕ СВЯЗАН с TTL ip-пакета. TTL обозначает количество маршрутизаторов, которые прошел пакет (их может быть не больше 255). Пакет с TTL=0 должен быть отброшен. По умолчанию все маршрутизаторы так и делают.

И вы соверешенно правы, что при трансляции трафик может быть направлен Вам по ошибке.
Да, для перегруженных маршрутизаторов/сетей такое может происходит.
Это свидетельствует о том, что либо пользователям пора давать по башке, чтобы не качали торенты, либо пришло время посмотреть на возможности NAT вашего марщрутизатора и задать себе вопрос, что настроено не так?!

Сообщение отредактировано: grgdvo - 27.11.16, 21:26

[^D^ima]

HighMan
Вопорос ваш тогда в чем?

[Akina]

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

Куда Вас снова понесло?

Если Вас уже не интересует исходный вопрос, то об этом можно было и сказать...

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

Он смотрит свои сохраненные таблицы и ищет кто же лез на исходники. Находит 10.10.0.100, отсылает ему полученный пакет, заменив destination ip с 1.1.1.1 на 10.10.0.100, после чего удалил эту таблицу. 10.10.0.100 смотрит свои сохраненные таблицы и узнает, что пакет этот нужен 192.168.0.2, отсылает пакет изменив destination ip на 192.168.0.2, и стирает таблицу у себя.

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

[HighMan]

Цитата Akina @ 28.11.16, 04:53

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

Это мои фантазии. Основано на измышления на заданную тему.
Дело в том, что у деловых роутеров совсем не много памяти и хранить кучу таблиц маршрутов им проблематично. Потому, ИМХО, они могут удалять отработавшую таблицу сразу по поступлении ответа. Новый запрос - снова создаётся таблица.
Вполне допускаю, что они отслеживают TCP соединения и держат таблицу до его закрытия.
Роутеры дороже имеют памяти больше, но и нагрузка на них куда выше. Тот же шлюз нашего провайдера, наверное используется для отопления самолётного ангара

[Akina]

Цитата HighMan @ 28.11.16, 10:17

Потому, ИМХО, они могут удалять отработавшую таблицу сразу по поступлении ответа. Новый запрос - снова создаётся таблица.

Установленная связь не требует запроса на каждый чих. Канал пробит - и достаточно, по нему поскакал трафик.

Цитата HighMan @ 28.11.16, 10:17

у деловых роутеров совсем не много памяти и хранить кучу таблиц маршрутов им проблематично.

Даже у самых убогеньких роутеров размер таблицы соединений составляет несколько тысяч записей. Для пары десятков (а это очень дофига для аппаратуры сохо-класса) клиентов это более чем достаточно, чтобы не сильно экономить и удалять каналы по тайм-ауту, и весьма щадящему, или вообще по LRU. А если клиентов сотня, то и оборудование должно быть другого уровня. И с другим количеством памяти.

[Pavia]

HighMan

Цитата HighMan @ 28.11.16, 10:17

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

http://www.dlink.ru/ru/products/6/1380_b.html
Параллельно держит 25 000 сессий. И новых сессий 2 000. Такой шлюз может обслуживать до 2 тысяч клиентов. По 12 сессий на нос.
При этом потребление всего 19 вт. Ангар вы не отопите.
У меня сейчас 12 сессий открыто Win XP обычно ограничивает до 100.
Памяти надо чучуть структуру на прошллой странице я приводил. 25 000*40 байт=1 мбайт памяти.