Редактирование: UNИX, осень 2008, 07 лекция (от 12 ноября)

* '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_11_12.ogg

= Лекция =

== Вступление ==

Не говорили про IPv6 (но был доклад о нем).

== PPP ==

PPP - протокол интерфейсного уровня.

Итак, PPP (Point-to-Point Protocol).

=== Проблемы ===

Нужен только поток байтов в обе стороны.

=== pty/ttyP ===

Еще одно часто встречающее место — pptp (Point-to-point tunneling protocol).

=== Туннелирование. GRE. ===

=== L2TP (Level 2 Tunneling Protocol) ===

== IPSec (IP Security) ==

Мы полностью шифруем весь IP-пакет вместе с заголовками, к нему присобачивается IPSec-пакет и новый IP-заголовок.

== Протокол ICMP (Internet Control Message Protocol) ==

В основном — запросы и ответы.

На всякие ситуации, связанные с той или иной неработоспособностью сетевого протокола, существует ICMP запросы.

 

=== Утилита ping ===

Если на сервере есть сайт, можно попробовать постучаться на 80 порт.

=== Утилита traceroute ===

=== Need to fragment ===

* В IPv4 есть фрагментация пакета, если он не влезает.

* В IPv6 нет фрагментации IP-пакета. Вместо этого клиенты обязаны использовать механизм MTU path discovery.

 

Для того, чтобы не происходила ситуация, при которой фрейм приходит 1500, и нужно было послать 1492 и 8 байт.

 

=== ICMP зарезан ===

= Конспект eSyr'a =

<div style="font-size:50%">

Отстутпление номер 1.

Когда мы гворили про протоколы более низкого, интерф., лектор рассказал про то, что бывает Eth, бывают другие апп. реализации, такие прот., что ниже апп. уровен, а ещё начяал говорить про туннелирование. Быол сказано, что на уже инт. уровне есть привязка к железу, а есть привязка к несущ. вирт.сущности, напр., VLAN. На самом еле, говоря о прот. инт. уровня, мы , как кажется лектору, напрасно упустили PPP. Это протокол уровня интерфейсного.

В чём заадча: есть какая-то СПД, которая умеет эти данные передавать. Как именно, мы не знаем, или знаем, но стремимся забыть. Единст., что мы знаем: эта СПД не предн. для того, чтобы орг. поверх неё прот. более верхнего уровня, IP. Типичный пример: СПД без разделения пакетов. Иди если пакеты есть, но до них нет доступа. Да мало ли бывает СПД, которые не соотв. инт. уровню TCP/IP. Типичный пример: модем. Могут быть и другие варианты, когда у нас дост. высокоуровн. канал, по которому перед высокоур. данные. Ещё типичный пример: PPPoE. Ещё вариант: есть некая внутр. сеть, к которой есть доступ только по ssh, ваши действия: ssh в свободный интернет, и поверх него PPTP. Факт., PPP --- протокол инт. уровня. Большая часть док., которая пишется про инт. протокол, пи шется соотв. модели ISO/OSI, а не в соотв. модели TCP/IP.

Какие подстерегают проблемы: это протокол точка-точка. Нам не нужны все свойства конкр. СПД, например, орг. PPPoE, нам не нужны все св-ва интернета, дост. того, что они идут в одну, и возвр. обратно. И когда привяз. IP, то выдаётся адрес второго IP, с которым ведётся взаимод, это отр. в том числе в ip addr.

Проблема вторая. Если бы ситуация была такая, что мы просто заводим доп. инт. над двух дополн. машинах и заводим между ними тунель, то доп. никаких действий е нужно было. Но мы сейчас говорим именно об уровне инт., какие доп. действия нужно произвести, чтоы PPP работало. Тут возн. две проблемы: Пробелма первая --- кто из них главней. Особенно это зарактерно в ситуации, когда пресловутые PPP-соед орг. по иниц. клиента, когда он соед. с сервером.Например, подкл. по интернету. На момент созд. подкл. связь асимметрична, бывает, что симметрична. То есть, в PPP долно быть реализ. подмножество команд, ... эта связь асимметрична, и не очень понятно, кто из них главный (например, callback). То есть помимо процедур аутент., нужен механизм, чтобы разобрались, кто главнее кто кому что должен выдавать. Для этого существует automatic selfconfiguration (LCP). Бывает и такая ситуация, когда каждая у каждой спрашивает пароль, и только после этого соед. уст.

