[Jula0071]

На сетевом уровне в заголовке пакета данных идут »

PPP вообще и PPPoE в частности работают на канальном уровне...

[El Scorpio]

На сетевом уровне в заголовке пакета данных идут 1 Адрес отправителя 2 Адрес получателя »

PPPoE - протокол не "сетевого" уровня, а канального.
Адресация протокола PPPoE производится по MAC-адресам устройств отправителя и получателя в заголовках пакетов PPP, по-этому работает и без назначения внешнему порту маршрутизатора отдельного IP-адреса.

MAC адреса сейчас практически не используются. Для доступа к серверу провайдера (моего) используется только User Name и Password. »

Всё правильно: "MAC адреса сейчас практически не используются" для идентификации абонента в момент установки соединения.
Что позволяет абонентам нормальных провайдеров без проблем использовать любые оконечные устройства, в которых для установки соединения достаточно указать логин и пароль.
Самые нормальные провайдеры заодно используют проверку абонентской линии, чтобы исключить использование украденного пароля сторонними лицами

[charon]

Ну и в целом: Википедия - энциклопедия заблуждений, её пишут энтузиасты, а не профессионалы. »

Не могу не согласиться.

[charon]

PPPoE - протокол не "сетевого" уровня, а канального. »

Согласен. С этими протоколами полный ппц - в голове уже каша. Каждый пишет что хочет. В одном месте одно, в другом другое. Кому верить?

Адресация протокола PPPoE производится по MAC-адресам устройств отправителя и получателя в заголовках пакетов PPP »

Я думал что MAC адреса вообще не используются. Клиент отправляет широкополосный запрос, коммутатор провайдера откликается и назначает локальный IP клиенту, далее на основе локального IP клиента сервер назначает клиенту внешний IP адрес. Как-то так.

В логах роутера MAC адрес нигде не упоминается. Есть только не очень понятный запрос роутера:
line0, canal0, devch0

Далее идет Open LCP, Open ICMP и т.д.

Уточню логи выложу.

[El Scorpio]

Я думал что MAC адреса вообще не используются. Клиент отправляет широкополосный запрос, коммутатор провайдера откликается и назначает локальный IP клиенту, далее на основе локального IP клиента сервер назначает клиенту внешний IP адрес. Как-то так. »

МАК-адреса устройств используются всегда.
Клиент отправляет широкополосный запрос (на MAC-адрес FFFFFFFFFFFF), коммутатор провайдера посылает на MAC-адрес клиента ответ, из которого клиент узнаёт MAC-адрес коммутатора провайдера для дальнейшего обмена информацией.

[bredych]

МАК-адреса устройств используются всегда. »

только они имеют значение исключительно в одном сегмнте сети, до первой активной железяки.
кто когда-либо пакеты читал, помнит, что символы с 1 по 6 - мак получателя, 7-12 - мак отправителя, потом уже капсулируется и ИП и всё остальное..
Но поскольку вероятнее всего сеть сегментированная, то мак бесполезен - это будет мак ближайшей в пути к девайсу активной железяки. Напр, первый же свитч по пути от компа, с которого проверяется.

[El Scorpio]

только они имеют значение исключительно в одном сегмнте сети, до первой активной железяки. »

Вы хотя бы в суть беседы вникали.

Но поскольку вероятнее всего сеть сегментированная, то мак бесполезен - это будет мак ближайшей в пути к девайсу активной железяки. Напр, первый же свитч по пути от компа, с которого проверяется.»

Откуда вы этот бред взяли?
При передаче пакетов в пределах одной подсети IP-адресации MAC-адреса отправителя и получателя в пакете не меняются, сколько бы коммутаторов не прошёл этот пакет.
Даже если сам пакет через точку доступа WiFi переходит из проводного сегмента ЛВС в беспроводной, адреса в нём не меняются.

Сомневаетесь? Напишите команду arp IP-адрес, и вы увидете MAC-адрес не "первого же свича", а указанного компьютера.

[Busla]

Даже если сам пакет через точку доступа WiFi переходит из проводного сегмента ЛВС в беспроводной, адреса в нём не меняются. »

не совсем так - всё же WiFi и Ethernet устроены по-разному, поэтому пакет не переходит, а преобразуется в другой формат, а MAC хоть и сохраняется, но роль у него не та

С этими протоколами полный ппц - в голове уже каша. Каждый пишет что хочет. В одном месте одно, в другом другое. Кому верить? »

Во-первых, читайте первоисточники, а не популистские статейки. Тот же OSI/ISO - это не диаграмма из семи прямоугольничков, а толстая брошюра, формалировки в которой "вылизывала" толпа умнейших людей на протяжении нескольких лет - воспринимать их надо буквально и однозначно. Подавляющее же число литературы/курсов основана не на стандартах как таковых, а на реализациях в ОС и железе.
Во-вторых, интернет построен и функционирует на безуровневых принципах - RFC 3439 - Internet Architectural Guidelines. Section 3. Layering Considered Harmful.
В-третьих, смысл vpn и подобных технологий, чтобы нарушать привычный ход обработки данных. Как данные передаются и что получается на выходе - две большие разницы.

[charon]

читайте первоисточники... »

Тяжело их найти (первоисточники), SEO им не надо, к сожалению. В поисковиках на первых местах "популистские статейки". К сожалению поисковики стали выдавать много мусора. Язык запросов (на яндексе) упрощен дальше некуда и работает совсем не так как описан на сайте. Нужен поисковик по поиску :-)
P.S. Да и на английском бегло не читаю.