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

[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