PPP

После того, как мы посмотрели один из примеров того, что может передавать данные на физике, Serial Link — это не единственный вариант, как можно передавать битики. Можно взять PDH, SDH. Там тоже, по сути, будут передаваться отдельные битики. Дальше из этих битиков надо как-то составлять кадрики. И один из вариантов того, что можно встретить на канальном уровне, когда у нас есть негибитовый поток, это будет протокол PPP. Этот протокол вырос из стандартного протокола HDLC. Стандартный протокол использовался только в мейнфреймах. Это была большая-большая машина, в которой можно было подключить много-много терминалов, и все абоненты сидели за своими терминалами. Но физически все вычисления проводились при этом только на одной машине, к которой терминалы были подключены. И для того, чтобы передавать трафик с терминалов на мейнфрейм, использовался как раз протокол HDLC.

Те данные, которые набирались на клавиатуре на терминале, отправлялись в сторону мейнфрейма. Те данные, которые отправлялись с мейнфрейма на терминал, соответственно, отрисовывались каким-то образом на экране. HDLC был протокол, заточенный под общую среду передачи данных, поэтому в нем были адреса. Например, как в Ethernet у нас есть MAC-адреса, в HDLC тоже были некие адреса. Но формат кадра там был довольно простой. Поскольку к одному мейнфрейму много терминалов подключить было нельзя, и, как правило, все терминалы, которые были подключены к мейнфрейму, были наперечёт, то можно было просто все адреса задать с помощью, например, джамперов. И поэтому в HDLC поле с адресом было крошечное, 1-байтовое. В Ethernet, например, два адреса используются в каждом кадре, и каждый адрес по 6 байт. Поэтому всего адресной информации в Ethernet 12 байт.

А в HDLC был всего 1 байтик. PPP был протокол, основанный на HDLC, в том смысле, что он заимствует формат кадра HDLC, поэтому в PPP тоже есть адресация, но эта адресация нарисованная, потому что PPP — это протокол, который передаёт данные между двумя узлами. Point-to-Point протокол предполагает, что у вас есть физический канал точка-точка, в котором можно передавать битики, и дальше мы договариваемся, что между двумя узлами в этом физическом канале точка-точка мы будем передавать кадры в формате HDLC. Но при этом мы говорим, что адреса там нам не нужны, и поэтому поле с адресной информацией в HDLC мы заполняем мусором. А фактически всё, что мы вкладываем в этот самый PPP, мы будем просто передавать и всё. Единственное требование к среде передачи у PPP, если мы говорим про битовый поток, который можно будет передавать поверх некой физики, это будет дуплексный режим, что данные, которые передаются в линке PPP,

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

можно взять и сделать такую штуку, что мы берём два этих физических провода, объединяем в один логический, и каждый конкретный кадр будет передаваться в обоих проводах одновременно. Можно будет сделать так называемый мультикласс PPP. Это запуск нескольких PPP-сессий в рамках одного и того же канала. Мы говорим, у нас провод один, но PPP-труб, PPP-туннелей мы поднимаем в этом проводе несколько. И трафик, который будет отправляться в одну трубу, будет более приоритетный, чем в другую. При этом всё равно всё пойдёт по одному и тому же проводу, но задержки, которые будет испытывать трафик в менее приоритетной трубе, будут больше, чем задержки, которые испытывает трафик в приоритетной трубе. Формат кадра у оригинального HDLC был следующий. Сначала, когда никакие данные не передавались, если у нас просто есть какой-то битовый поток, который мы можем передавать в Point-to-Point-Link, мы фактически делим всё время,

