UNИX, осень 2008, 07 лекция (от 12 ноября)
Материал из eSyr's wiki.
Лектор удивлен количеством народа. Сегодня запланирован 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 стек ОС.
В следующий раз говорим про оставшиеся протоколы.
