Канальные среды (2)

Про протокол рассказал. Дальше. В самом конце кадра у нас либо двух, либо четырехбайтовое поле FrameCheckSequence. Используется, в общем, очень похожий механизм на то, который используется в Ethernet. Естественно, полином может быть другой. И размер поля FCS согласуется с помощью LCP. То есть вы можете варьировать, в зависимости от ваших хотелок, сколько именно байт будет выделяться под чексуму в каждом отдельном кадре. Чаще всего используется двухбайтовая чексума, потому что вероятность случайного проведения кадра, она, соответственно, достаточно низка. Но если вы знаете, что у вас используется какая-то линия, в которой процент ошибок слишком высок по сравнению с просто нормальной линией, под которую делался PPP, а в случае, например, с модемными линиями это часто довольно бывает так, что, да, в модемных линиях часто проходят какие-то ошибки. В этом случае вы можете сказать, что вам нужна четырехбайтовая чексума, и тем самым вы будете весьма надежно защищаться от каких-то ошибок.

Все остальное выделяется под само мясо кадра. И так же, как в изернете, у нас есть ограничение на размер кадра сверху-снизу. Ограничение на размер сверху контролируется, во-первых, работой функции CRC, которая у нас в чексуме используется, CRC16 или CRC32. Во-вторых, ограничение сверху, которое у нас будет, будет еще дополнительно ограничиваться здравым смыслом. Будет максимальный размер кадра. Если вы будете передавать по какой-то медленной линии связи слишком большой кадр, он у вас будет занимать среду передачи данных на слишком большое время. То есть, если вы не используете расширение Multilink, и вы не разбиваете каждый кадр на отдельные кусочки, и вы не позволяете в этом случае кадры, которые более приоритетны, отправлять в серединке между менее приоритетными кадрами, то тогда, если вы начинаете передачу большого кадра, вы должны будете дождаться конца передачи

для того, чтобы следующий кадр передать. Если вам нужно передать какой-то приоритетный кадр, а вы уже начали передачу большого неприоритетного кадра, у вас будет расти задержка. На медленных линиях связи эта задержка может быть довольно актуальной и довольно большой. Поэтому ограничение на размер кадра сверху нужно не только для того, чтобы чек-сумма хорошо себя чувствовала, но и для того, чтобы не задерживать остальные кадры, которые висят в очереди слишком долго. Также, как и в интернете, есть ограничение на размер снизу. И это ограничение на размер снизу указывает, что если у нас есть какое-то желание передать чего-то маленькое, то надо это маленькое добить мусором, чтобы у нас ограничение снизу тоже работало. Опять же, на уровне LCP вы можете согласовать все ограничения, которые у вас есть. То есть у вас и верхнее, и нижнее ограничение может быть согласовано. Так, дальше, дальше, дальше, дальше. Как уже было сказано, в PPP есть проверка подлинности.

Она работает на этапе согласования LCP. И если у вас есть узел, который хочет проверить подлинность соседа, вот он может сказать, а ну-ка покажи, что ты действительно тот, за кого себя выдаешь. При работе PPP у нас есть две стороны. Одна и вторая. Вот протокол point-to-point, там две точки. Point-to-point. Одна точка и вторая точка. И каждый из точек может независимо заказать проверку подлинности со стороны соседа. То есть каждый из точек может сказать, а я не верю тебе, я не думаю, что ты это тот, за кого себя выдаешь. Но если ты мне покажешь, что ты действительно знаешь какой-то там секрет, то я тебя тогда буду трактовать как своего. До тех пор я тебя не верю. Обычно, когда мы используем PPP, у нас есть один узел, который инициирует соединение, а второй узел, который, ну, как бы согласен его установить. В этом случае у нас есть тот, кому очень сильно хочется подключиться, и он знает, куда он подключается. И второй узел, который как бы согласен, он в кавычках как бы сервер, да, кто так и быть согласен установить соединение.