когда мы можем что-то передавать или не передавать, на отдельные биттаймы. И мы фактически должны будем либо передавать нолики, либо передавать единички всё время. Нельзя сделать так, как в Ethernet, что мы немножко передали и помолчали, немножко передали и помолчали. Мы всегда должны будем передавать нолики-единички, если у нас канал имеет природу Point-to-Point. Тогда мы не должны будем заморачиваться с синхронизацией, мы не должны будем заморачиваться на многие другие вопросы. Но нам нужно будет при этом понимать, что если мы ничего не хотим передавать, а среду занимать передачей каких-то битиков всё равно надо, то надо будет каким-то образом договориться, что когда мы посылаем специальную последовательность в канал, она ничего не означает, она означает, что мы ничего передавать не хотим, нас просто заставляют. Такая последовательность в стандарте HDLC будет называться словом flag. Он будет выглядеть как байт 0x7E. 7E — это 01111110. Если вы передаёте такой байт постоянно,

то вы тем самым даёте понять соседу, что вы передаёте этот байт просто для того, чтобы показать, что среда свободна. Такая последовательность никогда, ни при каких обстоятельствах не может встретиться в боевых данных. Что касается ситуации, когда нам нужно будет передать в боевых данных именно такую последовательность, что мы хотим байт 0x7E передать в трафике. Бывает же такое, что мы хотим что-то передать. В этом случае никогда, ни при каких условиях такая последовательность внутри кадра передаваться не может. А если нам очень сильно надо отправить подобную последовательность, то она искусственно будет разбавляться другими битиками, чтобы именно этого в мясе кадра никогда не встретилось. Это именно флаг, и он будет означать, что сейчас среда передачи свободна. Если мы передали флаг, потом передаём какое-то мясо кадра, мясо, мясо, мясо, а потом снова идёт флаг в какой-то момент,

передаётся 01111110. Флаг. Это значит, что кадр закончился, среда передачи — кадр закончился, и сейчас мы ничего не передаём. Даже если на самом деле мы что-то хотели бы передать, если получатель это услышал, нолик, шесть единичек и нолик, он понимает, что кадр закончился. Это признак конца кадра. Для того, чтобы никогда в серединке, если мы захотели передать в серединке 0x7E, у нас не получилось, что до этого то, что мы передали, и после этого то, что мы передали, будет расцениваться как два разных кадра, разделённых этим самым пустым флагом, байтики, содержащие шесть единиц подряд, будут разбавляться нулями искусственно. Если у нас в какой-то момент при передаче данных получается так, что сначала идёт битик ноль, потом шесть или больше единиц, и потом неважно что, то после пяти единиц мы обязательно вставляем ещё один нолик. И получается, что этот нолик

не содержит никакой полезной информации, кроме того, что это не флаг. И когда получатель принимает нолик, потом 5 единиц, и потом после них нолик, он этот нолик выкидывает. Этот нолик передаётся по сети, но он передаётся по сети искусственно, для того, чтобы не создать флаг. Отправитель после каждых пяти единичек добавляет нолик, а получатель после пяти единичек, если видит нолик, обязательно его выбрасывает. Никогда, ни при каких обстоятельствах, в боевых данных шесть единиц подряд у нас встретиться не может. Более того, они не могут встретиться даже на границах кадра. Если у нас есть один кадр, который заканчивается на нолик и 4 единицы, а потом следующий кадр начинается на 2 единицы, всё равно там будут добавляться эти нолики, чтобы не получилось 6 единиц подряд. Эта техника будет называться битстаффинг, когда мы набиваем наш кадр лишними битиками для того, чтобы у нас не получилось нигде ничего похожего на флаг в серединке. Отправитель набивает кадр лишними битиками, получатель эти самые битики вынимает из кадра,

чтобы не получить биты, которые на самом деле были добавлены искусственно. Дальше. Если у нас есть какой-то кадр, мы его начали передавать, закончили. Должны будем передать хотя бы один раз этот самый флаг, чтобы следующий кадр снова можно было начать. Сначала передали кадр, потом флаг, потом снова кадр, потом снова флаг. Если мы ничего не хотим передавать, мы снова флаг, снова флаг, снова флаг, потом снова кадр, снова флаг. Так это и работает. В Ethernet мы можем немножко помолчать. В HDLC-канале мы должны будем отправлять флаги, когда мы ничего не хотим передавать ценного. Это фактически своего рода молчание. Дальше. После того, как вы закончили передавать флаги, начинаете передавать мясо кадра, самое первое поле — это адрес. В HDLC это может быть 1-байтовое поле или может быть больше.

