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

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 41 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

Лектор удивлен количеством народа.
Сегодня запланирован Internet Protocol (IP).
Чего мы еще не касались?
Мы рассказали, как устроены идентификация и маршрутизация в Интернете.
Поговорили про нестандартную маршрутизацию.
Не говорили про IPv6 (был доклад о нем).
Не говорили про протоколы уровня IP, которые существуют на этом уровне, не поднимаясь на транспортный уровень.

Про это расскажем с некоторыми отступлениями.
Когда мы говорили про протоколы более низкого уровня интерфейса, был рассказ об Ethernet, о других протоколах.
Было сказано о туннелировании.
На интерфейсном уровне есть привязка к железу, или к несуществующей сущности (например, VLAN).

PPP (протокол интерфейсного уровня).
Есть какая-то СПД, которая как-то передает данные.
Мы знаем, что эта СПД, возможно, не предназначена для организации протокола верхнего уровня (IP).
Типичный пример — СПД вообще без разделения пакетов (какие-то нолики и единички).
Или пакеты есть, но к ним нет доступа, те же нолики и единички.
Пример — модемный дозвон.
Поверх такой СПД необходимо дополнительно организовывать протокол интерфейсного уровня.
Может быть даже высокоуровневый канал, даже транспортного уровня, но в нем нужно выковыривать данные.
Есть некоторая внутренняя сеть, отгороженная от Интернета.
Может быть SSH-туннелирование, которое сводится именно к потоку байт.

Итак, PPP (Peer-to-peer).
Это средство наладить передачу IP-пакетов поверх почти любой СПД.
Интерфейсный уровень.
Или уровень Data Link (2) семиуровневой модели ISO/OSI.

Какие проблемы?
У него всего два конца.
Это не проблема, если СПД — двунаправленный поток байтов.
Организуя PPP по Ethernet, мы не требуем всех свойств Ethernet.
Нужен только потой байтов в обе стороны.
Настраивая IP, мы присваиваем IP-адрес.
Команда ip addr может быть работать непохоже на стандартный режим.
IP1 — IP2.
Заводим интерфейсы, даем адреса, говорим, что есть туннель.
Поверх СПД должны возникнуть два интерфейса.

Проблема первая.
Кто из них главнее?
Особенно характерно для ситуаций, когда соединение организуется по инициативе клиента, чтобы работать с сервером.
Сервер выдает настройки клиенту.
Подвох: до момента установки соединения соединение асимметрично (хотя бывает симметрично), не понятно, кто главнее.
Может быть Вы пинаете провайдера, он выдает Вам связь.
Или Вы пинаете провайдера, провайдер звонит Вам и выдает связь (Callback).
Синхронизация, самонастройка LCP.
Мы смотрели Wi-Fi.
Может быть даже такое, что каждая у каждой спрашивает пароль, когда они удовлетворяются, соединение устанавливается.
Все это появляется до того, как появляются IP-интерфейсы, у которых могут быть адреса.
Самонастройка, IP, маршуртизация, DNS.
Обратим внимание на следующее.
В процессе самонастройки выдается IP.
Это можно понять.
То, что может быть модифицирована таблица маршрутизации, тоже можно понять.
Провайдер предоставляет информацию о том, что за ним — весь Интернет.
НАстройка DNS требует прыжка через голову (служба прикладного уровня).
Из того, что мы дозвонились и организован канал сетевого уровня не следует, что есть следующий уровень.
Такой прыжок уже стандартен.
Сейчас все знают, что выдается адрес, адрес маршрутизатора и DNS.
В случае передачи IP это естественно, в случае верхнего уровня — извращенно, хотя и просто.

Механизм идентификации, авторизации.
За чьи деньги Интернет?
Мы не уверены, кто на том конце провода.
Человек должен ввести логин и пароль, получить какие-то права.

Необходимо шифрование.
Далеко не в каждой СПД отсутствуют наблюдатели, как в модеме (хотя там есть специальные организации).
Но если есть PPPoE, ситуация другая.
С шифрованием не все гладко, есть ситуации, когда вводятся логин и пароль (CHAP).
Вся эта катавасия, если внимательно рассматривать, непростая.
Некоторые методы шифрования криптонестойкие (легко взламываются).
А использование стойких методов поддерживается не всеми клиентами.