Вот обычно, чаще всего сервер, в кавычках сервер, заказывает проверку подлинности у инициатора соединения, у того, кто в кавычках будет клиентом. То есть если мы используем PPP, мы чаще всего используем его для построения виртуальных каналов в современном мире. И в этом смысле, да, мы чаще всего со стороны того, кто хочет установить соединение, должны будем продемонстрировать, обладание определенным секретом тому, к кому мы подключаемся. В принципе, PPP может заставить пользователя, не заставить, а предложить со стороны пользователя показать знание какого-то секрета и серверу. То есть каждый из узлов независимо может заказать проверку соседа, если вдруг захочет того. Но если мы подключаемся, например, с использованием какого-то VPN-соединения, то как-то будет немножко странно, если мы будем заказывать проверку подлинности от сервера, будучи клиентом. Поэтому обычно такого не происходит. В PPP поддерживаются три протокола. Это PPP, CHAP в разных его вариациях.

То есть там есть CHAP, MSCHAP, MSCHAP-2 и EAP. EAP — это фреймворк для дополнительного расширения возможностей протоколов аутентификации. PPP — это плентекстовая аутентификация, когда вы просто показываете плентекстом, как вас зовут и какой у вас пароль. В реальных сетях использовать PPP-аутентификацию ну как-то совсем не камерфой, если у вас используется недоверенное соединение. Ну, планетектом пароль полить — ну такое. CHAP не передает пароль в открытом виде, но у него есть ряд недостатков, которые постепенно решались путем улучшения работы CHAP-а. Там используется хэш-функция, которая передает некий отпечаток от содержимого пароля плюс некого одноразового челленджа, который передает сервер. Но у этого механизма есть ряд недостатков, и на конкретную реализацию CHAP-а, изначального протокола, были найдены уязвимости, которые позволяли вычленить оригинальный пароль, даже несмотря на то, что по сети он не передавался.

Поэтому постепенно его улучшали. Сначала придумали версию MS-CHAP, потом придумали версию MS-CHAP-2, а потом поняли, что постоянно улучшать этот самый CHAP — это какая-то тупиковая идея, и сказали, давайте мы сделаем просто набор функций, которые можно будет, скажем, с использованием которых можно будет взять совершенно произвольный протокол и подключить его к работе этого самого протокола LCP, чтобы можно было совершенно произвольным протоколом аутентифицировать пользователя при работе в PPP. А главное, уже такой протокол, в принципе, присутствовал. То есть этот протокол называется EAP, и он является фактически фреймворком для построения аутентификации на основе совершенно любого механизма, который вам будет по душе. Если вам хочется, вы можете в EAP завернуть и тот же самый PPP, и CHAP, и TLS, и все, что хотите. То есть механизмов там много, и EAP, если вдруг ваше оборудование поддерживает, конечно же, очень неплохой идеей будет использовать. Но далеко не все оборудование поддерживает EAP,

к сожалению. У PPP ограничение такое, что он придает все plaintextом, то есть у вас есть некий узел, который хочет подключиться к другому, допустим, узел R1, хочет подключиться к R2 с использованием протокола PPP. Например, он может PPP-уешьную трубу хотеть поставить. В этом случае R1 подключается, он говорит, я бы хотел подключиться к тебе, дорогой пользователь, дорогой узел R2. R2 говорит, а покажи, что ты знаешь, что такое, вот я такой вот хочу, чтобы ты мне что-то показал. Он говорит, покажи мне что-то по протоколу PAP. Отправляет сообщение Configuration Request Authentication Protocol PAP. R1 отвечает, окей, я тебе согласен показать кое-что по протоколу PAP. И отправляет сообщение, меня зовут R1, и пароль мой циск 123. В этом случае R2 говорит, окей, я тебя услышал, и проверил твой пароль по какой-то своей базе, и, соответственно, меня все устраивает. Он отправляет сообщение PPP Authentication Acknowledge. То есть PAP отработал,

и PPP не против того, чтобы продолжить дальше работу. То есть явно пароль подошел. У чапа нету проблемы с тем, что он посылает пароль в открытом виде. Потому что если злоумышленник в PAPе перехватит пароль, он, соответственно, сможет потом аутентифицироваться много-много раз. В случае с чапом пароль по сети в открытом виде не посылается. Опять же, у нас R1 подключается к router R2. R2 говорит, покажи мне кое-что по протоколу чап. R1 говорит, я понимаю, что такое чап. Давайте я сейчас кое-что покажу, но для этого кое-чего ты мне должен прислать одноразовое значение. R2 посылает в сторону R1 так называемый челлендж. Это одноразовое число, которое R2 только что на лету придумывает. R1 берет этот самый челлендж, берет свой пароль, который он знает, берет все это дело, хеширует, получает одноразовый отпечаток хэш и отправляет его в сообщение chap.response. Он говорит, что меня зовут R1, и то, что ты просил показать, это вот там какое-то одноразовое значение.