Стандартный вариант — это 1-байтовое поле. И дальше идёт поле Control. Оно указывает, как надо такой кадр обрабатывать. Дальше идёт само мясо кадра, ради чего всё это затевалось. Потом FrameCheckSequence. Либо 2, либо 4 байта CRC-16 или CRC-32. И на этом кадр заканчивается. По большому счёту довольно похоже на кадр Ethernet, если посмотреть. Только в Ethernet адресная информация — это 12 байт, два MAC-адреса. MAC-адрес получателя сначала, потом MAC-адрес отправителя. И потом Control Word — это фактически EtherType. То, что в Ethernet у нас было, плюс-минус. Только EtherType в явном виде указывал, что с этим полем надо делать. Он указывал на то, что внутри лежит. А здесь Control — какое-то не совсем понятное поле. Что-то явно там контролирует. И дальше идёт само мясо. PolyInformation — это то мясо кадра, ради которого всё затевается.

В стандарте HDLC не может быть такой ситуации, что вы не знаете, что внутри передаётся. Потому что всё это — только для мейнфреймов. И мейнфрейм по определению передаёт между терминалами и самим мейнфреймом только кадры одного и того же формата. Одного и того же содержимого. В мейнфрейме не может такое получиться, что терминал в сторону самого компьютера решит передавать данные, отличные от данных клавиатуры. Он не может сказать, я сейчас хочу передавать IPv4, а потом IPv6, а потом, не знаю, NetBIOS. Он передаёт всегда нажатие клавиатуры. И в обратную сторону, когда мейнфрейм передаёт в сторону терминала данные, он не может сказать, а я сейчас буду передавать IPX. Он всегда будет передавать картинку с экрана. Поэтому данные в мейнфрейме всегда бегут одинакового формата, и нет необходимости здесь указывать, что внутри лежит. В Ethernet у нас есть поле EtherType, которое в явном виде указывает на содержимое. Здесь просто поле Control, которое указывает на то, как этот кадр обрабатывается.

Cisco на это дело посмотрела и сказала, какой хороший протокол. Давайте мы попробуем из него сделать что-то пригодное для работы в Point-to-Point-Link. И она взяла этот формат, сказала, давайте, в Point-to-Point-Link нам адресация не сильно нужна. Мы оставляем 1-байтовое поле и забиваем его всеми единичками. 0xFF. 8 единичек в поле адрес. В поле Control неважно, что будет. Забиваем там 0x03, например. Просто обычный кадр. Контрольный байт указывал на то, в каком направлении кадр идёт. От терминала к мейнфрейму или от мейнфрейма к терминалу. 0x03 — это означает, что кадр непонятного назначения. Хорошо известное значение, которое надо будет запомнить. Control Word 0x03. Он много где встречается в современных сетях, на самом деле, этот контрольный байт.

И дальше Cisco сказала, в обычном HDLC сразу идёт содержимое, а мы возьмём и сделаем некое поле, которое никому не скажем, как называется, 1-байтовое. Но оно очень подозрительно смахивает на указание, что внутри лежит. И это 1-байтовое поле указывает, внутри там IPv4 или IPv6. И Cisco-вский HDLC уже не для мейнфреймов предназначен, он предназначен для обычных компьютеров, которые связываются между собой Point-to-Point-Link. А дальше уже указание, что внутри передаётся, и само мясо. Точно такая же чексумма и точно такой же способ передачи полезных данных внутри битиков, которые постоянно требуется передавать. Поэтому флаги идут, идут, идут, потом начинаем передавать данные, потом снова флаги, флаги, флаги. Этот механизм придумала Cisco, но он оказался очень интересным. На его основе придумали стандартный протокол, который называется PPP.

