Почему сервер не может получить MAC-адрес клиента, например IP-адрес клиента?

Фактически, MAC-адрес, хранящийся в пакете, изменяется на каждом этапе прохождения пакета.

MAC - это сокращение от Media Access Control, при этом носитель относится к локальному носителю связи. В то время как IP-адреса источника и назначения остаются неизменными на протяжении всего пути (и используются для принятия решений о маршрутизации на большие расстояния), MAC-адреса источника и назначения просто указывают следующий переход.

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

Возможно, вы захотите взглянуть на модель уровня OSI и инкапсуляцию .

У вас есть обратная связь между стеком IP и физическим стеком. MAC-адрес находится в той части, которая является оболочкой для IP-информации, а не наоборот. Поэтому, когда я отправляю что-то со своего компьютера, скажем, на ваш, физический сегмент в моей локальной сети (в данном случае Ethernet) оборачивается вокруг IP-данных и включает мой MAC. Затем маршрутизатор извлекает IP-информацию и передает ее вперед и назад (в данном случае снова через Ethernet) моему DSL-модему, используя свой собственный MAC-адрес в процессе. Модем DSL разворачивает IP-данные и отправляет их по телефонной линии, используя любой протокол, который он использует (не знаю и не волнует в этот момент), чтобы ... ну, вы поняли. Каждый переход по физическому каналу обертывает и разворачивает IP-информацию, используя любую дополнительную информацию, которую задействованный физический уровень подключает для локальной передачи.

В IPv6 можно фактически получить MAC-адрес компьютера из IPv6-адреса, если он закодирован в 64-битном формате адрес хоста.

См. Также Как избежать раскрытия моего MAC-адреса при использовании IPv6 ? от суперпользователя.

Нет "роутера сервера". Пакеты могут достигать сервера со многих маршрутизаторов.

Нет "роутера клиента". Пакеты могут отправляться от клиента на многие маршрутизаторы.

Единственные устройства, которые могут видеть MAC-адрес, - это те, которые находятся в одной локальной сети - возможно, только те, которые находятся в том же сегменте кабеля.

Кстати, сервер также не может получить IP-адрес клиента, если клиент находится на другой стороне прокси-сервера.

Остались исходный и целевой IP-адрес. Идея межсетевого взаимодействия в основном основана на межсетевой доставке. Промежуточные маршрутизаторы / хосты понимают только MAC-адреса. Насколько мне известно, таблицы маршрутизации должны понимать машинный адрес.

Если MAC-адреса могут оставаться на протяжении всего пути пакета; Это означает, что не нужно было придумывать адреса Интернет-протокола. И весь Интернет использовал бы только MAC-адреса :-)

Вы можете достичь того, чего хотите, только если и сервер, и клиент находятся в одной локальной сети (оба хоста подключены с помощью некоторого носителя L1).

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

Тем не менее, если вам нужен MAC-адрес исходного хоста на принимающем хосте; думаете отправить его как полезную нагрузку?

Добавление:

Сети не обязательно должны быть одного типа во всем мире (например, Ethernet, Frame Relay и т. Д.). Сетевой уровень обеспечивает гибкость маршрутизации без различия между нижележащими уровнями (уровень канала передачи данных) или, я бы сказал, базовой технологией L1. Короче говоря, IP предоставит нам межсетевой уровень, а уровень канала передачи данных (где MAC-адреса фигурируют) позаботится о связи на микроуровне (то есть в локальной сети). Это хорошая причина сосуществования Mac и IP-адресов! :-)

Вы не можете - если клиент не является локальным для вашего сервера. Если это так, вы можете попробовать выполнить arp-ping и таким образом получить MAC-адрес клиента.

Вы думаете о прямом соединении между LAN сервера и LAN клиента, а Интернет работает не так. Между двумя локальными сетями может быть любое количество переходов - и, кстати, нет никаких ограничений, чтобы любая из них использовала что-либо вроде MAC, поэтому «MAC-адреса» не помещаются в IP-пакеты. «MAC» имеет смысл только в пределах LAN (фактически только один, нижние уровни которого используют что-то вроде MAC ;-), и обнаруживаются / объявляются с помощью протоколов ARP и RARP (которые не разводится ;-).

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

Прежде чем понять, почему сервер не может получить доступ к MAC-адресу своего клиента, давайте разберемся, как пакет данных проходит в сети.

Случай 1:

IP-адрес назначения будет известен сетевому приложению или получен от DNS-сервера, если приложение знает только доменное имя. Затем хост сравнивает IP-адрес назначения со своим собственным IP-адресом и маской подсети. Если целевой хост находится в сети исходного хоста, исходный хост отправит ARP-запрос по сети с вопросом «у кого есть этот IP-адрес?» и хост назначения ответит своим MAC-адресом.

Случай 2: (что обычно происходит в Интернете)

Если целевой хост не находится в сети исходного хоста, скажем, когда мы просматриваем Google.com, DNS преобразует имя в IP. исходный хост отправит ARP-запрос с вопросом «у кого есть IP-адрес моего шлюза по умолчанию?». В этом случае, поскольку он находится вне нашей сети, мы отправим ARP-запрос на наш шлюз по умолчанию (шлюз по умолчанию - это узел в компьютерной сети, использующий набор интернет-протоколов, который служит в качестве узла пересылки (маршрутизатора) в другие сети), и DG отвечает своим MAC. Вы отправляете пакет с IP-адресом назначения Google и MAC-адресом назначения нашей DG. Когда DG получает этот кадр со своим собственным MAC-адресом назначения и некоторым другим IP-адресом назначения в заголовке IP, он знает, что пакет не предназначен для себя, а только для прохождения. Затем продолжается поиск ip для google, а затем ARP для следующего перехода и т. Д.

Итак, вы видите, что уровень канала данных, который выполняет физическую адресацию, никогда не знал MAC-адрес пункта назначения, он знал только MAC-адрес следующего HOP (маршрутизатора). MAC-адрес следующего маршрутизатора получается через ARP-запрос. Итак, как получатель узнает MAC-адрес своего отправителя. Ну, он никогда не знал и не может, потому что каждый раз, когда пакет был получен маршрутизатором, он добавлял свой собственный MAC-адрес в поле исходного MAC-адреса или, скорее, заменял его своим собственным. Следовательно, сервер никогда не сможет узнать MAC-адрес своего получателя, поскольку его никогда не было в пакете. Остался только IP-адрес.