Emilsson Magazine. Про все, крім політики

Це - друга стаття з серії "Швидкий Інтернет ..."
Ну що ж, тепер нарешті, настав час дізнатися деякі подробиці ініціалізації Інтернет-з'єднання. На деталі ініціалізації явно впливають налаштування Вашого підключення до мережі Інтернет і LAN (нагадаю, що тут розглядається з'єднання з Інтернет за технологією FTTB по PPPoE і без використання маршрутизатора на клієнтській стороні), але їх ми розглянемо наступного разу. Тому всі подробиці встановлення з'єднання будуть розглянуті з точки зору моїх поточних мережевих налаштувань, оптимальних на даний момент (що за настройки - докладніше знову-таки в наступний раз). Ну а ось, власне, і вони самі!
Для з'ясування деталей я скористався старим добрим EtherPeek NX від Wildpackets. Розробка нових версій ЦІЙ програми була припинена кілька років тому; Зараз залишився тільки OmniPeek (остання версія - 6.6 - вийшла майже місяць тому), який поєднує в собі можливості всіх раніше випускалися продуктів, тобто, працює практично з усіма видами мереж і протоколів, в т.ч., BitTorrent (адже " omni "означає" багато "). EtherPeek ж, підтримує тільки Ethernet; втім, і цього мені було достатньо: по крайней мере, його інтерфейс зручніше і не такий перевантажений, як у OmniPeek. Однак, здається я трохи відволікся; перейдемо до справи, і проілюструємо картинками;)
Для ініціалізації доступу до Інтернету використовуються аж цілих кілька різних протоколів :)
Перший з них - "PPPoE Discovery". Він необхідний для встановлення факту можливості використання PPP в мережі Ethernet. Як це працює:
1) Спочатку мережевий адаптер посилає широкомовний запит "Active Discovery Initiation" - авось, і відгукнеться хтось. Якщо ніхто не відгукується, ймовірно, цей запит може надсилатися нескінченно, або обмежене число разів з повідомленням про помилку - залежить від реалізації:

Тут і далі "Service Name" - ім'я служби з налаштування Інтернет-з'єднання (у мене не використовується);
"Host Unique" - унікальний ідентифікатор хоста, складається з двох 32-бітних полів, що створюються за особливими правилами (грає роль число спроб з'єднання, і порядок пакета в черзі ініціалізації); "Extra" - 24 байта, що мають нульові значення; "FCS" - контрольна сума. У цьому пакеті також "Source" - мій MAC-адресу, "Destination" - в даному випадку широкомовний, може бути MAC'ом "дружнього" AC ISP; крім того, мій MAC може виступати в ролі "Destination", а MAC AC - в ролі "Source"; бувають і інші варіанти (в залежності від пакета).
2) І ось, - о диво - відповідь отримана. Правда, це ще не "рукостискання", а всього лише "пропозицію дружби" - запит "Active Discovery Offer" від "дружнього" концентратора доступу (надалі просто AC) ISP. AC повертає мої "Service Name" і "Host Unique":

Тут "Source" - MAC-адресу відгукнувся AC; "Access Concentrator Name" - його ім'я; "Access Concentrator Cookie" - повертається cookie (він буде використаний в подальших операціях).
3) Мережевий адаптер відгукується на пропозицію "дружби" - він посилає у відповідь запит "Active Discovery Request", використовуючи отриманий cookie AC:

Так само мережевий адаптер інкрементує старші 32 біта "Host Unique" для свого запиту.
4) AC приймає це відповідь пропозицію і надсилає запит-підтвердження сесії PPPoE - "Active Discovery Session-confirmation" зі своїм cookie і повертає відправлений адаптером "Host Unique":

Як і на кроці 3), ніяких додаткових байт не надсилається - параметр "Extra.Number_of_bytes" дорівнює нулю.
На цьому обмін даними по протоколу "PPPoE Discovery" завершено - сесія PPPoE успішно ініційована.
Зв'язок встановлена, але її ще потрібно правильно налаштувати і утримувати. Тому далі йде другий етап - обмін по протоколу "Link Control", або, коротко, LCP (до речі, існує така настройка "Включити розширення LCP"; і вони повинні бути включені). Як це працює:
1) Мережевий адаптер, діючи тепер в рамках сесії PPPoE, посилає по LCP пакет, що містить деякі початкові налаштування для цього сеансу зв'язку ( "Configure Request"):