Организация IP канала имеет много вариантов использования.
Про PPP осталось сказать следующее: есть варианты использования PPP.
PPTP, PPPoE.
PPPoE — использование Ethernet в качестве среды передачи данных.
Для передачи необходима поддержка со стороны системы.
Заворичиваем поток байт во фреймы.
Есть eth0, из него лезут внутренние пакеты.
Некоторые — пакеты PPPoE.
Нужен модуль ядра, который бы выковыривал из этого интерфейса.
На уровне ядра преобразование пакетов в поток байт.

Маленькое отступление: как в Линуксе осуществляется преобразование чего-то в поток байт и обратно?
Есть специальный механизм pty/ttyP.
Некоторая программа, которая считает, что она знает, как преобразовывать нечто в байты и обратно, открывает устройство и пишет или читает поток байтов.
Другой конец устройства может быть каким угодно.
Фильтрация, работа на уровне ядра, выемка из USB.
В результате открытия доступно устройство ttyP — обычный терминал.
Его открывает любая программа и работает с ним.

cat /dev/pts/

Появится устройство /dev/pts/#.
Раньше создавали сотнями, сейчас — виртуальная ФС.

В Линуксе нет отдельного ppp-клиента.
Клиенту все равно, откуда пришел поток байт.
Лезет в терминал, видит (или не видит) протокол PPP.
Создает сетевое устройство ppp#, соответствующее терминалу.

С точки зрения Линукс, есть задача преобразовать поток байтов в ppp, и задача сделать из ppp сетевое устройство.

Если в качестве носителя данных используется Ethernet, область применения такой штуки довольно большая.
Если есть устройство, в котором видна только внутрення сеть, с точки зрения провайдера легко заставить вас настроить ppp-клиент, чтобы была связь с главной машиной сети, уже подключенной к Интернету.
Полноценной виртуальной частной сети не получится, но возможна нормальная выдача Интернета с нормальным контролем трафика на сетевом уровне.
Часто используется у провайдеров, особенно мелких.
Что получили?
Некое подобие туннеля между вами и вашим сервером.
Простой способ — настроить интерфейс на сервере, на клиенте, обеспечить маршрутизацию, определить, кто платит.
Недостаток — ограничены одним Ethernet-сегментом.

Еще одно часто встречающее место — pptp (point-to-point protocol).
Это семейство протоколов.
Для выдачи обычному пользователю доступа в Интернет используется еще чаще.

Задача — попробовать изобрести комплект протоколов уровнем выше.
Мы не можем воспользоваться интерфейсным уровнем, нужен сетевой, чтобы была хотя бы маршрутизация.
Есть некий универсальный способ туннелирования чего угодно куда угодно.
GRE.
Изобретен циской для внутренних нужд.
Нет шифрования, защиты.
Удобнее на маршрутизаторе тысяча потоков одного типа, чем тысяча потоков на тысячу протоколов Интернета.

Приделываем заголовок, получаем обычный IP-пакет.
Он едет по назначению, клиент его получает, детектирует, разворачивает вложенный пакет.
Получился туннель.
С точки зрения клиентов — прямой туннель, с точки зрения Интернета — обычный пакет с маршрутизацией произвольного вида.
С помощью GRE ничего не делаем — ни идентификацию, ни шифрование, ничего.
Только поток.
Возвращаемся обратно.
Туннелем надо управлять.
Нужно подключиться к серверу и инициировать соединение.

Туннель.
Кладем в него обычный трафик.
Но для туннеля этого недостаточно.
GRE+PPP.
PPTP — управляющий трафик.
Соединение.
Управляющее соединение — снаружи.
Порт 1723.
Передаем настройки прикладного уровня на интерфейс.
А здесь передача сетевого интерфейса через прикладной.
Шифрование не предусмотрено, точнее есть в PPP и не используется.
PPTP — множество протоколов с разными вариантами отклонения, которые не приводят к идеальной организации VPN.
Соединение на 1723 легко можно порезать файрволлом.

