PPP в Cisco IOS

Давайте поговорим про практику, про настройку PPP конкретно на Cisco. Эта штука есть. PPP вы можете использовать как в режиме включить его на serial-линках, так и в режиме поднять VPN, того же PPTP или L2TP, где действительно PPP используется в качестве нижележащего протокола. Когда вы используете VPN-подключения с L2TP, там внутри бегает PPP. И PPTP тоже, когда вы используете, там внутри бегает PPP. Вы можете использовать PPP на подключении PPPoE к вашему провайдеру. Вы можете использовать PPP при подключении PPP поверх Ethernet, поверх ATM к вашему провайдеру, если вы используете ADSL. PPP в Cisco используется довольно часто. Для начала давайте поговорим про то, как выбрать конкретный формат кадра PPP, если у нас есть, например, serial-линк. В serial-линке мы можем выбирать формат кадра по своему усмотрению.

По умолчанию на последовательных интерфейсах, на serial-линках, на Cisco работает инкапсуляция своя фирменная HDLC-шная. Она ни с кем не совместима. И поэтому, если у вас есть две Cisco, вы можете связать две Cisco между собой. С помощью serial-линка вы покупаете кабель, говорите, эта Cisco у нас будет DCE, эта Cisco будет DTE. DCE — это ведущий, задаёт clock rate, DTE — ведомый, clock rate принимает. И дальше мы говорим, как битики будут передаваться, задали, указали скорость, указали bandwidth, всё сделали, всё хорошо. Но дальше надо выбрать, в каком формате кадра мы будем передавать. И команда encapsulation HDLC будет указывать, что используется фирменный Cisco формат Cisco HDLC. Это не стандартный ISO-шный формат кадра HDLC, потому что есть это самое однобайтовое поле, секрет, что внутри лежит. Поле, которое называется проприетарное поле. Но в любом случае стандартных железок с инкапсуляцией HDLC

с serial-линками вы встретить не сможете, просто по той причине, что стандартный протокол HDLC — это только протокол для мейнфреймов. Он не предназначен для связывания между собой просто каких-то абстрактных узлов. В принципе, можно encapsulation HDLC даже не писать. Если вы на serial-линке зайдёте, скажете interface serial 0/1/0 или 1/0, или какой-то там у вас serial-линк будет, вы можете не писать encapsulation HDLC, он и так по умолчанию будет использовать именно его. Если вы указываете его, он просто даже не будет показываться в конфигурации, потому что это настройка по умолчанию. После того как вы задали encapsulation HDLC, как только с обеих сторон задали, интерфейс у вас поднялся, дальше на интерфейс можно IP-шники вешать, IP поверх HDLC бегает прекрасно, никаких сложностей с этим нет. Как посмотреть, что HDLC работает на интерфейсе? У нас есть команда, наш любимый show interface,

который показывает состояние канального уровня, и показывается, что интерфейс у нас на физике в UP, и на канальном уровне тоже в UP. Показывается MTU, максимальный размер кадра, bandwidth, но он берётся из команды bandwidth на интерфейсе, если она не задана, то serial-линк обычно у нас полуторамегабитный. Задержка сериализации 20 тысяч микросекунд или 20 миллисекунд. Надёжность и загрузка. Encapsulation HDLC скрытно намекает на то, какой формат кадра у нас используется. Если мы хотим переключить интерфейс в PPP, то команда будет иметь предсказуемый вид encapsulation PPP в настройке того же самого serial-линка. И после этого на этом же линке можно и IP назначать, и access-листы вешать, и всё, что мы делаем на интерфейсах. Это получается нормальный интерфейс, который позволяет отправлять IP-пакеты. Команда show interface покажет нам,

что у нас на физике интерфейс в UP, нолики-единички нормально бегают, на канальном уровне он тоже в UP, PPP согласовался. Дальше покажется MTU, bandwidth, delay. Если мы не задали bandwidth, то он будет полтора мегабита по умолчанию. И дальше начинается интересное. Encapsulation PPP намекает на то, какой тип кадра у нас используется. LCP open. Это означает, что Link Control Protocol согласовал передачу данных по этому проводу, и он не имеет никаких возражений. LCP дал отмашку, что линк хороший, линк работает. В строчке open показываются NCP-протоколы, которые отработали, и они дали отмашку, что можно использовать какие-то протоколы сетевого уровня. В нашем случае мы видим, что согласован протокол CDPCP на роутере R2.