R2 проверяет это значение, если у него результат сошелся, то, соответственно, он справляет сообщение chapsuccess. Если результат не сошелся, он говорит, ну, так, knowledge. Ну и, соответственно, chap, сама идея как бы красивая, если говорить про идею, что мы посылаем какое-то одноразовое значение и получаем в итоге отпечаток, который не содержит в себе содержимого пароля, и, соответственно, злоумышленник гипотетически не может из этого отпечатка вычленить оригинальное содержимое пароля, и если вдруг мы в следующий раз будем подключаться, мы каждый раз новому пользователю будем отправлять разные эти самые челленджи. Проблема оказалась в протоколе, что протокол, к сожалению, челленджи эти самые придумывал по стандарту не совсем случайно. Механизм хэширования тоже работал не совсем случайно, поэтому, по факту, из хэшей, которые можно было получить, если вы набрали некоторое количество этих самых хэшей, можно было с некоторой вероятностью предположить,

какой будет пароль. Поэтому механизм чапа, соответственно, в оригинальном своем формате используется крайне редко, потому что он просто небезопасен. Чуточку более безопасен, чем plaintext. Если у вас нет возможности большое количество хэшей набрать, соответственно, он сравнительно безопасен. Но если у вас есть возможность подслушать большое количество хэшей и челленджей к ним, то в этом случае вы можете угадать, какой был пароль. Недостатком работы чапа является то, что вы должны будете на роутере, который заказывает аутентификацию, знать, какой открытый пароль будет у R1. То есть вы должны будете знать некий общий открытый секрет. Если R1 знает свой пароль, R2 должен тоже знать именно открытый пароль. В случае с папом вы можете не знать сам пароль, вы можете его не хранить в конфигурации. То есть если вам пользователь говорит, у меня пароль циск 1, 2, 3, вы можете у себя, допустим, в конфигурации или в какой-то локальной базе хранить только хэш от паролев. Для папы это катит, потому что пользователь присылает вам открытый пароль, вы берете, считаете хэш от него,

сравниваете с тем, что хранится в конфиге и бурно радуетесь жизни. Но если кто-то в этом случае упрёт вместе с циской с вашей, то в этом случае он не получит базу всех-всех-всех паролей. В случае с чапом получается, что все пароли должны в plaintext лежать в конфигурации R2. Все пароли всех пользователей. Если кто-то если кто-то утащит конфигура R2, он получит пароли вообще всех учёток, с которыми можно будет подключаться. Это нехорошо. Так. Если говорить про реальность, реальность заключается в том, что на роутерах мы не храним конфигурацию, не храним пароли. Мы, как правило, используем некий внешний сейлер и всех подключающихся пользователей мы заставляем аутентифицироваться с помощью либо папа, либо чапа, либо япа с каким-то набором расширений и отправляем запросы пользователей на централизованный сервер. Идёт аутентификация с помощью процедуры, предусмотренной протоколом,

ну, как правило, радиус. Либо радиус, либо такакс. Есть альтернативные варианты, всякие диаметры и прочее, но в реальных сетях встречается исключительно редко. Чаще всего либо радиус, либо такакс. Где можно встретить PPP в реальном мире? Это почти всегда в современном мире PPPOE. Если у нас есть Ethernet-среда, то есть мы, как провайдер, построили сетку на использование оборудования Ethernet, может быть, метро Ethernet-овское оборудование, может быть, просто обычные свечи. Мы хотим, чтобы у нас пользователи не просто бы смотрели в толстый, желтый кактен. Мы хотим иметь отдельный виртуальный хотя бы интерфейс, который смотрит на отдельного пользователя, в котором мы можем провести процедуру аутентификации. Мы можем заказать у пользователя, чтобы он показал нам пароль. В Ethernet мы не можем этого сделать, а иногда очень сильно хочется. И вот PPPOE — это процедура, с помощью которой мы можем поверх Ethernet-овской среды, в которой нет аутентификации, в которой нет возможности проверить,