Кроме этого, как отд. механизм, должны происх. идент. и авт. В зависимости от длогина и пароля выд. те или иные конфиги, и это опять заложено в протоколе, до появления соединения.

Третье, что нужно здесь...

Вот эта самонастр., выдача IP, маршрутизация, DNS. То, что выда тся IP, можно понять. А вот то, что выд. маршрутизация, тоже понятно, потому что в зав. от того, какой ip выдан зависит то, что за ним лежит. А вот выдача DNS это довольно забавная штука,потому что она прыгает через одну голову. На самом деле, всё это есть в DHCP, и непонятно, зачем это здесь.

...

Когда речь идёт об аутен. и идент. необх. ещё и шифрование. Посколькку не все СПД одинаково хорошо защищены. Что касается шифр., то там тоже всё не вполне гладко, поск. бывает ситуация, когда вводятся олгин и пароль (CHAP), вся эта котовасия, если её вним. рассм, оказ. не вполне простой, кроме того, некоторые методы шифр. (напр., MS-CHAP) некриптостойкие, а исп. крипт. приводит к тому, что подд. её не все.

Что ещё осталось сказать про PPP. Видимо, ост. сказать след. Сущ. неск. реализаций PPP, исп. для VPN. Это PPTP и PPPOE. PPPOE --- PPP over Ethernet и факт. это исп. Eth в кач. той самой СПД, которая обесп. поток данных и больше ничего. Чтобы его орг., необх. опред. поддержка со стороны системы, которая разв. опр. рода фреймы в поток байт.

Есть инт. eth0, из него лезут пакеты, и нужен модуль ядра

Как это вообще. орг. в linux: некоторая программа, которая откр. устройство и пишет туда и читает, другим концом она может быть где угодно (придумывать, usb, ...). Открывая /dev/ptmx, обр. новое устр. в /dev/pts/0.

Потом уже совершенно обычный pppd лезет в это йстройство, видит там pptp, созд. устройство, которое соотв. уже интерфейсу.

Таким обр., мы тд. мух от котлет: есть задача преоб. чего угодно в поток байтов и есть задача рабоыт pptp.

Т.о., получается, что если тем метом, откуда дёрг. байтовый поток это Eth, ТО ПОЛЬЗА от ээтого неблоьшая. Если вы видете только внутр. сеть, то можно сказать, что можно подкл. по pppoe к машине, которая уже в интернет, и таким обр. решается задача шифрования и учёта траффика. VPN полноценный тут плохо, но доступ в интернет так делают.

Другой вариант — pptp. Это мех. объед в одну сеть разбр. по интернету машин. Оно популярно для орг. von до такой степени, что только это понимается по vpn в виндах. В чём смысл этого pptp:

* Настр. инт. на сервере

* Позв ... и при этому учитывать трафик

Это решается ppoe, но он только в лок. сетях. Наша задача: пробросить это вообще везде. След., нам надо подняться на уровнь выше. Как пост. люди, которые изобр. pptp. Есть более-менее расп. протокол GRE, изобр. Cisco, который позв. пробрасывать что угодно поверх ip-трафика.

Есть универс протокол GRE, который был созд. для прокидования цисочных туннелей. Про щифрование там речь не шла, только о туннелировании. При этом, как у всякого туннеля, идея очень простая. У нас есть какой-то траффик (например, ip), мы его засовываем в кач. payload, приделываем заголовок, приделываем к нему ip-заголовок и дальше это едет. Когда оно приезж., то видим обычн. ip-пакет.

Казалось бы, чего уж проще: разд. такие туннели польз. и хорошо им будет, ан нет. Мы с помощью gre не решили ни зад. аутент, ни шифр, ни учёта. Возвр. обратно.

Выясн., что этим туннелр. необх. как-то управлять.

При этом непонятно, почему нельзя было орг. gre+ppp.

Поэтому для упр. упр. траффик идёт на порт 1723 смервера. По рез. того, что происх. на порте 1723 происх. изм. в GRE-потоке. При этом по порту 1723 TCP-соед.

Но этого недост., поск. тут ещё нет шифрования, на 1723 исп. TLS, а поверх GRE в кач. расширения ож. реализ. шифрование.

Если трогать тему туннелирования и VPN, есть отдельный соверш. ...