R2 сказал, CDP можно принимать. А IPCP он сказал stopped. Это значит, что у него IPCP тоже есть. Он попытался согласоваться, но не смог, потому что с той стороны IPCP не присутствует. С той стороны только CDPCP есть. CDPCP — это CDP-протокол, а IP здесь нету. На роутере R1 не назначен IP-адрес. На роутере R1, на интерфейсе serial link, IP не поднялся. Как следствие, LCP со стороны роутера R1 сказал всё хорошо, а NCP, который он предоставил, это был только CDPCP. И CDPCP с одной стороны, и CDPCP с другой стороны отработали и сказали всё хорошо. CDP-шные кадры в этом линке у нас бегают нормально, списки соседей видны. А дальше IPCP с одной стороны ткнулся в другой,

и здесь ничего не обнаружил. Поэтому IPCP со стороны роутера R2 сказал, извините, мне тут делать нечего. Если роутер R1 на свой интерфейс повесит IP-шник, то IPCP с обеих сторон согласуется, и IP у нас тоже можно будет передавать. Если мы захотим использовать на цисках аутентификацию на serial link, то у нас будет два способа это сделать, но тот, который я вам покажу — это наиболее правильный способ. Во-первых, нам нужно будет выбрать, кто конкретно будет требовать предъявить логин и пароль, а кто будет согласен его показать. Никто не мешает, когда у нас есть две железки и serial link между ними, сказать, что сначала одна должна будет задать вопрос: ты кто? Покажи логин и пароль. А потом другая должна будет сказать: ты кто? Скажи логин и пароль. Никто не мешает обеим железкам показать логин и пароль друг другу. Это абсолютно независимые два процесса,

и роутер R1 и роутер R2 могут затребовать от соседа показать логин и пароль независимо ни от чего. Для того чтобы настроить отправку логина и пароля по serial link, если вдруг сосед потребует аутентификацию с помощью протокола PAP, мы можем указать следующую команду: ppp pap send-username логин password пароль. Вы должны будете с другой стороны сказать, что сосед может прислать имя пользователя и пароль такие-то. Если вы просто пропишете ppp pap send-username чего-то там, то без затребования со стороны соседа эта команда работать не будет. Для того чтобы это всё начало работать, R2 должен сказать: ты вообще кто? И «ты вообще кто» на интерфейсе указывается с помощью ppp authentication pap. Мы говорим: мы не пустим соседа

до тех пор, пока он не покажет логин и пароль. И логин и пароль, который он будет присылать, мы будем проверять по локальной базе пользователей, по той же самой, которая у нас используется для входа в систему по умолчанию. Мы указываем, что у нас есть какой-то username, указываем его логин, указываем password и пароль. Здесь можно использовать даже secret, username чего-то там secret чего-то там. Если захотите, в этой ситуации secret покатит. Если вдруг вы захотите с обеих сторон сделать одновременную проверку, то вы должны будете с обеих сторон задать ppp authentication pap, с обеих сторон в локальной базе внести username с паролем и с обеих сторон на интерфейсе serial указать ppp pap send-username чего-то там. Но по умолчанию, как правило, в PPP-шных линках крайне редко требуют аутентификацию с обеих сторон. Если мы говорим про, например, реальный сценарий использования PPP, чаще всего это выглядит как то,

что у вас есть провайдер, он подключает вас Ethernet-ом, у вас есть какой-то роутер, который подключается к провайдерскому коммутатору, и дальше у провайдера есть где-то роутер, который называется BRAS, Broadband Remote Access Server. И вы на него подключаете PPPoE-шный канал, и в этом PPPoE-шном канале вы должны будете показать логин и пароль своему провайдеру, а провайдер должен сказать: я тебя не пущу до тех пор, пока ты не покажешь логин и пароль. Поэтому, как правило, аналогичная команда send-username и password чего-то там прописывается на клиенте. А что-то типа ppp authentication pap прописывается на чём-то типа сервера. В случае если мы две свои собственные циски serial-линком связываем, то, понятно, там никакого сервера и клиента нету, но всё-таки PPP чаще всего используется именно в средах, где у нас есть чётко выраженный

