recv request from что это
Recv request from что это
Дорогие пользователи! У нас появился новый форум на платформе tp-link.community (Сообщество)
Форум доступен по ссылке https://community.tp-link.com/ru
Просим Вас отнестись с пониманием к новому форуму, он находится в стадии доработки и в скором времени будет полностью завершен.
Если при регистрации в Сообществе Вы укажете адрес электронный почты, который используете на данном форуме, то Ваши данные будут перенесены на форум Сообщества автоматически.
Также, если на форуме Сообщества Ваш никнейм будет занят, то Вам предложат сменить его или оставить, но с приставкой «_RU».
Убедительная просьба не дублировать темы на старом/новом форуме.
Обрывы соединения WAN
Обрывы соединения WAN
Сообщение GiNiX984 » 27 янв 2017, 07:50
Название темы : Обрывы соединения WAN
Аппаратная версия устройства : V1
Провайдер : Интернет Дома от Билайн (Казахстан)
Тип подключения : L2TP
Описание проблемы :
Вынужден обратиться в связи с проблемой, решения которой самостоятельно найти не получается.
Суть в следующем:
Периодически (4-6 раз в день) WAN-индикатор загорается оранжевым, соединение с интернетом обрывается. Иногда роутер сам возвращается в рабочее состояние, оранжевая индикация сменяется синей. Иногда этот «оранжевый висяк» лечится ручным переподключением роутера, иногда даже не с первого раза (выключил, подождал секунд 15, включил, индикатор опять оранжевый, выключил, подождал ещё раз секунд 15, включил, индикатор загорелся синим).
Настройки провайдера прописаны верно, заходил на официальный сайт Beeline Казахстан, всё досконально перепроверял (L2TP-Россия, динамический IP, защита Wi-Fi WPA2-PSK/AES и т.д.)
В чём может проблема:
• Интернет-кабель тянется с крыши, в квартиру заходит на 2 метра всего. Роутер стоит в гостиной. Покупал специальный переходничок с двумя WAN-выходами. В одни конец вставлен подъездный кабель, в другой конец – дополнительный домашний кабель, который уже непосредственно подключён в роутер (в WAN-порт). Может быть проблемный переходник? Грешил на него, но в целом он своё дело делает, интернет работает, значит вряд ли дело в переходнике.
• В настройках роутера в разделе WAN есть поле «максимальное время простоя». По умолчанию стоит 15 минут. В попытках решить свою проблему я подумал, что это может помочь. Мол «зачем мне нужно, чтобы устройство через каждые 15 минут простоя разрывало соединение?». Поставил «всегда активно», «время простоя – ноль». Может ли это как-то усугубить ситуацию? Перегружать роутер?
• Бывали проблемы с невозможностью подключения отдельных устройств к интернету при том, что другие устройства исправно работали. Эту проблему решил путём резервации IP-адресов под конкретные устройства (привязка к MAC). Может это вызывать обрывы WAN (оранжевый индикатор)?
Если есть какие-то ещё мысли, просьба, откликнуться.
С провайдером разговаривал, рекомендуют то же, что пишут везде в интернете: подключите кабель не в роутер, а напрямую в ноутбук и понаблюдайте. Хорошая идея, но проблема в том, что интернет вылетает не через равные промежутки времени, а тогда, когда ему вздумается. Т.е., подключив кабель в ноут, я могу просидеть весь день за ноутом в попытке поймать разрыв. Столько свободного времени у меня нет.
Dhcps recv inform from
9.3 Структура, формат и назначение DHCP пакетов (сообщений): DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем разбираться с протоколом DHCP в рамках подготовки к CCNA. В протоколе DHCP для сетевого инженера нет ничего сложного, вы в этом убедитесь сразу после того, как мы с вам разберемся со структурой DHCP-пакетов и увидим как сервер и клиент отправляют другу другу сообщения, в этой записи мы разберем четыре самых часто используемых DHCP-сообщения: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK.
Перед началом я хотел бы вам напомнить, что ознакомиться с опубликованными материалами первой части курса можно по ссылке: «Основы взаимодействия в компьютерных сетях».
9.3.1 Введение
Здесь мы рассмотрим структуру DHCP пакета и поговорим о их назначении DHCP-сообщений. В частности будут рассмотрены такие виды DHCP сообщений как: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK. Дам небольшое пояснение по поводу того, что я буду подразумевать под словом DHCP-пакет, а что под DHCP-сообщением. Под первым я буду понимать физическую сущность со строгой структурой, а под вторым я буду понимать логический смысл, который несет в себе физическая сущность, пакет всего один, а сообщений много и они разные.
9.3.2 Общая структура DHCP пакета, назначение его полей и их размер
Мы довольно наглядно рассмотрели процесс получения IP-адреса по DHCP в Cisco Packet Tracer, но хотелось бы понимать то, как устроены пакеты DHCP, которыми обменивается клиент и сервер. Тут у меня для вас две новости:
На рисунке ниже вы можете увидеть структуру DHCP-пакета, там показаны поля DHCP пакета и их размер.
9.3.1 Структура DHCP-пакета, поля и их размер
Сама по себе картинка нам еще ничего не дает, кроме названия полей в DHCP-пакета, также мы видим, что пакет разбивается на строки (иначе, машинные слова), каждая строка 32-а бита. Крайний левый бит в слове имеет нулевой порядковый номер, а крайний правый бит 31-ый. Размер всех полей в битах кратен числу 8.
Давайте теперь поговорим более подробно о каждом поле DHCP пакета. Для их описания я подготовил таблицу.
Объемная, но довольно простая и логичная структура DHCP-пакета, от которой можно отталкиваться при рассмотрении различных DHCP-сообщений.
9.3.3 Сообщение DHCPDISCOVER или как клиент ищет DHCP сервер?
Начнем мы с сообщения DHCPDISCOVER, как вы помните, это сообщение использует клиент для поиска DHCP-серверов в своей канальной среде. Чтобы не быть голословными, будем смотреть на примере дампа из Wireshark. Для начала посмотрим на то, как клиент инкапсулирует сообщение DHCPDISCOVER.
9.3.2 Как инкапсулируется и передается по сети сообщение DHCPDISCOVER
В заголовке IP-пакета в качестве адреса источника клиент использовал 0.0.0.0, а IP-адрес назначения опять широковещательный – 255.255.255.255. DHCP упаковывается на транспортном уровне в UDP, поскольку сообщение DHSPDISCOVER генерирует клиент, он в качестве порта источника использует значение 68, а в качестве порта назначения 67. Ну и наконец мы видим, что Wireshark смог определить, что это сообщение DHCPDISCOVER. Попробуем определить и мы.
9.3.3 Формат сообщения DHCPDISCOVER
Для этого заглянем внутрь DHCP-пакета и проанализируем значения его полей. В самом верху мы видим тип сообщения Boot Request (это поле opcode), значение 1 говорит нам о том, что это клиент что-то посылает серверу. Следующих два поля сообщают нам, что на канальном уровне используется Ethernet и указана длина аппаратного адреса. Поле Hops имеет значение 0, а значит клиент считает, что он находится с сервером в одной канальной среде. Когда клиент начал общение с сервером, он сгенерировал уникальный Transaction ID, по которому можно будет отличить этот процесс получения IP-адреса от какого-нибудь другого. Поле Second Elapsed никому не интересно, тут обычно стоит 0.
Далее клиент сообщает серверу о том, что ему не нужно сообщать hostname сервера и не надо давать ссылку на Boot-файл. Ну а поле Magic Cookie сообщает о том, что начались DHCP опции и нам нужно обратить внимание на следующий рисунок.
9.3.4 DHCP опции, которые передает клиент серверу в сообщение DHCPDISCOVER
Опция с кодом 60 служит для того, чтобы клиент мог рассказать серверу о том, кто является разработчиком программного обеспечения DHCP-клиента, и какая версия ПО используется, опираясь на эту опцию сервер может понять с какими опциями умеет работать клиент. DHCP опция с кодом 55 служит для того, чтобы клиент мог запросить у сервера необходимые на его взгляд параметры, при этом не факт, что сервер сможет сообщить клиенту все указанные параметры.
Список опций завершает опция с кодом 255, так сервер поймет, что опций больше не будет и само DHCP-сообщение закончилось.
9.3.4 Сообщение DHCPOFFER или как сервер предлагает клиенту IP-адрес?
Перейдем к сообщение DHCPOFFER, которым сервер отвечает на запрос DHCPDISCOVER от клиента, тут самый первый вопрос, который у вас должен возникнуть: а как сервер отправляет сообщение DHCPOFFER – broadcast или unicast. Правильным будет ответ: сервер может передавать сообщение DHCPOFFER как широковещательно, так и адресно, вот что написано в RFC протокола DHCP.
Если поле giaddr в сообщении DHCP от клиента отлично от 0, сервер передает все отклики на сообщения в порт DHCP server транслятору BOOTP, адрес которого указан в поле giaddr. Если giaddr = 0, а поле ciaddr отлично от нуля, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному адресу ciaddr. Если giaddr = 0, ciaddr = 0 и установлен флаг broadcast, сервер передает сообщения DHCPOFFER и DHCPACK по широковещательному адресу 0xffffffff. Если флаг broadcast не установлен, а giaddr и ciaddr имеют значение 0, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному аппаратному адресу клиента и yiaddr. Во всех случаях, когда giaddr = 0, сервер отправляет сообщения DHCPNAK по широковещательному адресу 0xffffffff.
9.3.5 DHCPOFFER — сообщение, которое отправляет сервер в ответ на DHCPDISCOVER
Если посмотреть на дамп протокола IP, то можно будет увидеть, что сервер не просто направил клиенту DHCPOFFER юникастом, но и более того, в поле IP-адрес назначения был подставлен IP-адрес, который был запрошен клиентом в сообщение DHCPDISCOVER. Главным образом такое поведение DHCP-сервера связано с тем, какие флаги были получены им от клиента.
Обратите внимание, что в сообщение DHCPOFFER сервер еще не использует предлагаемый IP-адрес в поле Client IP Address, там еще находятся унылые нули. В поле Your IP Address сервер предлагает клиенту тот IP-адрес, который он у него запросил, естественно, перед тем как его предложить, сервер убедился в том, что этот адрес свободен. Как видим, сообщение DHCPOFFER по своему содержимому не сильно отличается от DHCPDISCOVER, теперь давайте посмотрим на опции, которые сервер предложил клиенту.
9.3.6 DHCP опции в сообщение DHCPOFFER
Во-первых, опции в сообщение DHCPOFFER, как и в любых других сообщениях, начинаются с Magic Cookie, а заканчиваются 255 опцией. Во-вторых, сервер не знал всех опций, которые у него попросил клиент, поэтому выдал то, что смог. После Magic Cookie сервер сообщает, что этот пакет несете в себе сообщение DHCPOFFER. Следующим шагом он сообщает клиенту свой идентификатор. А вот опция с кодом 51 несет в себе очень важную информацию о времени аренды IP-адреса, об этом времени у нас будет отдельный разговор.
Еще из полезного сервер предложил в качестве опций клиенту IP-адрес шлюза по умолчанию, маску подсети и адрес DNS-сервера.
9.3.5 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса?
Сервер не обязан резервировать за клиентом IP-адрес, который он предлагает в DHCPOFFER, обычно резервирование происходит сразу после или во время отправки сообщения DHCPACK. Но это будет после, сейчас клиент должен сообщить серверу о том, что он согласен на получение предложенного IP-адреса и опций, а также сообщить серверу еще немного полезной информации.
ПРИМЕЧАНИЕ: здесь мы пропускаем все проверки на занятость/свободность IP-адреса, это мы обсудили при прошлом разговоре и сейчас считаем, что они есть и в результате этих проверок IP-адрес свободен.
Давайте посмотрим, как выглядит сообщение DHCPREQUEST в дампе Wireshark.
9.3.7 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса
Сразу бросается в глаза то, что DHCPREQUEST отправляется не адресно, а широковещательно, тут дело в том, что клиент должен сообщить всем серверам о том, какой адрес он хочет получить и с каким сервером он хочет продолжать взаимодействие. Все поля сверху, за исключением поля Message Type, имеют точно такие же значения, как и в сообщение DHCPDISCOVER, а вот поля опций изменились, давайте на них и посмотрим.
Содержание
Описание
Команда осуществляет управление работой клиента DHCP. Клиент DHCP предназначен для автоматического получения от DHCP-сервера параметров для одного или нескольких сетевых интерфейсов устройства. К параметрам относятся IP-адрес, маска сети, шлюз по умолчанию и прочие.
Синтаксис:
Параметры
Опции
Опция устанавливает список IP-адресов серверов DHCP, от которых клиенту разрешено принимать параметры.
-a (none|default|NUMBER)
Опция устанавливает идентификатор класса клиента DHCP.
Имя сетевого интерфейса
Команды
Примеры
Команда устанавливает количество ARP-запросов равным 5.
Расшифровка системного журнала беспроводного роутера
Системный журнал/System Log
В этой теме мы опишем стандартные записи в системном журнале.
Далее мы расскажем, что означают те или иные записи в системном журнале.
2. Старт устройства
Запись системного журнала начинается со строки System started, присутствует информация о том включен ли сервер DHSP на роутере и с пометкой SECURITY указаны дополнительные параметры защиты которые запустились. Те сервисы, которые отключены в системном журнале показаны с пометкой disabled.
#################################################################### 1st day 00:00:07 OTHER INFO System started 1st day 00:00:17 DHCP NOTICE DHCP server started 1st day 00:00:17 SECURITY INFO PPTP Passthrough enabled 1st day 00:00:17 SECURITY INFO L2TP Passthrough enabled 1st day 00:00:17 SECURITY INFO IPSEC Passthrough enabled 1st day 00:00:17 SECURITY INFO FTP ALG enabled 1st day 00:00:17 SECURITY INFO TFTP ALG enabled 1st day 00:00:17 SECURITY INFO H323 ALG enabled 1st day 00:00:17 SECURITY INFO RTSP ALG enabled
Не всегда в системном журнале хранится вся эта информация. Память в устройстве не бесконечна и поэтому роутер записывает только те последние стройки что уместились. Например, если роутер уже довольно давно работает, этих записей скорее всего не будет.
DHCPS:Recv DISCOVER from 68:9C:5E:28:C8:E5
Устройство с MAC адресом 68:9C:5E:28:C8:E5 в первый раз запрашивает IP адрес
DHCPS:Send OFFER with ip 192.168.0.100
Роутер предлагает этому устройству свободный IP адрес
DHCPS:Recv REQUEST from 68:9C:5E:28:C8:E5
Устройство соглашается на предложение
DHCPS:Send ACK to 192.168.0.100
Завершающий этап подтверждающий, что указанный IP адрес выдан.
4. DHCP Client. Получение IP адреса самим роутером от локальной сети провайдера
Sep 20 12:27:39 DHCP INFO DHCPC Send DISCOVER with request ip 0 and unicast flag 0 Sep 20 12:27:39 DHCP INFO DHCPC Recv OFFER from server d91efaa7 with ip a021e3a Sep 20 12:27:39 DHCP INFO DHCPC Send REQUEST to server d91efaa7 with request ip a021e3a Sep 20 12:27:40 DHCP INFO DHCPC Recv ACK from server d91efaa7 with ip a021e3a lease time 791901 Sep 20 12:27:40 DHCP INFO DHCPC:GET ip:a021e3a mask:fffffe00 gateway:a021e01 dns1:d91efaa7 dns2:d91efaa8 Sep 20 12:27:40 DHCP NOTICE Dynamic IP(DHCP Client) obtained an IP successfully
Здесь все происходит по стандарту. Все одинаково по сравнению с выдачей IP адресов самим роутером. Только теперь роутер является клиентом DHCP сервера провайдера.
Успешное подключение
Jul 14 10:41:32 PPP NOTICE Standard authentication. Jul 14 10:41:33 PPP INFO sent [PADI Host-Uniq(0x00000202)] Jul 14 10:41:33 PPP INFO rcvd [PADO AC-Name:asr2-ats66 AC-MAC:b4:14:89:04:11:00] Jul 14 10:41:33 PPP INFO sent [PADR Host-Uniq(0x00000202)] Jul 14 10:41:33 PPP INFO rcvd [PADS sess-id(30835)] Jul 14 10:41:33 PPP INFO sent [LCP Req mru=1480 magic=0x7dac6e97] Jul 14 10:41:33 PPP INFO rcvd [LCP Req mru=1492 auth=pap magic=0x6df87d08] Jul 14 10:41:33 PPP INFO sent [LCP Ack mru=1492 auth=pap magic=0x6df87d08] Jul 14 10:41:33 PPP INFO rcvd [LCP Nak mru=1492] Jul 14 10:41:33 PPP INFO sent [LCP Req mru=1492 magic=0x7dac6e97] Jul 14 10:41:33 PPP INFO rcvd [LCP Ack mru=1492 magic=0x7dac6e97] Jul 14 10:41:33 PPP INFO sent [PAP AuthReq user=»ep2play_rnd15413_ll01″ password=(hidden)] Jul 14 10:41:33 PPP INFO sent [LCP code=0xc] Jul 14 10:41:33 PPP INFO rcvd [PAP AuthAck «»] Jul 14 10:41:33 PPP INFO sent [IPCP Req addr=0.0.0.0 dns1=0.0.0.0 dns3=0.0.0.0] Jul 14 10:41:33 PPP INFO rcvd [IPCP Req addr=80.80.111.72] Jul 14 10:41:33 PPP INFO sent [IPCP Ack addr=80.80.111.72] Jul 14 10:41:33 PPP INFO rcvd [IPCP Nak addr=77.66.230.224 dns1=80.80.111.250 dns3=80.80.111.244] Jul 14 10:41:33 PPP INFO sent [IPCP Req addr=77.66.230.224 dns1=80.80.111.250 dns3=80.80.111.244] Jul 14 10:41:33 PPP INFO rcvd [IPCP Ack addr=77.66.230.224 dns1=80.80.111.250 dns3=80.80.111.244] Jul 14 10:41:34 PPP NOTICE PPPoE connected
Стандартная установка соединения PPPoE начинается с
Рассмотрим проблемы, из-за которых роутер может не соединяться с провайдером.
1st day 00:01:16 PPP NOTICE Standard authentication. 1st day 00:01:16 PPP INFO send_phase 2112 pppd_phase = 0x2 1st day 00:01:16 PPP INFO In pppd the httpd-id is 613, set link phase is 0x2 1st day 00:01:16 PPP INFO sent [PADI Host-Uniq(0x00000282)] 1st day 00:01:21 PPP INFO sent [PADI Host-Uniq(0x00000282)] 1st day 00:01:31 PPP INFO sent [PADI Host-Uniq(0x00000282)] 1st day 00:01:51 PPP INFO send_phase 2112 pppd_phase = 0x66 1st day 00:01:51 PPP INFO In pppd the httpd-id is 613, set link phase is 0x66 1st day 00:01:51 PPP WARNING PPPoE hard line is disconnected, please check the line 1st day 00:01:51 PPP ERROR Timeout waiting for PADO packets
В этом примере видно, что роутер пытается соединиться, отправляет PADI пакеты, но не видит ответных пакетов от сервера провайдера:
1st day 00:01:16 PPP INFO sent [PADI Host-Uniq(0x00000282)]
1st day 00:01:21 PPP INFO sent [PADI Host-Uniq(0x00000282)]
1st day 00:01:31 PPP INFO sent [PADI Host-Uniq(0x00000282)]
Три попытки начать установление соединения
1st day 00:01:51 PPP ERROR Timeout waiting for PADO packets
Не дождался
Успешное подключение.
Oct 15 01:57:29 PPP INFO pppol2tp kernel fd:11 Oct 15 01:57:31 PPP INFO sent SCCRQ Oct 15 01:57:31 PPP INFO rcvd Start-Control-Connection-Reply Oct 15 01:57:31 PPP INFO sent SCCCN Oct 15 01:57:31 PPP INFO sent ICRQ Oct 15 01:57:31 PPP INFO rcvd Incoming-Call-Reply Oct 15 01:57:31 PPP INFO sent ICCN Oct 15 01:57:31 PPP INFO pppoxl2tp fd2:12 Oct 15 01:57:31 PPP INFO pppol2tp session fd:13 Oct 15 01:57:31 PPP INFO sent [LCP Req mru=1460 magic=0xca05cec0] Oct 15 01:57:31 PPP INFO rcvd [LCP Ack mru=1460 magic=0xca05cec0] Oct 15 01:57:34 PPP INFO rcvd [LCP Req mru=1420 magic=0xca5054f9 auth=chap-MD5] Oct 15 01:57:34 PPP INFO sent [LCP Ack mru=1420 magic=0xca5054f9 auth=chap-MD5] Oct 15 01:57:34 PPP INFO rcvd [CHAP Challenge (717540970ab21bc8ed3b06a5c53e2f415c1debd540622ae8f935897), name = «xyz»] Oct 15 01:57:34 PPP INFO sent [CHAP Response (2e9ae43bf0a257bacd6a5116946), name = «l2tp»] Oct 15 01:57:34 PPP INFO rcvd [CHAP Success «»] Oct 15 01:57:34 PPP INFO sent [IPCP Req addr=0.0.0.0 dns1=0.0.0.0 dns3=0.0.0.0] Oct 15 01:57:34 PPP INFO rcvd [IPCP Req addr=172.18.0.73 dns1=0.0.0.0 dns3=0.0.0.0 ms-wins=0.0.0.0 ms-wins=0.0.0.0] Oct 15 01:57:34 PPP INFO sent [IPCP Rej dns1=0.0.0.0 dns3=0.0.0.0 ms-wins=0.0.0.0 ms-wins=0.0.0.0] Oct 15 01:57:34 PPP INFO rcvd [IPCP Req addr=172.18.0.73] Oct 15 01:57:34 PPP INFO sent [IPCP Ack addr=172.18.0.73] Oct 15 01:57:34 PPP INFO rcvd [IPCP Nak addr=172.16.1.1 dns1=192.168.0.1] Oct 15 01:57:34 PPP INFO sent [IPCP Req addr=172.16.1.1 dns1=192.168.0.1 dns3=0.0.0.0] Oct 15 01:57:34 PPP INFO rcvd [IPCP Ack addr=172.16.1.1 dns1=192.168.0.1 dns3=0.0.0.0] Oct 15 01:57:34 PPP INFO ipcpup : ipcp_wantoptions[0].default_route = 1^M Oct 15 01:57:34 PPP INFO delete old gateway^M Oct 15 01:57:37 PPP NOTICE L2TP connected
Oct 15 01:57:29 PPP INFO pppol2tp kernel fd:11
Запуск службы L2TP
Oct 15 01:57:31 PPP INFO sent SCCRQ
Роутер посылает серверу пакет Start-Control-Connection-Request для начала установления управляющего соединения
Oct 15 01:57:31 PPP INFO rcvd Start-Control-Connection-Reply
Ответ сервера о том, что он соглашается на продолжение установления соединения
Oct 15 01:57:31 PPP INFO sent SCCCN
Подтверждение установления управляющего соединения
Oct 15 01:57:31 PPP INFO sent ICRQ
Роутер отправил пакет Incoming-Call-Request
Oct 15 01:57:31 PPP INFO rcvd Incoming-Call-Reply
Сервер отвечает пакетом Incoming-Call-Reply
Oct 15 01:57:31 PPP INFO sent ICCN
Окончательное установление управляющего соединения
Oct 15 01:57:31 PPP INFO pppoxl2tp fd2:12
Oct 15 01:57:31 PPP INFO pppol2tp session fd:13
Переход службы в режим установления туннеля
Oct 15 01:57:31 PPP INFO sent [LCP Req mru=1460 magic=0xca05cec0]
Oct 15 01:57:31 PPP INFO rcvd [LCP Ack mru=1460 magic=0xca05cec0]
Oct 15 01:57:34 PPP INFO rcvd [LCP Req mru=1420 magic=0xca5054f9 auth=chap-MD5]
Oct 15 01:57:34 PPP INFO sent [LCP Ack mru=1420 magic=0xca5054f9 auth=chap-MD5]
Роутер и сервер договариваются о используемых параметрах аутентификации
Oct 15 01:57:34 PPP INFO rcvd [CHAP Challenge (717540970ab21bc8ed3b06a5c53e2f415c1debd540622ae8f935897), name = «xyz»]
Сервер просит роутер прислать данные для аутентификации
Oct 15 01:57:34 PPP INFO sent [CHAP Response (2e9ae43bf0a257bacd6a5116946), name = «l2tp»]
Роутер отправляет имя, пароль передается зашифрованным
Oct 15 01:57:34 PPP INFO rcvd [CHAP Success «»]
Сервер подтверждает правильность данных и устанавливает туннель
Oct 15 01:57:34 PPP INFO sent [IPCP Req addr=0.0.0.0 dns1=0.0.0.0 dns3=0.0.0.0]
Oct 15 01:57:34 PPP INFO rcvd [IPCP Req addr=172.18.0.73 dns1=0.0.0.0 dns3=0.0.0.0 ms-wins=0.0.0.0 ms-wins=0.0.0.0]
Oct 15 01:57:34 PPP INFO sent [IPCP Rej dns1=0.0.0.0 dns3=0.0.0.0 ms-wins=0.0.0.0 ms-wins=0.0.0.0]
Oct 15 01:57:34 PPP INFO rcvd [IPCP Req addr=172.18.0.73]
Oct 15 01:57:34 PPP INFO sent [IPCP Ack addr=172.18.0.73]
Oct 15 01:57:34 PPP INFO rcvd [IPCP Nak addr=172.16.1.1 dns1=192.168.0.1]
Oct 15 01:57:34 PPP INFO sent [IPCP Req addr=172.16.1.1 dns1=192.168.0.1 dns3=0.0.0.0]
Oct 15 01:57:34 PPP INFO rcvd [IPCP Ack addr=172.16.1.1 dns1=192.168.0.1 dns3=0.0.0.0]
Получение IP-адреса в туннельном соединении
Oct 15 01:57:34 PPP INFO ipcpup : ipcp_wantoptions[0].default_route = 1^M
Oct 15 01:57:34 PPP INFO delete old gateway^M
Изменяет шлюз на туннельное соединение, весь траффик идет в него, а не в локальную сеть провайдера
Oct 15 01:57:37 PPP NOTICE L2TP connected
Туннель L2TP установлен
Успешное подключение
Oct 15 02:16:28 PPP INFO sent Start-Control-Connection-Request Oct 15 02:16:28 PPP INFO rcvd Start-Control-Connection-Reply Oct 15 02:16:29 PPP INFO sent Outgoing-Call-Request Oct 15 02:16:29 PPP INFO rcvd Outgoing-Call-Reply Oct 15 02:16:30 PPP INFO sent [LCP Req mru=1420 magic=0x2dc659aa] Oct 15 02:16:30 PPP INFO rcvd [LCP Req mru=1420 magic=0xaba62526 auth=chap-MS-v2] Oct 15 02:16:30 PPP INFO sent [LCP Ack mru=1420 magic=0xaba62526 auth=chap-MS-v2] Oct 15 02:16:30 PPP INFO rcvd [LCP Ack mru=1420 magic=0x2dc659aa] Oct 15 02:16:30 PPP INFO rcvd [CHAP Challenge (fd41b09dc1e1eac829c7ed20333282e2), name = «xyz»] Oct 15 02:16:30 PPP INFO sent [CHAP Response (0e0afe2f8810f12fc908fdf700f35f380089c42ece82ae6f3652946fcd95c988b7b90bf71a00), name = «pptp»] Oct 15 02:16:30 PPP INFO rcvd [CHAP Success «S=C31AAA8C15537D11399314455C4088654FAF8446»] Oct 15 02:16:30 PPP INFO sent [IPCP Req addr=0.0.0.0 dns1=0.0.0.0 dns3=0.0.0.0] Oct 15 02:16:30 PPP INFO rcvd [IPCP Req addr=172.18.0.73 dns1=0.0.0.0 dns3=0.0.0.0 ms-wins=0.0.0.0 ms-wins=0.0.0.0] Oct 15 02:16:30 PPP INFO sent [IPCP Rej dns1=0.0.0.0 dns3=0.0.0.0 ms-wins=0.0.0.0 ms-wins=0.0.0.0] Oct 15 02:16:30 PPP INFO rcvd [IPCP Req addr=172.18.0.73] Oct 15 02:16:30 PPP INFO sent [IPCP Ack addr=172.18.0.73] Oct 15 02:16:30 PPP INFO rcvd [IPCP Nak addr=172.16.1.1 dns1=192.168.0.1] Oct 15 02:16:30 PPP INFO sent [IPCP Req addr=172.16.1.1 dns1=192.168.0.1 dns3=0.0.0.0] Oct 15 02:16:30 PPP INFO rcvd [IPCP Ack addr=172.16.1.1 dns1=192.168.0.1 dns3=0.0.0.0] Oct 15 02:16:30 PPP INFO ipcpup : ipcp_wantoptions[0].default_route = 1^M Oct 15 02:16:30 PPP INFO delete old gateway^M Oct 15 02:16:34 PPP NOTICE PPTP connected