Точно так же, как в HDLC. Сначала передаются флаги, флаги, флаги, потом начинается мясо кадра. Однобайтовое поле 0xFF указывает на то, что адресация нам не сильно нужна. Оно нужно только для совместимости с древним протоколом HDLC. Точно так же контрольное поле 0x03 указывает, что это не кадры от мейнфрейма к терминалу и не кадры от терминала к мейнфрейму, а какие-то другие кадры. Дальше указывает, что внутри лежит. Только это уже не какое-то секретное поле, а поле, которое так и называется. Что внутри лежит? Протокол. И эти протоколы, которые можно укладывать внутрь, они хорошо известны, предсказуемы. Там 2 байта, 65 тысяч разных значений. Они делятся на 3 группы. Первая группа — это протоколы сетевого уровня. Например, IP. Мы говорим, что мы передаем кадр PPP-шный, внутри лежит IP и кладем внутрь 0x0021. Это значит IPv4.

Дальше идет мясо и чек-сумма. Если нужно будет передавать кадр не меньше, чем определенного размера, то можно добить поле с информацией содержимым. Так же, как в Ethernet это делается, если у нас ограничение на размер снизу есть. В PPP тоже можно предположить, что может быть ограничение снизу при необходимости использовано. Дальше. Если мы хотим согласовать работу некого протокола, нам нужны будут специальные служебные протоколы, которые в PPP позволяют согласовать работу какого-то протокола сетевого уровня, то за это будут отвечать специальные подпротоколы PPP, которые называются NCP — Network Control Protocol. Например, протокол, который согласует работу IP, будет называться IPCP, и он будет иметь код вложения 8021, шестнадцатеричная. И есть еще один специальный протокол, который называется LCP —

это Link Control Protocol, протокол управления всем соединением в целом. Он имеет хорошо известный номер C021. Здесь скорее случайность, что заканчивается все на 21, в других протоколах, например, не IPv4, там IPv6, MPLS, CDP, вложения будут другие. Но LCP — он всего один, и C021 — это хорошо известный номер LCP. PPP, соответственно, будет работать следующим образом. Сначала у нас начинает работать служебный протокол, Link Control Protocol. Он определяет, можно ли вообще передавать по этому линку хоть что-нибудь. Он проверяет подлинность пользователя, он устанавливает соединение, если это необходимо, он согласует размеры кадра сверху, снизу, он согласует, нужно ли какие-то символы экранировать, например, те самые 7E, если мы должны будем передавать,

может быть, конкретно эта среда не требует того, чтобы мы экранировали эти самые битики 6 единиц подряд. Если нужно будет экранировать что-то, то мы делаем это. Если не нужно, то он же согласует этот самый флаг. Он же будет, например, согласовывать мультилинк, чтобы передавать данные одного и того же кадра по нескольким проводам одновременно. Link Control Protocol — это самый главный директор всего того, что происходит. Он один раз отрабатывает в начале подключения по проводу, и дальше он успокаивается, говорит, «Ладно, работайте». После того, как LCP согласовал главные параметры подключения, в дело вступают протоколы NCP. Это служебные протоколы, которые умеют работать именно с каким-то конкретным отдельным протоколом, который можно будет передавать поверх PPP. Например, это будет IPCP, IP Control Protocol, либо IPv6CP.

ATCP — это ATM. IPv6CP. CDPCP — это для того, чтобы CDP-шные кадры можно было передавать. MPLSCP — все это протоколы, которые можно передавать поверх PPP. И для того, чтобы их передавать, нужно согласовать их возможность передачи, чтобы не гонять лишний раз кадры, которые сосед понять, например, не сможет. И для того, чтобы у нас два узла, которые связаны между собой PPP-шным каналом, начали передавать, например, пакеты IP друг другу поверх PPP, один должен сказать, я запускаю IPCP у себя, и второй должен сказать, я запускаю IPCP у себя. Они между собой обмениваются параметрами, говорят, окей, с одной стороны IPCP разрешили, с другой стороны IPCP разрешили, и у нас дальше начинает передаваться трафик IP, который как раз согласован с использованием IPCP, с обеих сторон.