клиент и чётко выраженный сервер, если мы говорим про среду с аутентификацией. Если мы хотим использовать CHAP, то с CHAP всё попроще. С CHAP мы должны будем сделать следующую вещь. У нас есть роутер R1, есть роутер R2. На R2 мы говорим: мы тебя не пропустим до тех пор, пока ты не покажешь логин и пароль. Мы посылаем configuration request соседу, сосед говорит: окей, я согласен. Мы ему посылаем challenge, говорим, как нас зовут и какой challenge мы только что придумали. Сосед говорит: я принял от тебя challenge 1, 2, 3, 4, 5. Я достаю из широких штанин пароль, который соответствует твоему юзеру R2, который ты мне прислал. Беру тот пароль, который у меня в локальной базе хранится, считаю от всего этого дела хэш и присылаю тебе итоговый хэш. И заодно указываю, как зовут меня. R2 в своей локальной базе копается, находит пользователя R1,

находит его пароль, считает challenge, который он послал в канал, плюс пароль пользователя R1, берёт хэш, сравнивает с тем, что пришло. Если совпало, замечательно. Для того, чтобы это все работало, вам нужно будет в локальной базе пользователей и на одном, и на другом роутере прописать соответствующие учетные записи. Учетные записи должны быть следующие. На роутере, который будет работать с... На обоих роутерах у вас должен быть пароль одинаковый, в нашем случае там education, но учетка, именно логин для каждой учетной записи должен совпадать с хостнеймом соседа. На роутере R1 мы указываем учетную запись R2, на роутере R2 мы делаем учетную запись R1. И вот эта вот штука, она позволит в случае, когда роутер R2 говорит «Меня зовут R2,

на тебе челлендж», и получив ответ от роутера R1, соответственно, он пойдет в свою локальную базу, посмотрит, где у нас учетка пользователя R1, найдет его пароль education, возьмет тот челлендж, который был изначально отправлен, посчитает хэш и сравнит с тем хэшем, который прибежал. Точно так же, когда R2 посылает челлендж R2, говорит «Меня зовут R2», и посылает этот самый челлендж какой-то случайный. R1 для того, чтобы составить ответ, составить респонс, он находит учетку, соответствующую соседнему хостнейму, и берет пароль, соответствующий ей. Поэтому пароли должны будут совпадать, а имена учеток должны будут совпадать с хостнеймом соседа. Если у вас все хорошо сделано, то канал поднимается, и у вас все замечательно срабатывает. Если что-то пошло не по плану, например, пароль неправильный, то в этом случае линк будет находиться в состоянии up-down. То есть на физике он будет в апе, на канальном уровне PPP

не даст отмашку, что линк согласован, и, соответственно, у нас будет интерфейс line-протокола с down. Лечится это не лечится, а трэблшутится это дебагом. Есть команда debug.pp authentication, она показывает, как у нас бегают вот эти самые паповские, чаповские сообщения. Например, у нас вот есть канал, на котором настроены требования процедуры проверки подлинности с помощью чапа, но что-то как-то вот пошло не по плану. Видим, что мы посылаем сообщение «Скажи пароли, проходи», посылаем челлендж, говорим «Нас зовут R2», «Пожалуйста, в ответ на этот челлендж пришли мне ответ». Видим, что через 10 миллисекунд приходит ответ, входящий респонс от роутера R1, который вот чего-то нам прислал. Дальше мы проворачиваем тот ответ, который мы получили, сравниваем с тем паролем, который хранится у нас в базе, и говорим «Что-то не получилось». Outbound сообщение,

исходящее сообщение, «Failure» с фразой «Authentication failed». Понятное дело, что с той стороны точно так же DebugPppAuthentication можно включить, и по большому счету будет все то же самое, только будут входящие и исходящие сообщения изменены местами. Если пароли правильные и все хорошо работает, то вы должны будете получить примерно вот такой вот вид. То есть мы видим, что у нас есть челлендж, который мы отправили соседу, указав, как зовут нас. Получаем респонс от соседа, где он показывает, как зовут его. Это его юзернейм, если хотите. И видим, что у нас все совпало. Вместо фейлор мы посылаем сообщение «Success». И после того, как «Success» проходит, сразу пробегает сообщение, что line-протокол is up. Если вдруг вы захотите включить мультилинк, в экзамене этого нету, но просто показываю, как это выглядит, потому что в реальности очень часто можно будет