Тут запитується "Maximum Receive Unit" (MRU) - те саме, що і MTU - максимальний розмір нефрагментовані блоку даних (не включаючи заголовки). Для Ethernet він завжди дорівнює 1480 байт, і ніякі спроби його зміни за допомогою спеціальних утиліт і / або редагування реєстру до успіху не приводять - перевірено особисто; "Magic Number" - зміст той же, що і для cookie на етапі "PPPoE Discovery", тобто, це своєрідний тег операції; "Callback" - дії віддаленого сервера після встановлення зв'язку, зазвичай це "передзвонити на модем" (після встановлення з'єднання, зв'язок розривається, а потім віддалений сервер знову її ініціює), тобто ця настройка використовується тільки для Dial-up - з'єднань, і ніколи - для PPPoE {ця опція, мабуть, залишена для сумісності, і буде відкинута у відповідному повідомленні}; "Stac Electronics LZS" - ця опція не має відношення до параметру "Використовувати програмне стиснення даних"; після відомих розбіжностей між Microsoft і, власне, Stac Electronics, їх метод стиснення не використовується при передачі даних (а саме за це і відповідає дана опція); "Multilink Endpoint Discriminator" - запит узгодження багатоканального підключення для одноканальних; підтримується однойменної налаштуванням Інтернет-з'єднання, і навіть підтримується AC, але в реальності такі пакети не формуються (по крайней мере, для мого з'єднання це так). Крім того, в залежності від параметрів мережі, можуть передаватися і інші опції.
2) AC посилає зустрічний запит зі своїми настройками:

AC повідомляє про своє бажаному MRU (це завжди 1492 байта), "Authentication Protocol" - підтримуваному протоколі безпеки (у мого ISP це "Password Authentication Protocol" (PAP), тобто, небезпечний пароль, який передається відкритим текстом; Ваш ISP може використовувати і інші методи, наприклад, практикується часто MS-CHAP), і передає СВІЙ "Magic Number". Додаткові "Extra" байти містять нулі (ймовірно, використовуються для вирівнювання або заповнення).
3) Після цього AC перевіряє витребувані опції, і відкидає непотрібні, або не підтримуються ( "Configure Reject"):

В даному випадку, як я і говорив, відкинутими виявилися "Callback" і "Stac Electronics LZS". "Extra" байти знову содежат тільки нулі.
4) Після цього мережевий адаптер погоджує деякі опції від AC ( "Configure Ack"):

В даному випадку це MRU, "Authentication Protocol" (пунктів призначення в Інтернеті повинен бути вказаний підтримуваний Вашим ISP протокол (у мене це PAP), інакше буде повернуто помилку, і сесія PPPoE завершиться), і, в качесте підтвердження, "Magic Number" AC .
5) І, з урахуванням коректувань, адаптер знову пересилає свій запит підтримуваних налаштувань:

Як видно, від початкового запиту залишилися тільки MRU, "Magic Number" (той же) і "Multilink Endpoint Discriminator". Цей запит все ще вимагає підтвердження.
6) Цього разу AC успішно приймає всі передані адаптером настройки:

Так, багатоканальне узгодження підтримується (хоча і формально в моєму випадку). Але це ще не все.
7) Тепер, коли параметри мережевого з'єднання встановлено, адаптер відправляє AC перший запит на ідентифікацію ( "Identification") {цей запит відноситься до розширень LCP, згідно з документом RFC 1570; він доступний по активації настройки Інтернет-з'єднання "Включити розширення LCP"}:

І в першому випадку параметр "Data" (виділено на малюнку) являє собою ASCII-ім'я клієнтського вбудованого сервера віддаленого доступу: в даному прикладі це "MSRASV5.10", тобто MS RAS v 5.1 для Windows XP; для інших ОС тут може бути інше значення (наприклад, "MSRASV5.20" для Windows 2003 Server).
8) Після цього відправляється другий запит на ідентифікацію:

У другому випадку в параметрі "Data" передається ASCII-рядок, що містить ім'я мережеве комп'ютера: в даному прикладі це "MSRAS-0-VKR-01", де "VKR-01" - мережеве ім'я мого комп'ютера. Зауважу, що саме виконання команди LCP "Identification" залежить від розробника, тому всі наведені тут значення, і правила, за якими вони формуються, специфічні для ПО Microsoft.
На цьому і завершується обмін керуючими командами по протоколу LCP.
Але процедура ідентифікації ще не закінчена. Для її успішного проходження необхідний вже третій протокол, який буде використаний - вже згадуваний "Password Autentication", або просто PAP. Як я вже писав раніше, вибір протоколу для мережевої ідентифікації залежить від Вашого ISP, і, оскільки мій ISP використовує саме PAP, то розглянутий буде саме він. Як це працює:
1) У разі PAP все дуже просто: адаптер посилає запит "Authenticate-Request", що містить ім'я користувача і незашифрований (відкритим текстом) пароль:

