OSI ve TCP/IP yazısında bir ayrıntıyı sonraya bırakmıştık: istemci başka ağdaki bir sunucuya paket gönderirken çerçevenin hedef MAC adresi sunucunun değil, default gateway’in adresidir. Bu yazı o cümlenin arkasındaki mekanizmayı anlatıyor: bir cihaz paketi kime teslim edeceğine nasıl karar verir, teslim adresini nasıl öğrenir ve paket yol aldıkça hangi alanlar değişir?
İki adres, iki görev
Bir paketin üzerinde iki farklı adres türü bulunur ve ikisi farklı işler yapar:
- IP adresi paketin, yani IPv4 başlığının içinde taşınır ve nihai hedefi söyler. Örnekte istemci 10.0.20.25, sunucu 10.0.30.10’dur. Bu adresler ağ katmanındadır ve arada NAT yoksa yol boyunca değişmez.
- MAC adresi Ethernet çerçevesinin başlığında taşınır ve çerçevenin aynı yerel bağlantı üzerinde kime teslim edileceğini söyler. 48 bitliktir ve genellikle altı bayt olarak yazılır:
00-00-5E-00-53-25ya da00:00:5e:00:53:25. İlk üç bayt, adres bloğunu IEEE’den almış kuruluşun kimliğidir (OUI).
Bu yazıdaki MAC adresleri, RFC 9542’nin belgelerde kullanılmak üzere ayırdığı 00-00-5E-00-53-00 ile 00-00-5E-00-53-FF aralığındandır; gerçek bir cihaza ait değildir.
Kısacası IP “nereye”, MAC “bu adımda kime” sorusunun cevabıdır. İkisini birbirine bağlayan şey de ARP’dir.
İlk karar: hedef benim ağımda mı?
İstemci bir paket göndermeden önce, hedefin kendi bulunduğu alt ağda olup olmadığına bakar. Bu kararı VLAN’a bakarak vermez; erişim portuna bağlı bir bilgisayar hangi VLAN’da olduğunu genellikle bilmez bile. Kararı kendi IP adresi, alt ağ maskesi ve yönlendirme tablosuyla verir. RFC 1122’ye göre hedef, maske uygulandığında istemcinin kendi ağıyla aynı çıkıyorsa doğrudan gönderilir; aynı çıkmıyorsa ancak bir gateway üzerinden ulaşılabilir. VLAN’ın rolü başkadır: istemcinin bağlı olduğu L2 bağlantı alanını, yani ARP yayınının ulaşabileceği cihazları belirler.
Örnekteki istemcinin ayarları DHCP’den gelir: adres 10.0.20.25, maske 255.255.255.0 (/24), default gateway 10.0.20.1. Bu ayarların DHCP ile nasıl dağıtıldığı ve nerede bozulabileceği AP Online Ama İstemci IP Alamıyor yazısında. İstemcinin yönlendirme tablosu bu ayarlardan oluşur; sadeleştirilmiş hâliyle iki satırdır:
| Hedef | Nereye gönderilir? |
|---|---|
| 10.0.20.0/24 (kendi alt ağı) | Doğrudan, aynı bağlantıdaki hedefe |
| 0.0.0.0/0 (geri kalan her yer) | Default gateway 10.0.20.1’e |
/24 maskesinde ilk üç bölümü 10.0.20 olan her adres istemcinin kendi alt ağındadır. Maskenin farklı uzunluklarda nasıl hesaplandığı subnetting yazısının konusu; burada yalnızca kararın maskeyle verildiğini bilmek yeterli.
Default gateway “internet çıkışı” değildir; istemcinin kendi alt ağı dışındaki her hedef için ilk duraktır. Örnekteki sunucu aynı binada, hatta aynı switch’e bağlı olabilir; başka bir alt ağdaysa paket yine önce gateway’e gider.
ARP: IP adresinden MAC adresine
Karar verildikten sonra istemcinin elinde bir IP adresi vardır: ya hedefin kendisinin (yazıcı 10.0.20.30) ya da gateway’in (10.0.20.1). Çerçeveyi gönderebilmek için bu adresin MAC karşılığını bilmesi gerekir. Bunu ARP (Address Resolution Protocol, RFC 826) ile öğrenir:
- ARP Request: İstemci “10.0.20.1 kimde?” diye sorar. Soruyu kime soracağını bilmediği için çerçeveyi yayın adresine,
FF-FF-FF-FF-FF-FF’e gönderir. Çerçevenin EtherType alanı 0x0806’dır; içeride IPv4 değil ARP olduğunu söyler. Yayın, aynı yerel ağdaki bütün cihazlara ulaşır; adres kendisine ait olmayanlar soruyu yanıtlamaz. - ARP Reply: 10.0.20.1 adresinin sahibi olan gateway, yanıtı yalnızca soran istemcinin MAC adresine, unicast olarak gönderir: “10.0.20.1,
00-00-5E-00-53-01’de.”
RFC 826’ya göre isteğin hedefi olan cihaz, istekteki gönderenin IP–MAC eşleşmesini kendi tablosuna ekler. Bu yüzden istek sırasında gateway de istemcinin eşleşmesini öğrenmiş olur.
ARP, yanıtın gerçekten adresin sahibinden gelip gelmediğini doğrulamaz. Bu zayıflığın nasıl istismar edildiği ve Dynamic ARP Inspection ile nasıl önlendiği Layer 2 Saldırıları yazısında.
ARP önbelleği: her pakette sormamak
Her paket için yeniden ARP yapılsaydı yerel ağ yayınla dolardı. Bunun yerine öğrenilen eşleşmeler ARP önbelleğinde (ARP tablosu) tutulur ve sonraki paketler doğrudan bu kayıtla gönderilir. Eşleşme henüz yoksa RFC 1122’ye göre en az son paket saklanır ve ARP tamamlanınca gönderilir.
Kayıtlar kalıcı değildir. RFC 1122, eskimiş kayıtların temizlenmesini zorunlu tutar; süre işletim sistemine ve cihaza göre değişir. Böylece bir IP adresi başka bir cihaza geçtiğinde ya da ağ kartı değiştiğinde eski kayıt bir süre sonra düşer.
Önbelleği kendi bilgisayarınızda görebilirsiniz: Windows’ta arp -a, Linux’ta ip neigh show. Gateway’e bir kez erişmiş bir istemcide 10.0.20.1 için bir kayıt görürsünüz. Uzak sunucu 10.0.30.10’a erişilmiş olsa bile tabloda onun MAC adresi yer almaz; istemci o sunucu için hiç ARP yapmamıştır, çünkü çerçeveyi gateway’e gönderir. Bu, ilk karardaki ayrımın tabloda görünen izidir. Gateway tarafında da aynı türden bir tablo vardır; erişim sorunlarında bu tablonun nasıl okunacağı Wi-Fi Bağlı Ama İnternet Yok yazısında.
ARP tablosu, switch’in MAC tablosuyla aynı şey değildir. ARP tablosu IP adresini MAC adresine bağlar ve IP ile çalışan cihazlarda (istemci, router, L3 switch, firewall) bulunur. MAC tablosu ise MAC adresini switch portuna bağlar; switch’in çerçeveyi hangi porttan çıkaracağını bilmesini sağlar. Nasıl öğrenildiği ayrı bir yazının konusu.
Yol boyunca değişen ve değişmeyen alanlar
İstemci sunucuya (10.0.30.10) gönderdiği paketi, gateway’in MAC adresine yazılmış bir çerçeveyle gönderir. Gateway çerçeveyi açar, hedef IP’ye bakar ve sunucunun kendi doğrudan bağlı ağında (VLAN 30, 10.0.30.0/24) olduğunu görür. Sunucunun MAC adresini gerekirse o ağda kendisi ARP ile öğrenir ve paketi yeni bir Ethernet çerçevesiyle gönderir.
Burada değişen, cihazların MAC adresleri değil, her yeni Ethernet çerçevesinin kaynak ve hedef MAC alanlarıdır: ilk bağlantıda istemciden gateway’e, ikincide gateway’den sunucuya. RFC 1812 router’ın işini aynı biçimde özetler: gelen çerçevenin bağlantı katmanı başlığını kaldırır, IP başlığını günceller (örneğin TTL’i bir azaltır) ve paketi yeni bir bağlantı katmanı başlığıyla iletir. Kaynak ve hedef IP adresleri ise bu örnekte uçtan uca aynı kalır, çünkü arada NAT yoktur.
Maske yanlış girilirse
Maskenin bu karardaki rolü, yanlış girildiğinde daha net görülür. Elle ayarlanmış bir bilgisayarda 255.255.255.0 yerine 255.255.0.0 (/16) girildiğini düşünelim. İstemcinin doğrudan bağlı ağı artık 10.0.0.0/16’dır ve 10.0.30.10’u da kendi ağında sanır. Bu yüzden sunucuya giderken gateway’i değil, sunucunun kendisini ARP ile sorar.
İstek yalnızca VLAN 20’ye yayılır; sunucu VLAN 30’da olduğu için soruyu duymaz. Gateway proxy ARP ile bu soruya kendi adına yanıt vermiyorsa (RFC 1027; bu davranış üreticiye ve ayara göre açık ya da kapalı olabilir) yanıt gelmez. Sonuç tipiktir: aynı VLAN’daki yazıcıya erişim çalışır, başka alt ağdaki sunucuya erişim çalışmaz. Kablo, VLAN ve gateway sağlam görünürken sorunun istemcinin maskesinde olabileceğini akılda tutmak gerekir.
IPv6’da durum
IPv6’da ARP yoktur. Aynı işi Neighbor Discovery (RFC 4861) yapar: adres çözümlemesi yayınla değil, hedefe özgü bir multicast adrese gönderilen Neighbor Solicitation mesajıyla yapılır; cevap unicast Neighbor Advertisement ile gelir. Mantık aynıdır: IP adresinden yerel bağlantıdaki teslim adresine.
Kısaca
Bir paketin yolculuğu iki sorunun tekrarıdır: “hedef benim ağımda mı?” ve “bu adımda kime teslim edeceğim?”. İlkine maske ve yönlendirme tablosu, ikincisine ARP cevap verir. Bu iki soruyu ayırabilen biri, gateway’e ulaşılamayan ya da aynı VLAN’da olup birbirini göremeyen cihazlarda nereden başlayacağını bilir.
Kaynaklar
- RFC 826: An Ethernet Address Resolution Protocol
- RFC 894: Transmission of IP Datagrams over Ethernet Networks
- RFC 1122: Requirements for Internet Hosts, Communication Layers
- RFC 1812: Requirements for IP Version 4 Routers
- RFC 1027: Using ARP to Implement Transparent Subnet Gateways (proxy ARP)
- RFC 4861: Neighbor Discovery for IP version 6
- RFC 9542: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
- IANA: IEEE 802 Numbers (EtherType)
- Microsoft Learn: arp
- Linux man-pages: ip-neighbour(8)