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

[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 мбайт памяти.