мультилинк встретить на всяких вот этих вот средах, типа VPN-туннель или чего-то еще. Выглядит это будет следующим образом. У нас есть воображаемый интерфейс, который называется мультилинк. Мультилинк, то есть мы не на физические интерфейсы в случае с мультилинком в MW6 IP-адресе, а на искусственный вот этот самый мультилинк-интерфейс, у которого есть номер, ну типа как порт-группа. И, соответственно, на него даем все настройки, а на физических интерфейсах, которые входят в эту порт-группу, мы указываем команду ppp-multilink и ppp-multilink-групп чего-то там. На всех интерфейсах, которые входят, мы указываем эту штуку. С другой стороны, аналогичные настройки у нас будут. То есть на роутере 1 эта физика и эта физика объединяются в группу. И здесь эта физика и эта физика объединяются в группу. Никакой специальный протокол, как в Изорченнеле, здесь запускать не нужно, потому что сам ppp не позволит согласовать передачу данных по вот этому проводу, если эти провода действительно не втыкаются в одну и ту же железку.

То есть у нас сам ppp отвечает за то, чтобы проверить процедуру согласования согласования вот этого самого мультилинка. Траблшутится с помощью команды showpp all, которая покажет, что у нас есть физические интерфейсы, где отработал lcp. И вот этот плюсик показывает, что все хорошо, протокол lcp дал отмашку, что на этом линке работать можно. А на мультилинке у нас будет работать ncp протоколы. ipcp сказал можно, cdpcp сказал можно. Давайте попробуем это дело пошчупать. Благо у нас на наших роутерах шчупать это дело тоже можно. Так. Enable. ConvT. Interface. Serial. 1.0. Вот этот вот Serial Link у нас на роутере смотрит на центральный роутер. Соответственно, я на нем указываю, во-первых, no shutdown.

Понятное дело, что интерфейсы на роутерах выключены, их надо как минимум включить. А во-вторых, мы на него можем повесить тип инкапсуляции. Encapsulation. PPP. По умолчанию там HDLC. Как только я сказал, что тип инкапсуляции у нас используется PPP, lcp сказал, о, я вижу, что я должен запуститься на этом интерфейсе. Попробовал потыкаться палочкой в соседа, не обнаружил там ответ и сказал, знаете, я не даю отмашку, что на интерфейсе можно работать. Поэтому линк у нас выключился на этом интерфейсе. Do show interface serial 1.0. Вот показывается, что физика у нас в апе, битики передаются, а кадрики не складываются, потому что с той стороны у нас не PPP. С той стороны у нас HDLC по умолчанию. С одной стороны мы отправляем одни кадры, с другой стороны ловим другие. В общем, как-то не складывается ситуация.

И вот, lcp у нас пытается потыкать палочкой соседа, ничего не выходит, в фазу open он не перешел. Дальше. Для того, чтобы у нас PPP согласовался, надо с той стороны тоже что-то включить. И вот я на центральном роутере сейчас буду заниматься увлекательнейшим действием. Интерфейс range с serial-ами не работает, поэтому interface serial serial 2.0 no shutdown encapsulation PPP serial 2.1 no shutdown encapsulation PPP и так, 3-3 no shutdown encapsulation PPP я указал, что у меня есть три интерфейса, на которых работает encapsulation PPP и, соответственно, у нас поднимается

на тех линках, которые смотрят на соседей, где PPP тоже включен, линк сразу в состоянии up. И вот здесь пробегает тоже сообщение, что на нашем маленьком роутере PPP согласовался. Если я сейчас выполню команду show interface serial 1.0, я увижу, что у нас линк в API, соответственно, физика в API, линк тоже в API. Показывается lcp open, то есть он согласовал принципиальную возможность работы по каналу. Он сказал, что я согласовал протокол cdp-cp, как понятно, это протокол, который согласует передачу cdp-шных кадров. И у нас между двумя роутерами на этих интерфейсах будут теперь видны соседи. Do show cdp-neighbors. Вот у нас core-роутер, видно на интерфейсе serial 1.0. Мы на него смотрим serial 1.0, он на нас смотрит serial 3.3. Ну, в общем, похоже на правду. Что касается... Что касается...