В качестве замены позиционируется L2TP (Level 2 Tunneling Protocol).
Это часть стека IPv6 (по стандарту).
Пробрасывание пригодного с точки зрения интерфейса трафика.
Восприятие как сетевого устройства.
Трафик через UDP и всем хорошо.
Если порт закрыт, не работает.
Поддержка есть практически везде, даже некоторые провайдеры ее обещают.
В Линуксе работает.
Не получила большого распространения, возможно, потому что в Windows появилась недавно.
L2TP — туннелирование сетевого трафика по транспортному протоколу UDP.
Видимо, есть какие-то проблемы с невозможностью вставить в IP-пакет нужную информацию.

IPSec (IP Security).
Часть протокола IPv6.
Часть стандарта.
Активно затаскивается в IPv4.
Лектор видел реализации.
В принципе, работает хорошо и достаточно надежно.
RAME, Strong SWAN.
Две разные реализации одного и того же.
Вещь довольно простая.
В Линуксе всего пяток утилит.
Разговоривать про настройку не будем.
Из название следует, что это возможность обеспечить защиту на уровне IP.
Самая простая идея — взять каждый пакет и его зашифровать.
Вопрос как?
С заголовком или без.
Если с заголовком, куда он пойдет с зашифрованным адресом?
Если же заголовок не шифровать, какая тут защита, если видно, что мы залезли на сервер ICQ.
Проблема нерешаемая.
Варианты решения: организовать туннель.
Мы полностью шифруем весь IP-пакет вместе с заголовками, к ниму присобачивается IPSec-пакет и новый IP-заголовок.
Все пакеты будут выглядеть как «это пакет IPSec».
Чем идея хороша?
Это организация туннеля на уровне IP.
IP over IP.
Каждый пакет шифруется, снабжается достаточной информацией, посылается.
Проблемы: если раньше написано, что это аська, то сейчас неизвестно и никто не знает.
Даже сотрудник безопасности, а он обидится.
Пакет может быть зарезан как непонятный.
Пакет гуляет по всему Интернету.
Проблема в том, что могут порезать.

Другой режим — транспортный.
Мы шифруем только payload (все, что внутри пакета).
Но не шифруются поля IP-пакета, которые могут видоизменяться.
Адрес отправителя не шифруется, вдруг проходит через NAT.
Достоинства: такой пакет выглядит обычно.
Любой маршрутизатор увидит обычный пакет с обычным типом протокола.
Проблемы две.
Первая — утечка security, ибо открыты адрес отправителя, получателя.
Вторая более хитрая.
Все IPSecurity — не IPCrypt.
Не должно быть возможности произвести атаку replay.
Поворачиваем башню танка на 90 градусов.
Посылаем еще дважды, башня танка поворачивается еще на 180 градусов.
Помимо этого нужно обеспечить возможность идентификации каждого пакета, какой абонент отправил пакет и так далее.
Способ идентификации.
Проблема довольно большая.
В случае туннеля все очевидно.
Есть идентифицирующийся пользователь, зашифровали, вычислили хеш-сумму и все хорошо.
Первый же попавшийся NAT сломает передачу.
Транспортный режим приводит к плохому работу с файрволлами.
Либо отключаем защиту заголовков и понадеяться на то, что шифрование надежное, а все остальное проверяется на транспортном уровне.

Чистая теория безопасности говорит, что пакет должен быть идентифицирован, и нужно защищать заголовки.
Другой вариант — вручную разрешать такие проблемы, как проход пакета через NAT.
NAT-T (NAT-прогноз).
Обмен ключами (в мирное время бумажками с fingerprint).
Ключ можно скачать с DNS.
Если DNS никто не подменяет, трафик тоже никто не подменяет, можно брать открытый ключ с DNS.
Отдельный протокол IPSec.

Получается два уровня.
Сначала устанавливается соединение, затем происходит удостоверение личности друг друга.