PPP будет работать как поверх битовых сред, если у нас есть среда, в которой мы можем передавать отдельные битики, например, тот самый Serial Link RS-232, или какая-то синхронная цифровая иерархия. В любом случае мы можем сказать, что в такой среде мы можем гонять кадры, которые подобны HDLC, с этими самыми флагами, с битстаффингом, со всей фигней, и после того, как мы согласуем формат кадра, похожий на HDLC, соответственно, там мы внутри будем передавать кадры PPP-шные в том формате, в котором я показывал. У нас получается PPP Encapsulation, поверх него сначала работает LCP, потом начинает работать, например, NCP, какой-нибудь конкретный протокол типа IPCP, согласует параметры IP, и потом начинает работать уже передача данных в самом протоколе IP. Есть специальные служебные подпротоколы, которые отвечают за аутентификацию пользователя. Мы можем сказать, что в конкретном протоколе PPP,

в конкретном линке мы требуем для того, чтобы линк включился, чтобы пользователь с другой стороны подтвердил свою личность, чтобы он продемонстрировал, что он действительно тот, за кого себя выдает. Например, чтобы он продемонстрировал знание пароля, или чтобы он продемонстрировал обладание неким сертификатом, или что-то в этом духе. За это отвечают специальные служебные протоколы, PAP, CHAP, EAP. Их несколько таких протоколов, мы в курсе разберем два, PAP и CHAP. Это будет являться частью протокола LCP, это не какие-то отдельные, прямо специальные протоколы, типа того же самого IPCP или что-то еще. Это часть протокола LCP. PPP на самом деле позволяет работать не только поверх битовых сред. PPP позволяет использовать формат кадра свой даже в тех случаях, когда у вас используются другие канальные среды. Вы, например, можете взять, запустить Ethernet и поверх него сказать, а давайте мы в кадре Ethernet прямо сразу готовый кадр PPP будем укладывать.

У нас есть Ethernet-овский кадр с MAC-адресами, MAC-адрес получателя, MAC-адрес отправителя, указание, что внутри лежит. И что внутри лежит? Внутри лежит PPP-шный кадр. И дальше вы указываете, что внутри лежит PPP. Эта штука будет называться PPP поверх Ethernet или PPPoE. А дальше, после того, как мы внутрь Ethernet кадра вложили PPP-шный кадр, у нас по-прежнему будут все плюшки, которые PPP позволяет осуществлять. Мы можем и поверх одного и того же канала передавать трафик разных типов, приоритизировать его, и поверх канала мы можем взять и выполнить аутентификацию, и разные другие вещи тоже можем делать. Главное, PPP имеет природу point-to-point, так что у нас всегда есть понимание, что трафик ходит только между двумя узлами, никто больше его особо не видит. Можно сказать, что PPP можно вложить не только в Ethernet, но и в ATM. Это будет PPP поверх ATM. Все те же самые плюшки, которые есть для Ethernet с PPP,

то же самое ATM с PPP. Мы поверх какой-то среды провайдерской строим PPP-шную трубу, в ней проверяем подлинность пользователя, и в ней начинаем управлять конкретной передачей данных. У нас получается такой виртуальный провод между двумя участниками, построенный поверх ATM-ной среды. В LCP, как уже было сказано, есть проверка подлинности за счет одного из нескольких служебных протоколов, либо PAP, либо CHAP, либо EAP. Она может выяснить, кто с другой стороны находится, действительно ли с другой стороны находится тот, за кого себя выдает пользователь. И в этом случае вы можете не согласовывать передачу данных до тех пор, пока вы не выполните какие-то функции по безопасности. Обычно, когда мы используем PPP, мы это делаем, например, при подключении по VPN. Если в Windows взять и создать VPN-подключение, то там внутри этого VPN-подключения будет бегать PPP. И когда мы вводим логин и пароль в VPN-подключение,

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