Что касается процедуры проверки подлинности. Для того, чтобы заставить наш роутер показать логин и пароль, можем попытаться попросить его сказать, покажи нам, пожалуйста, логин и пароль с помощью команды ppp. Дальше у нас здесь есть authentication. И здесь мы можем выбрать, какой именно тип проверки подлинности мы можем запросить со стороны соседа. Либо pap, либо chap, либо чего-то, чего в курсе у нас нет. Понятное дело, что если вы в реальности будете что-то требовать, то имеет смысл требовать только вот этого. Потому что что pap, что chap, что ms-chap, они прям совсем небезопасны. Поэтому в реальности, если вдруг вы будете требовать проверку подлинности, то надо использовать только eap, если ваш сосед это умеет. А если не умеет, то надо 10 раз подумать перед тем, как использовать вообще что-нибудь. Но в нашем случае мы потребуем сначала pap. Мы скажем, что

дорогой сосед, центральный роутер, пожалуйста, перед тем, как пытаться согласовать канал, покажи нам логин-пароль. Или я могу сейчас сказать, что я на центральном роутере сделаю эту настройку, благо она везде одинаковая. Так, интерфейс serial 2.0, ppp, authentication, pap. Так, 2.0, 2.1 и 3.3. ppp, authentication, pap. И у нас линки погасли. Погасли они потому, что сосед обнаружил, что требуется процедура согласования канала, а она пройдена не была. Поэтому он линк от греха подальше выключил. Для того, чтобы в сторону соседа отправить

такой логин и пароль, который ему позволит подключиться, мы должны будем прописать здесь команду. Команда будет иметь вид ppp, pap, send username. И давайте используем нашу любимую Cisco Cisco. Cisco, password Cisco. И со стороны центрального роутера я должен буду сказать, что при подключении по протоколу pap можно предъявить логин и пароль, и эти логин и пароль могут быть Cisco. username Cisco, password Cisco. Это просто я в обычной базе пользователей завожу юзера. И вот поднимаются два канала. Так, что-то у меня здесь айпишники какие-то полезли. Интересно, девки пляшут. Так, вот поднялись два канала. Поднялся канал на первый комплект и поднялся канал на восьмой комплект.

Мы прописали команду, что можно послать username Cisco и password Cisco. Прописали, что с другой стороны в локальной базе пользователя есть user Cisco и пароль Cisco. И получили, что канал у нас действительно согласовался. Если вдруг мы захотим использовать chap, по большому счету здесь есть соответствующая фича. Мы можем прописать chap password, мы можем прописать chap hostname и сделать так, чтобы у нас были прописаны именно отдельные логины, отдельный пароль для соседа, который будет использоваться. Но на экзамене нужно будет продемонстрировать процедуру, которая предполагает, что вы просто указываете, что у вас есть юзернейм, и этот юзернейм будет совпадать с hostname соседа. Поэтому сейчас для того, чтобы продемонстрировать работоспособность chap,

делаем следующую штуку. На нашем маленьком роутере мы пишем юзернейм, давайте, core, подчёркивание, r, password, Cisco. Здесь очень важно, чтобы юзернейм на нашем маленьком роутере в базе пользователей совпадал с тем, что будет присылать нам центральный роутер. Он будет говорить, что его зовут core_r, и поэтому для того, чтобы пароль ему отправить правильный, он должен быть в учётке с названием core_r. И дальше со стороны нашего маленького роутера делать больше ничего не нужно. Мы создали учётку, мы сказали, что если вдруг мы будем посылать chap-сообщение с хэшем от пароля, когда core_r нас попросит прислать такой response, мы найдём в локальной базе пользователей юзера core_r, возьмём его пароль, когда он нам чего-то пришлёт, мы это чего-то сложим

с его паролем Cisco и пошлём в ответ хэш. Со стороны центрального роутера интерфейс serial 1.0 указываем, так, что не так, serial 2.0, ppp, chap, 2.1, chap и дробь 3, chap. Связь у нас не отваливается, потому что LCP уже провёл процедуру согласования пользователя и пароля. Когда мы изменили метод, LCP сказал, но всё равно там уже понятно, что с той стороны находится свой чувак. Поэтому он не выключает нам линк. Он считает, что линк уже проверенный, пусть даже с использованием какого-то не того метода, который сейчас был запрошен. Но если сейчас мы будем проверять по chap логины и пароли,