Протокол ICMP (Internet Control Message Protocol).
На уровне IP есть еще один важный протокол.
Предназначен для передачи служебной информации, в случае, если произошла ошибка, например, или эту информацию запросили.
Крайне простой протокол, около 20 типов того, что может присылать машина.
В основном — запросы и овтеты.
На всякие ситуации, связанные с той или иной неработоспобностью сетевого протокола, существует ICMP запросы.
Пример — утилита ping.
Не гарантирует.
«Системный администратор зарезал ping».
Реально конкретный тип пакетов не пропускает.
Утилита посылает запрос вида «Жив ли ты?».
Адресат отвечает, если хочет, что он жив.
NAT.
Каждый ICMP-запрос сделан так, что когда мы получаем ответ, мы знаем, от кого ответ (пингуем несколько сайтов на одном сервере).
Неправильной практикой является фильтровать всевозможные сообщения об ошибках вида host unreachable, ttl exceeded.
Каждый раз, когда происходит маршрутизация, если администратор не предпримет специальных действий, ttl уменьшается на единичку.
Когда значение ttl равно 0, считается, что пакет не дошел и посылается соответствующее уведомление.
Пакет может зациклиться, так что в конце концов он все же сбросится.
Что делать в случае, если закрыт ping?
Если на сервере есть сайт, можно попробовать на 80 порт.
tcping.

Программа traceroute.
Программа посылает ICMP-запрос.
Механизм работы следующий.
Первый пакет имеет ttl равный единице.
Первый же маршрутизатор должен сказать, что время истекло и уведомить отправителя.
Следующий — с ttl равным 2.
Таким образом traceroute добивается ситуации, когда пакет все же доходит.
Мы видим как бы путь, по которому шел пакет.
Реально пути мы не видим, мы видим конец пути, по которому шел первый пакет, второй пакет и т. д.
Они не обязаны быть одинаковыми.
Маршрутизатор может изменить канал.
Пакет, пришедший 6, может идти по другому пути, нежели 7 пакет.
Легенда о том, что если мы работаем с сайтом и параллельно пингуем, работа идет быстрее.
Может иметь место при оптимизации маршрутизаторами пути.

Еще один тип ICMP-ответов, которые нельзя резать.
Need to fragment.
В IPv4 есть фрагментация пакета, если он не влезает.
В IPv6 нет фрагментации IP-пакета.
Вместо этого клиенты обязаны использовать механизм MTU path discovery.
Internet — от internetwork.
Среды могут иметь MTU разного размера.
Для того, чтобы не происходила ситуация, при которой фрейм приходит 1500, и нужно послать 1492 и 8 байт.
Можно запретить маршрутизатору принимать такие пакеты, а можно посылать сообщение Need to fragment.
Отправитель должен получить и обработать.
Когда этому абоненту приспичит посылать туда же еще один пакет, его размер должен быть не больше указанного в сообщении Need to fragment.
Этот механизм замечательно работает.
В IPv4 возможны ситуации.
На маршрутизаторе это включено для минимизации нагрузки на Интернет.
Такая фигня может увеличить вдвое количество фреймов.
ICMP зарезан.
Мы заходим на сайт и видим несколько букв.
Потом еще несколько букв.
Низкая скорость работы либо вообще неработоспособность.
Мы могли просто не получить ICMP пакет.
Это не обязательно один неграмотный администратор.
Администратор домовой сети мог сказать, что ICMP — зло и зарезал его.
Клиент — TCP/IP стек ОС.

В следующий раз говорим про оставшиеся протоколы.

Конспект eSyr:
<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>

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2008%2C_07_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_12_%D0%BD%D0%BE%D1%8F%D0%B1%D1%80%D1%8F%29

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

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 1: / Строка 1: @@
-* '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_11_12.ogg
-= Лекция =
-== Вступление ==
 Лектор удивлен количеством народа.
 Сегодня запланирован Internet Protocol (IP).
@@ Строка 8: / Строка 4: @@
 Мы рассказали, как устроены идентификация и маршрутизация в Интернете.
 Поговорили про нестандартную маршрутизацию.
-Не говорили про IPv6 (но был доклад о нем).
+Не говорили про IPv6 (был доклад о нем).
 Не говорили про протоколы уровня IP, которые существуют на этом уровне, не поднимаясь на транспортный уровень.
@@ Строка 16: / Строка 12: @@
 На интерфейсном уровне есть привязка к железу, или к несуществующей сущности (например, VLAN).
-== PPP ==
+PPP (протокол интерфейсного уровня).
-PPP - протокол интерфейсного уровня.
 Есть какая-то СПД, которая как-то передает данные.
 Мы знаем, что эта СПД, возможно, не предназначена для организации протокола верхнего уровня (IP).
@@ Строка 28: / Строка 23: @@
 Может быть SSH-туннелирование, которое сводится именно к потоку байт.