Только третий вариант — EAP. EAP — это не протокол, который сам по себе что-то проверяет. Это такой фреймворк для того, чтобы поверх него можно было что-то другое передавать. Можно будет в EAP, например, сказать, давайте мы будем использовать по сути свой EAP, отправлять логин и пароль плейн-текстом, но зашифруем это все дело с TLS. И у нас получается в рамках EAP будет работать TLS труба, и в этой трубе мы плейн-текстом отправляем логин и пароль. По сети все передается зашифрованное, но получатель получает логин и пароль в открытом виде. Такие плюшки у EAP возможны, и поэтому он довольно популярен в современном мире. Как будет работать PAP? Уже, в принципе, все было сказано. Логин и пароль посылаются в открытом виде. Если у нас есть два роутера, роутер-1 и роутер-2, и они между собой хотят согласовать передачу данных по протоколу PPP с использованием Serial Link. С одной стороны Serial Link, с другой стороны Serial Link, хотя на самом деле не обязательно именно Serial Link.

Может быть, там PPPoE или что-то еще. Короче, что-то, где бегает PPP. Они запускают линк с PPP, в этом PPP начинает бегать LCP, Link Control Protocol, и тот узел, который требует, чтобы сосед представился, он говорит, я прошу у тебя, Configuration Request, использовать протокол аутентификации PAP. R2 говорит, я тебя не пущу дальше до тех пор, пока ты не покажешь логин и пароль. И R1 говорит, окей, раз ты просишь, я тебе показываю логин и пароль. Я согласен использовать конфигурацию с использованием PPP, и посылает сообщение PPP Authentication Request. Он показывает в явном виде свое имя, свой хостнейм, или имя пользователя, или что-то еще, и он в явном виде показывает пароль. Понятное дело, что если кто-то перехватит такое сообщение, то он увидит просто логин и пароль в открытом виде, и если злоумышленник захочет после этого представиться легитимным пользователем, ему это легко будет сделать.

Тем не менее, такой механизм есть. Если R2 согласен с тем, что пароль правильный, он говорит, все хорошо, PPP Authentication Acknowledge. В чем проблема у PAP? Во-первых, если злоумышленник подслушает, то можно будет повторно потом выполнить аутентификацию в предположении, что пароль не изменился. А во-вторых, если говорить про Serial Link, у Serial Link бывает часто конфигурация, что и с одной стороны узел говорит «Представься, пожалуйста», и с другой стороны узел говорит «Представься, пожалуйста». И часто пароли одинаковые с обеих сторон используют два роутера. Один роутер говорит «Я хочу, чтобы второй сказал, что его зовут R2, и пароль у него CISCO», а R2 скажет «Я хочу, чтобы сосед сказал, что его зовут R1, и пароль у него CISCO». И пароль одинаковый, CISCO-CISCO. Соответственно, когда R1 говорит «Я хочу сказать тебе, что пароль CISCO», R2, будучи злоумышленником, на самом деле говорит «О, я увидел твой пароль CISCO, я тебе тоже хочу сказать, что у тебя пароль CISCO»,

и, соответственно, зовут меня как-то там R2. И получается, что кто-то должен первым этот пароль в открытом виде спалить, и кто первый спалил, тот оказывается проигравшим. Поэтому PAP протокол довольно уязвимый, использовать его поверх недоверенной среды нельзя. Можно только, если вы точно знаете, что среда у вас абсолютно доверенная. Как жить, если у вас среда может быть недоверенной? PAP запрещено использовать, значит, нам нужен другой протокол. Для этого случая был придуман протокол CHAP. Опять же, у нас два роутера. Опять же, роутер R2 говорит «Я не уверен, что я с той стороны подключаюсь к тому, кому надо, поэтому я прошу, чтобы сосед, подключающийся с той стороны линка, предъявил логин, пароль, и этот логин, пароль проверился бы по некой базе». В этом случае то же самое у нас происходит. После работы LCP запускается R2 процедура,

говорит «Скажи пароль и проходи», configuration request, authentication protocol, CHAP. R1 говорит «Я не против того, чтобы согласиться с использованием CHAP». Он говорит configuration acknowledge, authentication protocol CHAP. То есть это LCP сообщает, что он не против согласовать дополнительную опцию аутентификации, которая не обязательна, но в принципе достаточно стандартная. Дальше. R2 присылает некий challenge. Он придумывает случайное число и говорит «Меня зовут R2, я тебе придумал случайное число, возьми его, пожалуйста, возьми тот пароль, который ты хочешь показать, и сложи это число с паролем, а потом посчитай от этого хэш по предсказуемому алгоритму». Этот challenge запоминается. Соответственно, он отправляется в линк. Дальше. Сосед берет тот challenge, который прислали, берет тот пароль, который у него есть, складывает всё вместе, считает от всего этого хэш, говорит «Меня зовут R1, я тебе посылаю хэш, который ты просил». То же самое делает R2.

