Anahtarlar neden mac adreslerini yeniden yazmıyor?

10

Ethernet anahtarlarının bir paketin MAC adresini değiştirmemesinin belirli bir nedeni var mı?

MAC adresini kullanarak son ana bilgisayar tanımlaması mı yoksa başka bir şey mi?

ethernet protocol-theory mac-address

— user2720323
kaynak

5

İsminizin Kumar olduğunu varsayalım. İnsanlar size "Jessica" demeye başlarsa hoşuna gider mi?

— Mike Pennington

1

anahtarlar paketleri (çerçeveleri) yeniden yazmaz; sadece arayüzden arayüze taşırlar. (yayın / çok noktaya yayın durumunda, bu birden çok bağlantı noktasına kopyalamayı içerir.)

— Ricky Beam

4

Eğer bir anahtar neden geçerli bir sebep düşünemiyorum Can gerektiğini MAC adresini değiştirmek?

— Teun Vink

Herhangi bir cevap size yardımcı oldu mu? öyleyse, cevabı kabul etmelisiniz, böylece soru sonsuza kadar ortaya çıkmayacak, bir cevap arıyor. Alternatif olarak kendi cevabınızı verebilir ve kabul edebilirsiniz.

— Ron Maupin

10

Bir anahtar MAC adreslerini değiştirecek olsaydı, ağ iletişimi tamamen kesilirdi.

MAC adresi, yerel ağdaki ana bilgisayarlar tarafından kullanılan benzersiz bir tanımlayıcıdır.

Anahtar hedef MAC'i değiştirecek olsaydı, çerçeve uygun ana bilgisayara teslim edilmezdi. Örneğin, çerçeve sular altında kalırsa, hedef ana bilgisayar, artık ana bilgisayar için hedeflenmeyeceği için bırakacaktır.

Anahtar kaynak MAC adresini değiştirecek olsaydı, hedef ana bilgisayar bu MAC adresini yanıtlar için kullanır (ARP girişlerinin hatalı verilerle güncellenmesi dahil). Bu, tüm dönüş trafiği için daha önce tarif ettiğim durumla sonuçlanır.

Bu, 802.1X ve aygıtı tanımlamak / sınıflandırmak için MAC adresini kullanan diğer mekanizmalarla ilgili sorunlara neden olabilir.

Bunu yapmak için mekanizmalar geliştirilebilir mi? Eminim yapabilirler. Ancak bu noktada bunu yapmak için hiçbir neden yoktur ve bu sadece ağ oluşturmayı zorlaştırır ve gereksiz işlemleri ekler. Mevcut MAC adres havuzunu tüketmeye yakın değiliz, bu yüzden MAT gibi bir şeye gerek yok (MAC adres çevirisi kavramının herhangi bir yerde var olup olmadığını bilmiyorum, bu yüzden belki sadece bir terim yazdım?).

— YLearn
kaynak

4

Datagramların adreslerinin yeniden yazılması, katman 3'te, örneğin NAT çalıştıran ağ geçitleri (yönlendirici veya güvenlik duvarı) iç ağdaki ana bilgisayarların IP adreslerini yeniden yazdıklarında, hepsi ağ geçidinin kendisindeki bir (veya birkaç) harici IP adresinden göründüğünde gerçekleşir.

Katman 2 düzeyinde benzer bir şeyin olmamasının nedeni (ana bilgisayarları ve anahtarları datagramların, yani çerçevelerin hareketini yapmak için MAC adreslerini kullandığımız yerlerde) yukarıdaki yorumlarda gerçekten buna gerek olmadığını söylediği gibidir.

NAT ile üçüncü katman durumunda NAT bir takım problemleri çözer:

IP adresleri genel iletişim için kullanılır ve paylaşılması gereken sınırlı bir IP adresi havuzu vardır. NAT kullanarak, daha fazla sayıda dahili ana bilgisayar, genel internette görünen daha az (genellikle yalnızca bir) IP adresini paylaşabilir.
IP adreslerinin yeniden yazılması, herkes tarafından olmasa da, iç makinelerin IP adreslerini maskeleyerek bir güvenlik katmanı eklediği düşünülür.