-Итак, PPP (Point-to-Point Protocol).
+Итак, PPP (Peer-to-peer).
 Это средство наладить передачу IP-пакетов поверх почти любой СПД.
 Интерфейсный уровень.
 Или уровень Data Link (2) семиуровневой модели ISO/OSI.
-=== Проблемы ===
 Какие проблемы?
 У него всего два конца.
 Это не проблема, если СПД — двунаправленный поток байтов.
 Организуя PPP по Ethernet, мы не требуем всех свойств Ethernet.
-Нужен только поток байтов в обе стороны.
+Нужен только потой байтов в обе стороны.
 Настраивая IP, мы присваиваем IP-адрес.
 Команда ip addr может быть работать непохоже на стандартный режим.
@@ Строка 87: / Строка 81: @@
 Для передачи необходима поддержка со стороны системы.
 Заворичиваем поток байт во фреймы.
-=== pty/ttyP ===
 Есть eth0, из него лезут внутренние пакеты.
 Некоторые — пакеты PPPoE.
@@ Строка 123: / Строка 115: @@
 Недостаток — ограничены одним Ethernet-сегментом.
-Еще одно часто встречающее место — pptp (Point-to-point tunneling protocol).
+Еще одно часто встречающее место — pptp (point-to-point protocol).
 Это семейство протоколов.
 Для выдачи обычному пользователю доступа в Интернет используется еще чаще.
-=== Туннелирование. GRE. ===
 Задача — попробовать изобрести комплект протоколов уровнем выше.
 Мы не можем воспользоваться интерфейсным уровнем, нужен сетевой, чтобы была хотя бы маршрутизация.
@@ Строка 160: / Строка 151: @@
 Соединение на 1723 легко можно порезать файрволлом.
-=== L2TP (Level 2 Tunneling Protocol) ===
 В качестве замены позиционируется L2TP (Level 2 Tunneling Protocol).
 Это часть стека IPv6 (по стандарту).
@@ Строка 173: / Строка 163: @@
 Видимо, есть какие-то проблемы с невозможностью вставить в IP-пакет нужную информацию.
-== IPSec (IP Security) ==
+IPSec (IP Security).
 Часть протокола IPv6.
 Часть стандарта.
@@ Строка 179: / Строка 169: @@
 Лектор видел реализации.
 В принципе, работает хорошо и достаточно надежно.
 RAME, Strong SWAN.
 Две разные реализации одного и того же.
@@ Строка 186: / Строка 175: @@
 Разговоривать про настройку не будем.
 Из название следует, что это возможность обеспечить защиту на уровне IP.
 Самая простая идея — взять каждый пакет и его зашифровать.
 Вопрос как?
@@ Строка 193: / Строка 181: @@
 Если же заголовок не шифровать, какая тут защита, если видно, что мы залезли на сервер ICQ.
 Проблема нерешаемая.
 Варианты решения: организовать туннель.
-Мы полностью шифруем весь IP-пакет вместе с заголовками, к нему присобачивается IPSec-пакет и новый IP-заголовок.
+Мы полностью шифруем весь IP-пакет вместе с заголовками, к ниму присобачивается IPSec-пакет и новый IP-заголовок.
 Все пакеты будут выглядеть как «это пакет IPSec».
 Чем идея хороша?
 Это организация туннеля на уровне IP.
 IP over IP.
 Каждый пакет шифруется, снабжается достаточной информацией, посылается.
 Проблемы: если раньше написано, что это аська, то сейчас неизвестно и никто не знает.
@@ Строка 212: / Строка 198: @@
 Но не шифруются поля IP-пакета, которые могут видоизменяться.
 Адрес отправителя не шифруется, вдруг проходит через NAT.
 Достоинства: такой пакет выглядит обычно.
 Любой маршрутизатор увидит обычный пакет с обычным типом протокола.
 Проблемы две.
 Первая — утечка security, ибо открыты адрес отправителя, получателя.
 Вторая более хитрая.
 Все IPSecurity — не IPCrypt.
@@ Строка 224: / Строка 207: @@
 Поворачиваем башню танка на 90 градусов.
 Посылаем еще дважды, башня танка поворачивается еще на 180 градусов.
 Помимо этого нужно обеспечить возможность идентификации каждого пакета, какой абонент отправил пакет и так далее.
 Способ идентификации.