Он знает, что пароль должен быть какой-то, например, CISCO. Он берет challenge, который он послал в этот канал, берет пароль, который он знает, какой должен получиться, складывает вместе, тем же самым алгоритмом считает хэш и сравнивает с тем, что пришло в response. Если результат совпал, значит, сосед брал тот же самый пароль для того, чтобы посчитать хэш. Если результат не совпал, то есть из одного и того же challenge и разных паролей у вас получились разные хэши, значит, сосед не знает, какой пароль должен быть, значит, мы ему отправим отбойник. В этом случае мы говорим либо CHAP success, всё хорошо, либо CHAP not success, значит, всё плохо. Эта штука не требует передачи пароля по сети. По сети передается одноразовый challenge и одноразовый же пароль, который зависит от этого самого challenge. Challenge придумываются каждый раз разные. И, соответственно, она защищает от атаки на повторное воспроизведение, но есть проблема всё равно с этим CHAP, заключающаяся в том,

что два узла, оба, которые должны будут использовать аутентификацию, они должны будут знать именно пароль в открытом виде. Если какой-то злоумышленник проникнет на роутер, он сможет увидеть в конфигурации этот пароль plaintext. Не очень приятная штука. Хочется, конечно же, чтобы пароли plaintext не хранились. Что еще можно будет сделать в PPP? Опция multilink PPP заключается в том, что если вы берете два роутера и берете несколько линков между ними, вы их можете соединить в один логический линк. Здесь показано, что у нас физических-то проводов два, но за счет того, что трафик по ним одновременно передается, они фактически воспринимаются как один большой линк, и трафик бежит по ним одновременно. Почему эта штука клевая? Потому что она производительность повышает, отказоустойчивость повышает. Это не так, как в EtherChannel, где у нас может быть, производительность повысится, а надежность точно повысится. Здесь точно повысится

и надежность, и производительность, потому что все линки утилизируются одновременно. Каждый конкретный кадр передается по всем линкам сразу. Но, соответственно, среди прочего она предполагает, что у вас есть какой-то кадр, который вы хотите передать по нескольким линкам одновременно. Вы его делите на части и передаете одну половинку в один линк, вторую половинку в другой линк. Что еще можно сделать, если вы включаете опцию multilink? Иногда multilink включают даже в ситуации, когда у вас между двумя роутерами просто один провод. Делается это специально для того, чтобы отправлять по одному и тому же проводу части одного и того же кадра не вместе, не монолитно. Например, если у вас есть какой-то кадр, который надо отправить внепланово, очень резко, очень быстро, то есть пришел какой-то длинный-длинный-длинный торрент, вы его делите на части по чуть-чуть и начинаете отправлять по частям.

Эту часть отправили, эту часть отправили, а потом прибегает какой-то суперважный кадр, но маленький, с мигалкой, голосовой, например. И вы его можете взять и в серединку между кусочками другого кадра вставить. Эта штука будет называться interleaving, то есть когда вы можете некий кадр с большим приоритетом отправить в середине между кусками другого кадра, который вы порезали на части. И link fragmentation — это как раз то, что вы кадры отправляете по частям. Это немножко повышает накладные расходы, но совсем чуть-чуть, зато повышает качество работы сети за счет того, что задержки для важных приоритетных кадров минимизируются. Плюс к тому, естественно, если один из проводов выходит из строя, то трафик начинает ходить только по второму, производительность при этом, правда, падает, но тем не менее надежность системы из двух проводов выше, чем надежность системы из одного провода. Если один провод отвалится, у вас есть второй. Это что касается теории про протокол

PPP. Продолжение следует...