Что позиц. в кач. замену этому делу: L2TP, Level 2 Tunneling Protocol, который взят их ipv6 (там он часть протокола). Идея в том, чтобы пробр. более-менее пригодный с точки зрения инт. уровня трафик.

Поддержка L2TP есть практ. везде, даже нек. провайдеры работают.

Есть ещё один вариант IPsec.

Отдельная соверш. песня. IPSec это часть ipv6, там это явл. частью стандарта, активно затаск. в ipv4.

Под linux есть две реализ. IPsec. Одна из них. KAME и взять из NetBSD, Вторая — StrongSWAN. Был ещё Fizzle(?) но он умер года 4 назад.

В теории, что это вообще такое: возм. навести security перед. данных прямо на ур. ip. Самая простая идея том, чтобы шифр. каждый пакет. Правда, сразу встаёт вопрос, мы как шифруем: вместе с заголовком или нет? Если не шифр. ip-заголовки, то это security или что? Это задача нерешаемая, точнее, решаемая, но двумя способами:

* Можно орг. туннель, это озн. след: мы полностью шифруем ip-пакет вместе с загловками, к нему пирсобачивается ipsec-пакет и новый ip-загловок. То есть, все пакеты туннельного вида будут выгл так: это пакет ipsec. Это спец. тип данных передаваемый по IP. Есть две проблемы: если раньше было напишано, что это icq, то это хорошо, но его не прочитает и нач. вашей служы без., тоде не сможет и очень обидится. Анлаогично могут поступить и нек. маршуритзации. То есть вер. того, что пакет могут зарезать. Кроме того, у туннеля должен быть второй конец.

* Транспортный режим. Шифр. только payload. Возм. также шифр. незначащих частей заголовка. Выглядит это след. образом: есть ip payload, и есть ip header, и что-то из этого шифруется. Достойнства: это выгл. как обычный ip-траффик. Проблем с марш. быть не должно. Недост. в том, что происз. утечка security, ибо откр. всякие поля заголовка.

Вторая пробл. более хитрая: написано ip security, а не ip crypt. Как следствие, должна быть идентификация. То есть, ipsec на самом деле довольно сложный: он опис. не только шифр., но и идент. А вот тут возн. проблемы. В случае туннеля всё очевидно. А в случае трансп. режима у нас очень плохо работает с NAt. Можно сделать что: либо откл. защиту заголовков и понадеяться на то, что шифр. надёжно. Ещё есть NAT-T где описано, как IPsec, окторый может проходить через NAT.

Есть есть комплект утилит racoon, которые исп. для идентификации. Есть протоколы для обмена первонач. ключами. Весь комплект действий по обесп. инент. связан со отд.к комплектом протоколов.

Таким обр. есть два уровня: снач. происх. удиентификаци абон., а потом они применяют один из видов шифрования.

Протокол ICMP и связ. с ним утилиты. На уровне IP есть ещё один важный протокол, Internet Control Message Protocol. Это служ. инф., предн. для передачи по сети какой-то служ. инф., не связ. с передачей данных. ICMP сам по себе крайне простой протокол, в нём порядка 20 разных типов сообщ, в осн. это либо icmp-запросы или icmp-ответы. Ответы вида:

* Недост. адресат

* Марш. неизвестна

* Редирект

И так далее. На всякие сит., связ. с нераб. или непр. исп. сети, предусм. сообщ. протокола ICMP.

Примером явл. утилита ping. Обычно ей польз. для выясн. доступности хоста, хотя если сист. администратор заредал ICMP-сообщ., которые явл. ответом. Внутри ICMP-запроса имеются уник. идент., который в том числе исп. для NAT.

Из тех типов ICMP-пакетов, которые рек. фильтровать:

* Сообщ. об ошибках, напр. Host Unreachable

* TTL Exceeded

Касаемо время жизни пакета, каждый раз, когда происх. маршр.,

ping ...

traceroute ...

ОСталось ровно одно: расска ещё об одном типе ICMP-ответов, которые нельзя резать — need to fragment. В ipv4 есть такая штука, как фрагментирование. Чтобы оно пост. не происходило, можно

* Запретить фрагментацию

* При необх. фрагм. посылается сообщ. need to fragment

В ipv6 такая ситуация по умолч. В ipv4 могут быть варианты, поск. в одном месте не фрагментировал и сказал need to fragment, а в другом (или том же самом) icmp режется.

В след раз поднимаемся на уровень выше.

</div>

{{UNИX, осень 2008}}

{{Lection-stub}}