@@ Строка 245: / Строка 227: @@
 Сначала устанавливается соединение, затем происходит удостоверение личности друг друга.
-== Протокол ICMP (Internet Control Message Protocol) ==
+Протокол ICMP (Internet Control Message Protocol).
 На уровне IP есть еще один важный протокол.
 Предназначен для передачи служебной информации, в случае, если произошла ошибка, например, или эту информацию запросили.
 Крайне простой протокол, около 20 типов того, что может присылать машина.
-В основном — запросы и ответы.
+В основном — запросы и овтеты.
-На всякие ситуации, связанные с той или иной неработоспособностью сетевого протокола, существует ICMP запросы.
+На всякие ситуации, связанные с той или иной неработоспобностью сетевого протокола, существует ICMP запросы.
+Пример — утилита ping.
-=== Утилита ping ===
 Не гарантирует.
 «Системный администратор зарезал ping».
@@ Строка 258: / Строка 239: @@
 Утилита посылает запрос вида «Жив ли ты?».
 Адресат отвечает, если хочет, что он жив.
 NAT.
 Каждый ICMP-запрос сделан так, что когда мы получаем ответ, мы знаем, от кого ответ (пингуем несколько сайтов на одном сервере).
@@ Строка 265: / Строка 245: @@
 Когда значение ttl равно 0, считается, что пакет не дошел и посылается соответствующее уведомление.
 Пакет может зациклиться, так что в конце концов он все же сбросится.
 Что делать в случае, если закрыт ping?
-Если на сервере есть сайт, можно попробовать постучаться на 80 порт.
+Если на сервере есть сайт, можно попробовать на 80 порт.
 tcping.
-=== Утилита traceroute ===
+Программа traceroute.
 Программа посылает ICMP-запрос.
 Механизм работы следующий.
 Первый пакет имеет ttl равный единице.
@@ Строка 278: / Строка 256: @@
 Следующий — с ttl равным 2.
 Таким образом traceroute добивается ситуации, когда пакет все же доходит.
 Мы видим как бы путь, по которому шел пакет.
 Реально пути мы не видим, мы видим конец пути, по которому шел первый пакет, второй пакет и т. д.
@@ Строка 284: / Строка 261: @@
 Маршрутизатор может изменить канал.
 Пакет, пришедший 6, может идти по другому пути, нежели 7 пакет.
 Легенда о том, что если мы работаем с сайтом и параллельно пингуем, работа идет быстрее.
 Может иметь место при оптимизации маршрутизаторами пути.
-=== Need to fragment ===
 Еще один тип ICMP-ответов, которые нельзя резать.
-* В IPv4 есть фрагментация пакета, если он не влезает.
+Need to fragment.
-* В IPv6 нет фрагментации IP-пакета. Вместо этого клиенты обязаны использовать механизм MTU path discovery.
+В IPv4 есть фрагментация пакета, если он не влезает.
+В IPv6 нет фрагментации IP-пакета.
+Вместо этого клиенты обязаны использовать механизм MTU path discovery.
 Internet — от internetwork.
 Среды могут иметь MTU разного размера.
-Для того, чтобы не происходила ситуация, при которой фрейм приходит 1500, и нужно было послать 1492 и 8 байт.
+Для того, чтобы не происходила ситуация, при которой фрейм приходит 1500, и нужно послать 1492 и 8 байт.
 Можно запретить маршрутизатору принимать такие пакеты, а можно посылать сообщение Need to fragment.
 Отправитель должен получить и обработать.
 Когда этому абоненту приспичит посылать туда же еще один пакет, его размер должен быть не больше указанного в сообщении Need to fragment.
 Этот механизм замечательно работает.
 В IPv4 возможны ситуации.
 На маршрутизаторе это включено для минимизации нагрузки на Интернет.
 Такая фигня может увеличить вдвое количество фреймов.
+ICMP зарезан.
-=== ICMP зарезан ===
 Мы заходим на сайт и видим несколько букв.
 Потом еще несколько букв.
@@ Строка 317: / Строка 291: @@
-= Конспект eSyr'a =
+Конспект eSyr:
 <div style="font-size:50%">
 Отстутпление номер 1.