MAC-адрес отправителя, MAC-адрес получателя и MAC-адрес маршрутизатора - в локальной сети: тестирование с помощью java jpcap

В настоящее время я занимаюсь «самостоятельным изучением» сетей с коммутацией пакетов, включая TCP, UDP и другие протоколы. Я подтвердил, что MAC-адрес отправителя не может быть отправлен напрямую получателю, поскольку пакеты, как правило, проходят через несколько маршрутизаторов (где есть глобальная сеть).

Но в локальной сети я предположил аналогичный сценарий, давайте предположим, что есть один маршрутизатор для двух терминалов, которые связываются с простым «TCP-чатом», разработанным на Java. (код давать не буду). Я разработал простой «сниффер пакетов» в java (с помощью jpcap), который извлекает MAC-адреса из каждого «заголовка пакета» и помещает их в текстовый файл следующим образом...

Destination MAC: ##:##:##:##:##:##           /*My Terminal's MAC*/
Source MAC: ##:##:##:##:##:##        /*Sender's Terminal's MAC*/

В ПОРЯДКЕ..? Теперь... Я сомневаюсь... в приведенных выше данных я обнаружил, что MAC-адрес маршрутизатора не включен...! Когда мой терминал является получателем, у которого есть этот анализатор пакетов, поэтому я могу напрямую видеть MAC-адрес отправителя выше..!

Но мой аргумент заключается в том, что между отправителем и получателем нет маршрутизатора (в локальной сети)? Тогда почему приведенный выше код не показывает MAC-адрес этого маршрутизатора вместо MAC-адреса отправителя?

Но когда я выполнил свой «анализатор пакетов» при подключении к Google через браузер, я заметил, что приведенные выше данные просматриваются следующим образом...

Destination MAC:  ##:##:##:##:##:##  /* My LAN-Router's MAC */
Source MAC: ##:##:##:##:##:##  /* My Terminal's MAC */

Здесь я вижу MAC-адрес моего LAN-маршрутизатора...!

Кто-нибудь может объяснить, почему я не вижу MAC-адрес LAN-маршрутизатора, когда связываюсь через TCP-чат с узлом в локальной сети...?

Заранее спасибо..!


person Maharan    schedule 27.04.2014    source источник


Ответы (1)


Способы просмотра веб-страниц и чата (обычно) различаются. Когда вы подключаетесь к Google, вы подключаетесь не напрямую к IP-адресу Google (хотя вы также можете это сделать), а, вероятно, к www.google.com, который требует, чтобы DNS определял IP-адрес, на который должен быть отправлен HTTP-запрос. отправлено в. Когда вы используете чат TCP, вы направляетесь прямо к чату TCP на чужой машине.

person jedison    schedule 27.04.2014
comment
Конечно, сэр. Но как бы то ни было, компьютер, находящийся в локальной сети, изначально должен связаться с соседним устройством (обычно маршрутизатором, концентратором, коммутатором и т. Д.), Затем через это устройство отправляются пакеты, не так ли? Следовательно, какой бы пакет ни пришел на этот компьютер (скажем, «из глобальной сети»), он должен иметь MAC-адрес этого устройства в качестве MAC-адреса отправителя, нет? Но когда это локальная сеть, я заметил выше, что MAC-адрес соседнего устройства не был включен в пакет, который был отправлен от однорангового узла (который находился в локальной сети) через это соседнее устройство, но MAC-адрес однорангового узла был включен. Как это случилось? - person Maharan; 27.04.2014
comment
Нет, не обязательно. Когда я отправляю пакеты TCP/IP на IP-адрес xxx.xxx.xxx.xxx, они отправляются на этот IP-адрес — может быть включен MAC-адрес. Когда я отправляю пакеты TCP/IP на www.google.com, я понятия не имею, какой у Google MAC-адрес — я должен указать MAC-адрес DNS-сервера. - person jedison; 27.04.2014
comment
Да, сэр, даже мы понятия не имеем о MAC-адресе нашего интернет-провайдера. С помощью перехвата пакетов мы можем отследить только MAC-адрес соседнего маршрутизатора. (Далее мы можем использовать DOS-команду «tracert» для IP-адресов, но не для MAC-адресов). Тогда я могу решить, что маршрутизатор имеет тенденцию помещать свой MAC-адрес вместо MAC-адреса LAN-клиента (в каждом пакете), когда он подключается к глобальной сети. ... но в случае локальной сети маршрутизатор этого не делает, а просто передает пакеты между отправителем и получателем. Разве не сэр..? - person Maharan; 28.04.2014
comment
Да, это было бы так. - person jedison; 28.04.2014
comment
Сэр... Отсюда я узнал больше... networkengineering.stackexchange.com/a/5339/5468 - person Maharan; 29.04.2014