Dolayısıyla, NAT örneğine sadık kalırsak, NAT katmanının iki muadiline gerçekten gerek yoktur.

MAC adresleri küresel olarak internetteki datagramları adreslemek için kullanılmaz, yerel alt ağdaki doğru ana bilgisayarlara çerçeve göndermek için kullanılır. Yerel alt ağlar nispeten küçük olduğundan ve olası MAC adreslerinin sayısı çok büyük olduğundan, katman 2 düzeyinde kullanılabilir MAC adresleri "tükenmez". (NIC'lerin MAC adreslerini rasgele bir değere elle yapılandırma seçeneği bunu değiştirmez)
Ayrıca, yönlendirme sırasında datagram adreslerini yeniden yazmanın tartışmalı güvenlik avantajı için: MAC adresleri yalnızca yerel bir alt ağda kullanıldığından, göreceli olarak, o alt ağ üzerindeki güvenlik açısından (fiziksel olarak ve çoğu tüm cihazlar olan (uygulamada bağlı kullanıcılar ve ağ mühendisleri olarak hiçbir güvenlik kontrolümüz yoktur) katman 3 vakasındaki muadili ile karşılaştırıldığında.

Umarım bu, anahtarların neden MAC adreslerini yeniden yazmadığı konusunda biraz ışık tutar. Başımın üstünden geldiğim tek katman 3 vakası NAT'dı, diğerleri kesinlikle IP yeniden yazma işlemlerinin garanti edildiği diğer katman 3 vakalarına örnek verebilir (ve bu teknolojiler neden katman 2 seviyesinde anlamsızdır) .

— IllvilJa
kaynak

3

Spot-on, ama cevabınızla ilgili küçük bir kelime oyunu var. "NAT'ın iki muadili bir katmana gerçekten gerek yok" dan bahsettiniz ... MAC NAT'ı görmeme rağmen, mac düzeyinde tünelleme gördüm. Bazı durumlarda, diğer mac adreslerinin içindeki "tünel" mac adreslerine geçiş yapmak mantıklıdır. Hemen akla gelen durum IEEE 802.1ah Tedarikçi Tabanlı Köprüleme'dir (PBB) . Genellikle, bu, mevcut vlansları ölçeklendirmek / servis sağlayıcı metro halkalarında mac öğrenmesini azaltmak için kullanılır

— Mike Pennington

1

@IllvilJa: İyi dedi ..! Son birkaç hafta beni şaşırtan bir şüpheyi çözdün. Birkaç hafta önce şöyle düşündüm ... "Bir yönlendirici, bir WAN ile uğraşırken, gönderenin MAC adresi (her pakette) yerine MAC adresini koyma ve paketleri alıcıya aktarma eğilimindedir. LAN, yönlendirici, göndericinin MAC adresi yerine MAC adresini koymaz (her pakette), ancak paketleri gönderen ve alıcı arasında geçirir "Ancak açıklamanızdan sonra 'yönlendirici' ve ' Bir anahtar'. Tekrar teşekkürler..!

— Maharan

0

MAC adresinin yeniden yazılması önemli ölçüde karmaşıklık katacaktır (anahtar, arp gibi daha üst düzey protokolleri bilmelidir), böylece adres çözümlemesini yeniden yazabilir), sorun gidermeyi zorlaştıracak, STP gibi protokollerin çalışmasını engelleyecek ve genellikle bir PITA olacaktır. Ayrıca normalde gerekli değildir.

Bu mümkün olmadığını söylemek değil. ebtables (katman 2 ile iptables arasındaki karşılık) MAC adres çevirisi için bazı seçeneklere sahiptir. Bu, vlan başına MAC tabloları kullanmayan anahtarlarınız varsa ve bazı katman 2 filtrelemesi yapmak istiyorsanız yararlı olabilir.

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

— Peter Green
kaynak