которые нам будут присылать, то нам нужно будет убедиться, что сосед будет присылать правильные логины и пароль. И эти логины и пароли можно будет проверить по локальной базе пользователей. Поэтому в настройке роутера core_r мы делаем username R01 password Cisco. И username R02 password Cisco. Username R08 password Cisco. У себя переименуйте, пожалуйста, железку, если она вдруг ещё не переименована. Сделайте большую букву R и 01, 02, 08. Вот такой юзернейм должен быть у нас. И дальше, после того, как всё будет сделано, интерфейс serial 1.0 мы выключаем, включаем заново. Shut, no shut. Интерфейс падает, поднимается. И заново пересогласуется. Сейчас он пересогласуется именно с использованием chap. Что-то не пересогласовывается.

Do show interface serial 1.0. Что у нас не согласуется? LCP что-то не согласовал. Говорит LCP closed. Прекрасный пример на troubleshooting. Включаем debug. Debug. Debug ppp authentication. И чего? Interface serial 1.0. Shut. О, он только включился, а я его выключил. No shut. Он, походу, просто тормозил. Но как раз я успел поймать debug. Debug у нас имеет следующий вид. Нам приходит challenge. Вот это сообщение маленький мой роутер показывает, потому что я включил дебаг. Так оно, конечно, не видно. Нам приходит challenge, в котором написано, что прислал его некий core_r.

Мы находим в локальной базе пользователей юзера, у которого имя совпадает с core_r. Берём его пароль. Где он есть-то? Вот он, его пароль. И складываем с тем challenge, который прислал нам сосед. Берём от всего этого дела хэш и посылаем сообщение response, где в явном виде указываем наш логин и в явном виде указываем тот самый response. И приходит в ответ сообщение success. Как только оно приходит, немедленно интерфейс поднимается. Вот 883 миллисекунда и 883 миллисекунда, мы видим, что интерфейс поднялся. Я исключительно ловко умудрился попасть своим shutdown ровно в тот самый момент, Когда интерфейс поднялся, прям в ту самую миллисекунду. Это надо уметь. После того как интерфейс у меня упал, он снова поднялся, снова ту же самую процедуру прошел. К нам пришел челлендж от имени Core R. Мы нашли в локальной базе пользователей юзера Core R, взяли его пароль,

сложили с этим челленджем, который пришел, отправили в ответ хэш от челленджа и пароля в виде респонза и получили ответ success. Если вдруг у нас в нашей локальной базе пользователей пароль был бы неправильный, юзернейм core_R, password cisco1, заведомо неправильный пароль, интерфейс serial 1.0, мы видим, что посылаются постоянно раз в две секунды сообщения «покажи пароль и проходи». Мы в ответ посылаем свои сообщения, наш пароль будет cisco1, и нам в ответ приходит сообщение «пароль неправильный, скажи правильный и проходи». Тут можно долго наблюдать. Я сейчас возьму и поменяю пароль на правильный, и мы увидим, что всё хорошо пройдет с первого раза.

Вот это сообщение. Ещё пока с неправильным паролем. К нам приходит сообщение от имени Core R. «Скажи хэш». Челлендж приходит. Мы находим в локальной базе пользователя, который зовется Core R. Берем его пароль, считаем хэш, отсылаем его в респонзе, и вместо success приходит failure. Говорит, пароль неправильный. Как только пароль поменялся, мы получаем ожидаемый результат. Видим success, у нас всё хорошо, всё работает. Так что вот так устроен CHAP. Если вдруг вы захотите его понастраивать, то настройка его довольно простая. Должны быть правильно прописаны пароли, и в настройке интерфейса должно быть указано PPP Authentication, либо PAP, либо CHAP. Предлагаю на этом тему считать закрытой, потому что больше тут особо смотреть нечего. Мультилинка на экзамене не будет. В реальности с PPP, если вы будете сталкиваться, только в провайдерских каких-то темах,

а там, как правило, своя атмосфера, и если вдруг вам придется работать со всем этим делом, то там вас сразу в провайдере и научат. Так что на предприятии, если вдруг с PPP придется сталкиваться, то крайне ограниченно, и вот этого объема знаний для работы с сетью предприятия вам должно, по идее, хватить. А на сегодня всё. Спасибо за внимание, пока-пока.