Dlaczego przełączniki nie przepisują adresów MAC?

Czy istnieje jakiś szczególny powód, dla którego przełączniki Ethernet nie zmieniają adresu MAC pakietu?

Czy służy to identyfikacji hosta końcowego przy użyciu adresu MAC, czy czegoś innego?

Gdyby przełącznik miał zmienić adresy MAC, całkowicie zepsułoby to sieć.

Adres MAC jest unikalnym identyfikatorem używanym przez hosty w sieci lokalnej.

Gdyby przełącznik zmienił docelowy MAC, ramka nie zostałaby dostarczona do odpowiedniego hosta. W takich przypadkach, na przykład w przypadku zalania ramki, host docelowy upuści ją, ponieważ nie będzie już przeznaczony dla hosta.

Gdyby przełącznik miał zmienić źródłowy adres MAC, host docelowy użyłby tego adresu MAC do wszelkich odpowiedzi (w tym do aktualizacji wpisów ARP o złe dane). Spowodowałoby to tę samą sytuację, którą już opisałem, tylko dla całego ruchu powrotnego.

Może to dodatkowo powodować problemy z takimi rzeczami, jak 802.1X i innymi mechanizmami, które wykorzystują adres MAC do identyfikacji / klasyfikacji urządzenia.

Czy można by to opracować mechanizmy? Jestem pewien, że mogliby. Ale w tym momencie nie ma powodu, aby to robić, a to tylko skomplikowałoby pracę w sieci i spowodowało niepotrzebne przetwarzanie. Nie jesteśmy bliscy wyczerpania dostępnej puli adresów MAC, więc nie potrzebujemy czegoś takiego jak MAT (nie wiem, czy koncepcja translacji adresów MAC w ogóle istnieje, więc może właśnie stworzyłem termin?).

Ponowne zapisywanie adresów datagramów odbywa się na warstwie 3, na przykład, gdy bramy (router lub zapora) z translacją NAT przepisują adresy IP hostów w sieci wewnętrznej, tak aby wszystkie pojawiały się z jednego (lub kilku) zewnętrznych adresów IP w samej bramie.

Powodem tego, że coś podobnego nie dzieje się na poziomie warstwy 2 (gdzie używamy adresów MAC do rozróżnienia hostów i przełączników wykonujących ruch datagramów, czyli ramek) jest, jak powiedziano w komentarzach powyżej, że tak naprawdę nie ma takiej potrzeby.

W przypadku trzeciej warstwy z NAT NAT rozwiązuje wiele problemów:

• Adresy IP są używane do globalnej komunikacji, a dostępna jest ograniczona pula adresów IP, które należy udostępnić. Używając NAT, upewniasz się, że większa liczba hostów wewnętrznych może współdzielić mniej (zwykle tylko jeden) adres IP widoczny w publicznym Internecie.
• Przepisywanie adresów IP przez niektórych, ale nie wszyscy, rozważa dodanie warstwy bezpieczeństwa poprzez maskowanie adresów IP wewnętrznych maszyn.

Tak więc, jeśli będziemy trzymać się przykładu NAT, tak naprawdę nie ma potrzeby tworzenia drugiej warstwy NAT.

• Adresy MAC nie są globalnie używane do adresowania datagramów w Internecie, służą do wysyłania ramek do odpowiednich hostów w lokalnej podsieci. Ponieważ lokalne podsieci są stosunkowo małe, a liczba możliwych adresów MAC jest bardzo duża, nie „wyczerpuje się” dostępnych adresów MAC na poziomie warstwy 2. (Opcja ręcznej rekonfiguracji adresów MAC kart sieciowych na dowolną wartość nie zmienia tego)
• A dla dyskusyjnej korzyści bezpieczeństwa wynikającej z przepisywania adresów datagramów podczas przesyłania: Ponieważ adresy MAC są używane tylko w lokalnej podsieci, zwykle można względnie lepiej kontrolować pod względem bezpieczeństwa w tej podsieci (zarówno fizycznie, jak i większość zaangażowanych urządzeń) w porównaniu z odpowiednikiem w przypadku warstwy 3, którym jest cały internet (nad którym my jako użytkownicy połączeni i inżynierowie sieci w praktyce nie mamy kontroli bezpieczeństwa).

Mam nadzieję, że rzuciło to nieco światła na to, dlaczego przełączniki nie przepisują adresów MAC. Jedyny przypadek warstwy 3, który wymyśliłem z góry głowy, to NAT, inni z pewnością mogą podać przykład innych przypadków warstwy 3, w których przepisywanie adresów IP jest uzasadnione (i dlaczego te technologie nie mają sensu na poziomie warstwy 2) .

Przepisanie adresu MAC spowodowałoby znaczną złożoność (przełącznik musiałby wiedzieć o protokołach wyższego poziomu, takich jak arp, aby mógł przepisać rozwiązywanie adresów), utrudniłoby rozwiązywanie problemów, uniemożliwiłoby działanie protokołów takich jak STP i generalnie byłby PITA. Zwykle nie jest to również potrzebne.

Co nie znaczy, że to niemożliwe. ebtables (odpowiednik iptables warstwy 2) ma kilka opcji translacji adresów MAC. Może to być przydatne, jeśli masz przełączniki, które nie używają tabel MAC per-vlan i chcesz przeprowadzić filtrowanie warstwy 2.

http://ebtables.netfilter.org/examples/example1.html