http://freesource.info/wiki/AfanasovDmitry/Сеть/ЯдрёныйПутьПакета History/revisions of FreeSource/AfanasovDmitry/Сеть/ЯдрёныйПутьПакета en-us http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa/show?time=2008-03-26+12%3A21%3A44 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".afanasovdmitry.set_.jadrjonyjjput_paketa" href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa&" class="">/Afanasov&nbsp;Dmitry&nbsp;/&nbsp;Сеть&nbsp;/&nbsp;Ядрёный&nbsp;Путь&nbsp;Пакета</a> за <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2008-03-26+12%3A21%3A44">2008-03-26 12:21:44</a> и <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa">2008-03-26 12:25:42</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">cat&nbsp;/etc/protocols | grep -i &laquo;encap\|gre&raquo;<br /> etherip 97 ETHERIP # Ethernet-within-IP Encapsulation<br /> pipe 131 PIPE # Private IP&nbsp;Encapsulation within IP</div><br /> <b>Удалено:</b><br /> <div class="deletions">cat&nbsp;/etc/protocols | grep &laquo;encap\|gre&raquo;</div></div> http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa/show?time=2007-08-30+08%3A23%3A30 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa&" class="">/Afanasov&nbsp;Dmitry&nbsp;/&nbsp;Сеть&nbsp;/&nbsp;Ядрёный&nbsp;Путь&nbsp;Пакета</a> за <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2007-08-30+08%3A23%3A30">2007-08-30 08:23:30</a> и <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2008-03-26+12%3A21%3A44">2008-03-26 12:21:44</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">С&nbsp;самого начала для&nbsp;понимания adv&nbsp;linux routing мне&nbsp;не&nbsp;хватало понимания, что&nbsp;вообще происходит с&nbsp;пакетов в&nbsp;ядре linux. Так&nbsp;как мне&nbsp;не&nbsp;хочется травмировать свою же&nbsp;психику, в&nbsp;код я&nbsp;не лез, хотя, как&nbsp;говорят, там&nbsp;&laquo;самая полная документация&raquo; :) Но&nbsp;то что&nbsp;понял постараюсь выложить здесь.<a name="h1244-1"></a><h2> 2000 Вступление </h2> Сначала определимся, что&nbsp;такое пакет. Вообще есть два&nbsp;вида &laquo;маршрутизации&raquo; &ndash; связи двух точек. <em>Коммутация соединений</em> и&nbsp;<em>коммутация пакетов</em>. В&nbsp;первом случае у&nbsp;нас устанавливается физическое подключение (которое характеризуется напряжением, сопротивлением, ещё кучей радиоэлектронных понятий), и&nbsp;электрончики по&nbsp;нему бегают до&nbsp;обрыва соединения. Банальный пример: телефоны. Такие &laquo;маршрутизаторы&raquo; называют ещё АТС.<br /> Во&nbsp;втором же&nbsp;случае физическое соединение присутствует постоянно, просто связующая аппаратура перебрасывает не&nbsp;все &laquo;электрончики&raquo; от&nbsp;одной соединённой точки к&nbsp;другой, а&nbsp;ещё и&nbsp;пытается решить на&nbsp;основе дополнительных данных, что&nbsp;несут эти&nbsp;самые &laquo;электрончики&raquo;, в&nbsp;какое соединение их&nbsp;бросать. Это&nbsp;локальная сеть; и&nbsp;занимаются описанным делом маршрутизаторы. Ethernet Switch'и тоже в&nbsp;какой-то мере, так&nbsp;как они&nbsp;анализируют ethernet frame'ы для&nbsp;выбора порта, куда выкидывать полученный frame.<br /> <span class="cite">Для работы <em>пакетной коммутации</em> соединения уже&nbsp;дожны быть скоммутированы, то&nbsp;есть <em>пакетная коммутация</em> работает <u>поверх</u> <em>коммутации соединений</em>. Что&nbsp;означает, что&nbsp;ваш ethernet провод должен быть воткнут в&nbsp;концентратор/коммутатор (hub/switch), в&nbsp;другую сетевую карту; АТС&nbsp;должна соеденить ваши модемы; etc.</span><br /> И&nbsp;наконец, рассматривается только <!--notypo-->Tcp/Ip<!--/notypo--> протокол. С&nbsp;остальными не&nbsp;работал, хотя давно хочу изучить netbios/smb.<br /> Вот&nbsp;сетевая железка у&nbsp;нас зафиксировала электромагнитную активность на&nbsp;своём входе. (в это&nbsp;время она&nbsp;ещё бывает подмигивает :). Так&nbsp;как железка умная, без&nbsp;чего при&nbsp;работе с&nbsp;пакетами ну&nbsp;просто никуда, то&nbsp;она из&nbsp;этой активности вытягивает <u>весь</u> пакет своего уровня. В&nbsp;ethernet это&nbsp;frame, в&nbsp;ATM ещё что-то, в&nbsp;X.25 &ndash; и&nbsp;вообще, пусть кто&nbsp;другой дополнит. Сам&nbsp;с&nbsp;удовольствием почитаю :) <br /> <ul><li> <em>широковещательные</em> (англ. broadcast). <br /> Суть их&nbsp;в том, что&nbsp;пакет (последовательность ноликов-единичек, электрических импульсов) доходят до&nbsp;<u>всех</u> подключенных в&nbsp;сеть (правильнее было бы&nbsp;сказать <em>коммутируемые</em>. Потому что, например, switch не&nbsp;пропустит пакет машине, которой он&nbsp;не предназначался. По&nbsp;крайней мере на&nbsp;это хочется надеятся :). И&nbsp;уже сетевое устройство решает, что&nbsp;с&nbsp;ним делать. Решает оно&nbsp;на&nbsp;основе <em>физического адреса</em> (метки?), что&nbsp;в&nbsp;таком случае обязательно сопровождает каждый пакет. В&nbsp;ethernet этот адрес обзывают <em>MAC-адресом</em> (от англ. Media Access Control — управление доступом к&nbsp;носителю). Если адрес не&nbsp;совпадает с&nbsp;указанным в&nbsp;памяти чипсета, то&nbsp;пакет игнорируется; если да, то&nbsp;пропускается дальше на&nbsp;следующий уровень обработки. <br /> Исключая один режим &ndash; <em>promisc</em> (promiscuous &ndash; безалаберный, беспорядочный, неразборчивый, разнородный, разношерстный, смешанный). В&nbsp;этом режиме устройство пропускает всё, что&nbsp;только видит. </li><li> <em>точка-точка</em> (англ. point-to-point) <br /> тут&nbsp;всё проще. Так&nbsp;как мы&nbsp;имеем лишь одно физическое соединение, и&nbsp;на другом конце <u>гарантировано</u> находится нужный peer (одно из&nbsp;значений слова peer &ndash; &laquo;равный, ровня&raquo;, предлагаю переводить, как&nbsp;&laquo;напарник, партнер&raquo;), то&nbsp;данные просто сбрасываются в&nbsp;физическую среду; причём я&nbsp;даже не&nbsp;уверен, что&nbsp;они имеют хоть какой-нибудь заголовок физического уровня. Поэтому ни&nbsp;в телефонной линии, ни&nbsp;в туннелях не&nbsp;существует <em>физического адреса</em>. Хотя нет, существует: в&nbsp;туннеле это&nbsp;ip&nbsp;peer'а, а&nbsp;ppp &ndash; телефонный номер :) То&nbsp;есть эти&nbsp;адреса характеризуют предшествующую маршрутизации <em>коммутацию соединений</em>.</li></ul> Хардварная (железная, канальный с&nbsp;физическим уровнем) часть передала наверх пришедшие данные, удалив по&nbsp;пути свои заголовки. Теперь то, что&nbsp;для уровнем ниже было данными опять расщепляется на&nbsp;заголовок/данные. <br /> В&nbsp;ethernet frame, как&nbsp;я&nbsp;помню (надо уточнить) заголовок содержит ещё и&nbsp;протокол, что&nbsp;идёт на&nbsp;следующем уровне. Как&nbsp;ip&nbsp;заголовок содержит, кто&nbsp;идёт за&nbsp;ним &ndash; udp, tcp, gre. На&nbsp;основе того номера определяется, кто&nbsp;будет анализировать всё это&nbsp;дело дальше.<br /> На&nbsp;данном этапе пакет анализируется целиком, часто вплоть до&nbsp;прикладного уровня &ndash; сокетов. Исключения raw&nbsp;sockets, что&nbsp;читают сразу из&nbsp;интерфейса. Происходит это&nbsp;следущим образом<br /> Анализ <!--notypo-->tcp/ip<!--/notypo-->: после расшифровки ip&nbsp;заголовка, запускается анализ следующего в&nbsp;зависимости от&nbsp;указанного протокола. Как&nbsp;происходит анализ tcз, udp, icmp нас&nbsp;сейчас не&nbsp;волнует, интересен анализ 47 (gre) и&nbsp;98 (ipip). Это&nbsp;туннели. Здесь данные после ip&nbsp;заголовка просто напросто передаются заново вниз, только от&nbsp;имени другого интерфейса, и&nbsp;происходит уже&nbsp;анализ как&nbsp;бы&nbsp;с нуля.<a name="h1244-2"></a><h2> Замечание к&nbsp;предыдущему абзацу from Черносов Денис 26.03.2008</h2> В&nbsp;нескольких статьях наткнулся на&nbsp;разные номера протоколов для&nbsp;туннелей. Обратился к&nbsp;первоисточнику:<br /> <!--notypo--><textarea class="code" rows="6" readonly="readonly">cat /etc/protocols | grep &quot;encap\|gre&quot; ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'') gre 47 GRE # Generic Routing Encapsulation ipip 94 IPIP # Yet Another IP encapsulation encap 98 ENCAP # Yet Another IP encapsulation</textarea><!--/notypo--><br /> Так&nbsp;что, если у&nbsp;кого-то будут затыки со&nbsp;связью, проверьте и&nbsp;этот момент, какой именно протокол нужно разрешить в&nbsp;вашем случае...</div><br /> <b>Удалено:</b><br /> <div class="deletions">С&nbsp;самого начала для&nbsp;понимания adv&nbsp;linux routing мне&nbsp;не&nbsp;хватало понимания, что&nbsp;вообще происходлит с&nbsp;пакетов в&nbsp;ядре linux. Так&nbsp;как мне&nbsp;не&nbsp;хочется травмировать свою же&nbsp;психику, в&nbsp;код я&nbsp;не лез, хотя, как&nbsp;говорят, там&nbsp;&laquo;самая полная документация&raquo; :) Но&nbsp;то что&nbsp;понял постараюсь выложить здесь. === 2000 Вступление ===<br /> Сначала определимся, что&nbsp;такое пакет. Вообще есть два&nbsp;вида &laquo;маршрутизации&raquo; &ndash; связи двух точек. <em>Коммутация соединений</em> и&nbsp;<em>коммутация пакетов</em>. В&nbsp;первом случае у&nbsp;нас устанавливается физическое подключение (которое характеризуется напряжением, сопротивлением, ещё кучей радиоэелектронных понятий), и&nbsp;электрончики по&nbsp;нему бегают до&nbsp;обрыва соединения. Банальный пример: телефоны. Такие &laquo;маршрутизаторы&raquo; называеют ещё АТС.<br /> Во&nbsp;втором же&nbsp;случае физическое соединение присутствует постоянно, просто связующая аппаратура перебрасывает не&nbsp;все &laquo;электрончики&raquo; от&nbsp;одной соединённой точки к&nbsp;другой, а&nbsp;ещё и&nbsp;пытаеся решить на&nbsp;основе дополнительных данных, что&nbsp;несут эти&nbsp;самые &laquo;элетрончики&raquo;, в&nbsp;какое соединение их&nbsp;бросать. Это&nbsp;локальная сеть; и&nbsp;занимаются описанным делом маршрутизаторы. Ethernet Switch'и тоже в&nbsp;какой-то мере, так&nbsp;как они&nbsp;анализируют ethernet frame'ы для&nbsp;выбора порта, куда выкидывать полученный frame.<br /> <span class="cite">Для работы <em>пакетной коммутации</em> соединения уже&nbsp;дожны быть скоммутированы, то&nbsp;есть <em>пакетная коммутация</em> работает <u>поверх</u> <em>коммутации соединений</em>. Что&nbsp;означает, что&nbsp;ваш ethernet провод должен быть вокнут в&nbsp;концентратор/коммутатор (hub/switch), в&nbsp;другую сетевую карту; АТС&nbsp;должна соеденить ваши модемы; etc.</span><br /> И&nbsp;наконец, рассматривается только <!--notypo-->Tcp/Ip<!--/notypo--> протокол. С&nbsp;отсальными не&nbsp;работал, хотя давно хочу изучить netbios/smb.<br /> Вот&nbsp;сетевая железка у&nbsp;нас зафиксировала электромагнитную активность на&nbsp;своём входе. (в это&nbsp;время она&nbsp;ещё бывает подмиивает :). Так&nbsp;как железка умная, без&nbsp;чего при&nbsp;работе с&nbsp;пакетами ну&nbsp;просто никуда, то&nbsp;она из&nbsp;этой активности вытягивает <u>весь</u> пакет своего уровня. В&nbsp;ethernet это&nbsp;frame, в&nbsp;ATM ещё что-то, в&nbsp;X.25 &ndash; и&nbsp;вообще, пусть кто&nbsp;другой дополнит. Сам&nbsp;с&nbsp;удовольствием почитаю :) <br /> <ul><li> <em>широковещательные</em> (англ. broadcast). <br /> Суть их&nbsp;в том, что&nbsp;пакет (последовательность ноликов-единичек, электрических импульсов) доходят до&nbsp;<u>всех</u> подключенных в&nbsp;сеть (правильнее было бы&nbsp;сказать <em>коммутируемые</em>. Потому что, например, switch не&nbsp;пропустит пакет машине, которой он&nbsp;не предназначался. По&nbsp;крайней мере на&nbsp;это хочется надеятся :). И&nbsp;уже сетевое устройство решает, что&nbsp;с&nbsp;ним делать. Решает оно&nbsp;на&nbsp;основе <em>физического адреса</em> (метки?), что&nbsp;в&nbsp;таком случае обязательно сопровождает каждый пакет. В&nbsp;ethernet этот адрес обзывают <em>MAC-адресом</em> <span class="mark">(интересно, а&nbsp;как он&nbsp;рашифровывается?)</span>. Если адрес не&nbsp;совпадает с&nbsp;указанным в&nbsp;памяти чипсета, то&nbsp;пакет игнорируется; если да, то&nbsp;пропускатся дальше на&nbsp;ледующий уровень обработки. <br /> Исключая один режим &ndash; <em>promisc</em> (promiscuous &ndash; безалаберный, беспорядочный, неразборчивый, разнородный, разношерстный, смешанный). В&nbsp;этом режиме устройство пропускает всё, что&nbsp;только видит.<br /> </li><li> <em>точка-точка</em> (англ. point-to-point) <br /> тут&nbsp;всё проще. Так&nbsp;как мы&nbsp;имеем лишь одно физическое соединение, и&nbsp;на другом конце <u>гарантировано</u> находится нужный peer <span class="mark">(как перевести?)</span>, то&nbsp;данные просто сбрасываются в&nbsp;физическую среду; причём я&nbsp;даже не&nbsp;уверен, что&nbsp;они имеют хоть какой-нибудь заголовок физического уровня. Поэтому ни&nbsp;в телефонной линии, ни&nbsp;в туннелях не&nbsp;существует <em>физического адреса</em>. Хотя нет, существует: в&nbsp;туннеле это&nbsp;ip&nbsp;peer'а, а&nbsp;ppp &ndash; телефоный номер :) То&nbsp;есть эти&nbsp;адреса характеризуют предшествующую маршрутизации <em>коммутацию соединений</em>.</li></ul> Хардварная (железная, канальный с&nbsp;физическим уровнем) часть передала наверх пришедшие данные, удалив по&nbsp;пути свои загловки. Теперь то, что&nbsp;для уровнем ниже было данными опять расщепляется на&nbsp;заголовок/данные. <br /> В&nbsp;ethernet frame, как&nbsp;я&nbsp;помню (надо уточнить) загловок содержит ещё и&nbsp;протокол, что&nbsp;идёт на&nbsp;следующем уровне. Как&nbsp;ip&nbsp;заголовок содержит, кто&nbsp;идёт за&nbsp;ним &ndash; udp, tcp, gre. На&nbsp;основе того номера определяется, кто&nbsp;будет анализировать всё это&nbsp;дело дальше.<br /> На&nbsp;данном этапе пакет анализируется целиком, часто вплоть до&nbsp;прикладного уровня &ndash; сокетов. Исключения raw&nbsp;sockets, что&nbsp;читают сразу из&nbsp;интерфейса. Происзодит это&nbsp;следущим образом<br /> Анализ <!--notypo-->tcp/ip<!--/notypo-->: после расшифровки ip&nbsp;заголовка, запускается анализ следущего в&nbsp;зависимости от&nbsp;указанного протокола. Как&nbsp;происходит анализ tcз, udp, icmp нас&nbsp;сейчас не&nbsp;волнует, интересен анализ 47 (gre) и&nbsp;98 (ipip). Это&nbsp;туннели. Здесь данные после ip&nbsp;заголовка просто напросто передаются заного вниз, только от&nbsp;имени другого интерфейса, и&nbsp;проиходит уже&nbsp;анализ как&nbsp;бы&nbsp;с нуля.</div></div> http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa/show?time=2005-09-19+18%3A26%3A14 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa&" class="">/Afanasov&nbsp;Dmitry&nbsp;/&nbsp;Сеть&nbsp;/&nbsp;Ядрёный&nbsp;Путь&nbsp;Пакета</a> за <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2005-09-19+18%3A26%3A14">2005-09-19 18:26:14</a> и <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2007-08-30+08%3A23%3A30">2007-08-30 08:23:30</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">=== 2000 Вступление ===</div><br /> <b>Удалено:</b><br /> <div class="deletions"><a name="h1244-1"></a><h2> Вступление </h2></div></div> http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa/show?time=2005-09-19+17%3A55%3A57 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa&" class="">/Afanasov&nbsp;Dmitry&nbsp;/&nbsp;Сеть&nbsp;/&nbsp;Ядрёный&nbsp;Путь&nbsp;Пакета</a> за <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2005-09-19+17%3A55%3A57">2005-09-19 17:55:57</a> и <a href="http://freesource.info/wiki/AfanasovDmitry/Set'/JadrjonyjjPut'Paketa?time=2005-09-19+18%3A26%3A14">2005-09-19 18:26:14</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">На&nbsp;данном этапе пакет анализируется целиком, часто вплоть до&nbsp;прикладного уровня &ndash; сокетов. Исключения raw&nbsp;sockets, что&nbsp;читают сразу из&nbsp;интерфейса. Происзодит это&nbsp;следущим образом<br /> <ul><li> <strong>ppp</strong> интерфейс. Вся&nbsp;пакетина принимается демоном pppd. Из&nbsp;/dev/ttyS*, из&nbsp;pty (ssh соединение, например, pptpd подключение). Из&nbsp;него выдирается <!--notypo-->tcp/ip<!--/notypo--> пакет (в случае с&nbsp;параметром pty&nbsp;pppd сразу принимает <!--notypo-->tcp/ip<!--/notypo--> пакеты), затем через модули передаётся на&nbsp;уровень ядра. Ядро расшифровывает как&nbsp;обычно tcp/ip пакет. <br /> Pppd понимает только <!--notypo-->tcp/ip<!--/notypo--> пакеты. </li><li> <strong>ethernet</strong> интерфейс. Пакет принимается сразу ядром. Анализируется им&nbsp;же. Если это&nbsp;<!--notypo-->tcp/ip<!--/notypo--> пакет &ndash; как&nbsp;обычно. Если же&nbsp;другой &ndash; анализирует модуль этого &laquo;другого&raquo;, с&nbsp;чем я&nbsp;уже не&nbsp;работал. </li><li> <strong>tun/tap</strong>. </li><li> <strong>dvb</strong>. работает как&nbsp;обычный ethX.</li></ul> Анализ <!--notypo-->tcp/ip<!--/notypo-->: после расшифровки ip&nbsp;заголовка, запускается анализ следущего в&nbsp;зависимости от&nbsp;указанного протокола. Как&nbsp;происходит анализ tcз, udp, icmp нас&nbsp;сейчас не&nbsp;волнует, интересен анализ 47 (gre) и&nbsp;98 (ipip). Это&nbsp;туннели. Здесь данные после ip&nbsp;заголовка просто напросто передаются заного вниз, только от&nbsp;имени другого интерфейса, и&nbsp;проиходит уже&nbsp;анализ как&nbsp;бы&nbsp;с нуля.<a name="h1244-1"></a><h2> После анализа </h2> Всё, мы&nbsp;проанализировали пакет, заполнили структуру skb, и&nbsp;вот сдесь начинается самое интересное. Для&nbsp;ip&nbsp;протокола &ndash; остальные не&nbsp;рассматриваем.<a name="h1244-2"></a><h3> Netfilter hooks (iptables) </h3> Сейчас мы&nbsp;сразу попадаем в&nbsp;netfilter.</div></div>