Як Ви вже, напевно, здогадалися, всі дані про мого профілю Інтернету були старанно викреслити> Ім'я користувача і пароль передаються відкритим текстом в полях "Peer-Id" і "Passwd" відповідно. Втім, передати щось можна що завгодно, а ось чи спрацює?
2) "AC завдає удару у відповідь". Введені дані перевіряються, і AC відсилає адаптера запит "Authenticate-Ack":

У разі успіху повертаються дані, як на малюнку зверху; якщо ж, наприклад, пароль виявився невірним, в поле "Message" повертається повідомлення "Authentication failed.".
Як бачите, в разі протоколу PAP все дуже просто. Весь обмін даними складається тільки з цих двох повідомлень.
Отже, зв'язок мережевого адаптера з концентратором доступу встановлена ​​остаточно. Але передавати між ними які-небудь корисні дані (корисні з точки зору звичайного користувача ПК) поки ще неможливо. Для цього потрібно змусити їх розмовляти один з одним на мові TCP / IP. Для цього нам знадобиться ще один, четвертий, протокол: "PPP IP Control Protocol" (IPCP). Як це працює:
1) Спочатку AC посилає адаптера запит, який містить його локальний IP-адреса ( "Configure Request"):

AC мого ISP пропонує мені, як варіант, свій IP, рівний 10.11.0.1 (це локальний IP, що існує тільки в рамках LAN).
2) У відповідь мережевий адаптер також посилає конфігураційний запит необхідних IP адрес:

Замість реальних адрес скрізь стоять нулі: це означає, що все поля повинні бути коректно заповнені AC, або відкинуті, як неприпустимі або Неподдерживается. В даному випадку адаптер запитує свій валідний IP-адреса, а також адреси серверів імен NetBIOS. Крім цих, за окремим запитом та інші IP-адреси, і в першу чергу - IP-адреси серверів DNS. Але так як ці адреси мені були відомі, то я ввів їх у відповідні поля налаштувань Інтернет-з'єднання, і необхідність в їх визначенні кожен раз при ініціалізації Інтернет-з'єднання відпала (а це трохи економить час ініціалізації). Тому в даному запиті IP-адреси серверів DNS не фігурують.
3) IP-адреса AC (10.11.0.1), переданий адаптера, цілком влаштовує останнього, тому цю адресу підтверджується ( "Configure Ack"):

Поле "Extra", як зазвичай, нічого крім нулів не містить.
4) А ось деякі із запропонованих адаптером параметрів, можуть не влаштовувати AC, і він їх негайно відкидає ( "Configure Reject"):

І в даному випадку це IP-адреси серверів імен NetBIOS (мабуть, вони не підтримуються ISP).
5) Зрозуміло, адаптер нічого не залишається, як підкоригувати свій запит і відправити його заново:

Після коригування залишається тільки запит на отримання IP-адреси для мережевого адаптера.
6) 0.0.0.0 - в общем-то валідність, але неприйнятне в даній ситуації значення (можливі кращі варіанти :)), про що AC негайно повідомляє адаптер за допомогою запиту "Configure Nak":

Як варіант, AC пропонує для адаптера в якості IP-адреси значення 46.250.66.131 - динамічний IP-адресу.
7) Зрозуміло, цей варіант влаштовує адаптер, і він з радістю відправляє запит на підтвердження:

Замість нулів тепер тут динамічний IP 46.250.66.131
8) Тепер AC цей IP-адреса з легкістю може підтвердити (оскільки сам його і видав спочатку):

На цьому обмін даними по протоколу IPCP завершений. Тепер передача даних по таким протоколам, як TCP і UDP стає можливою. Цією передачі даних, звичайно передуватимуть такі речі, як побудова маршрутів і дозвіл імен, але це вже, як то кажуть, зовсім інша історія, яка не має безпосереднього відношення до Інтернет-з'єднанню і його налаштувань.
PS
Як я вже написав, тут були опущені деякі моменти, цілком або частково залежать від певних налаштувань підключення до мережі Інтернет. Вони будуть розглянуті в наступний раз.

Сподобалася ця і / або інші мої статті?

Тоді не соромтеся висловити свою думку, залишивши тут свої коментарі. Ви також можете допомогти розвитку цього журналу, ставши його постійним читачем. А якщо ж ця стаття Вам ну дуже-дуже сподобалася, то ви можете віддячити їй автора наступними способами <щиро сподіваюся, що ці кнопки все-таки працюють 8)))>

Експеримент №1: пузомерка Втім, передати щось можна що завгодно, а ось чи спрацює?
Сподобалася ця і / або інші мої статті?