что действительно другой участник тот, за кого себя выдает. Мы не можем ограничивать скорость в Ethernet, мы не можем ограничивать количество данных, которые передаются в Ethernet. То есть пользователь может нам просто безустановочно посылать какие-то кадры. Мы можем и дальше не фарвардить, но тем не менее присылать их пользователь все равно может. Вот PPPOE решает все эти проблемы. Если мы сможем поверх Ethernet-а построить виртуальную PPPOE трубу, она, соответственно, с нас большую часть головной боли снимет, потому что у нас будет отдельный интерфейс на пользователя, которым мы можем рулить. Мы можем этот интерфейс в конце концов разорвать при необходимости, если мы понимаем, что пользователь как себя некорректно ведет. Мы возьмем этот интерфейс, просто погасим, и пользователь дальше нам не сможет чего уже прислать. PPPOE — это протокол, который довольно часто используется. Он строит виртуальную трубу поверх не совсем доверенной Ethernet-среды. Он позволяет нам

аутентифицировать пользователя, позволяет нам прописать какие-то правила на уровне этого пользовательского соединения, куда пользователя можно пускать, чего ему можно делать. можно будет сжимать заголовки, если вдруг нам это будет нужно. Можно будет сжимать сам трафик. И самое главное, почему PPPOE очень и очень популярен в провайдерских сетях, он не требует никаких специальных настроек. То есть он не требует, чтобы пользователь какие-то специальные настройки вносил на свое оборудование для того, чтобы этот самый PPPOE-шный канал заработал. Нужно только создать на пользователя эту самую процедуру установления PPPOE-шного соединения. То есть клиент автоматически обнаруживает PPPOE с помощью бродкастовой рассылки. Он орет на всю сеть, есть ли среди вас PPPOE-шные сервера. Дальше сервер отвечает, да, я есть. И дальше взаимодействие между сервером и клиентом в изернете начинается с помощью обычного

уникастового взаимодействия. Внутрь изернетовских кадров вкладываются PPPOE-шные вложения. И вот это PPPOE-шное вложение это уже будет просто обычный кадр PPPOE. Весь трафик, который у вас будет в PPPOE-шное соответственно передаваться между пользователем и сервером, он по факту будет ходить уникастом. Если у вас никто не производит атаку на вашу коммутацию, то, соответственно, обычные пользователи этого трафика вообще даже не видят. Неважно, что пользователь там будет посылать. Будет посылать браткасты, будет посылать мультикаст, уникаст. Коммутаторы если у нас есть IP, который работает в PPPOE-шной трубе, ну, например, в PPPOE, то для работы IP поверх PPP нам будет нужно некоторое количество служебных протоколов опять же. Во-первых, у нас будет IPCP, который согласует какие-то совсем базовые фичи, необходимые для работы IP. Ну, в частности, IP-шник, например, на своем конце туннеля и на другом конце туннеля протокол IPCP

будет отвечать за его работу. Но, как правило, достаточно мало будет сценариев, где вам достаточно иметь только IP-адрес. Вам, как правило, для работы, например, в интернете необходимо еще какие-то дополнительные опции получить. Например, можно получить DNS-сервер. Например, можно получить, там, не знаю, NTP-сервер, сервер времени. Например, можно получить, что там еще можно заказать со стороны соседа, какие-то кастомные маршруты. Все это можно будет получить с использованием протокола DHCP. То есть тот же самый DHCP, который работает в Ethernet, в PPP на самом деле тоже работает. Если вы попытаетесь поднять из Windows любое VPN-соединение, которое использует PPP, то есть это PPTP, L2TP, PPPOE, там на самом деле будет работать протокол DHCP, который у вас как раз и настроит большую часть всяких фич в этом VPN-соединении,

который не настраивается с помощью IPCP. Если вам нужны кастомные маршруты, если вам нужно там DNS тот же самый, вот IPCP не может вам притащить DNS, а DHCP может. Так. Как? ERIC tien.