Aynı alt ağa sahip iki saha neden tek bir LAN değildir
Bir uçbirim, herhangi bir VPN yönlendiricisi paketi görmeden önce doğrudan bağlantı ile sonraki atlama arasında karar verir. Aynı öneki paylaşan iki sahanın uzatılmış bir bağlantıya veya yeniden numaralandırma planına ihtiyacı vardır.
İki ofis de 192.168.77.0/24 kullanıyor ve biri tek ağ olmaları için bir tünel öneriyor. Bu ifade kulağa basit gelir ve üç farklı tasarımı gizler: çakışan iki bağımsız LAN, bir WAN üzerinden bilerek uzatılmış bir Ethernet segmenti ve uzak adresler adına yanıt veren bir proxy-ARP düzeni. Hangisine sahip olduğunuz, uçbirimin paketle ne yaptığını belirler ve yanıt VPN geçidi devreye girmeden önce görülür.
Uçbirim yönlendiriciden önce karar verir
192.168.77.10/24 adresli bir uçbirim, hedefi kendi önekiyle karşılaştırır. Bu önekin içindeki her şey doğrudan bağlantıdadır, bu yüzden uçbirim hedefin bağlantı katmanı adresini doğrudan çözer. Dışarıda kalan her şey varsayılan geçide gider.
Bu karar tünelde değil, uçbirimin yığınında verilir. Geçide eklenen bir yol, uçbirimin oraya hiç göndermediği bir paketi kurtaramaz.
Bu yüzden 192.168.77.20 yalnızca diğer sahada varsa, yerel uçbirim onu ARP ile sorar ve yanıt alamaz. VPN el sıkışması tamamen sağlıklı olabilirken bu başarısız olur. Arıza yönlendirme sorunu gibi değil, ölü bir uçbirim gibi görünür. Bu imzayı tanımak tünel hata ayıklamasında bir saat kazandırır.
ARP yerel bağlantının sorusudur
ARP bu bağlantıda adresin kime ait olduğunu sorar ve yanıt yayını duyabilen bir şeyden gelmelidir. Bir IPsec tünelinin diğer ucundaki yönlendirici, tasarım iki sahayı tek bir yayın alanı yapmadıkça bunu duymaz.
Aynı adrese sahip iki cihaz durumu daha kötü yapar: başarılı bir çözüm bile hangisinin yanıt verdiğini söyleyemez.
Yinelenen adresleme bir yönlendirme hatası değildir ve hiçbir yol onu düzeltmez. Ya sahalar farklı öneklere yeniden numaralandırılır ya da bilerek tek bir bağlantı katmanı alanı olurlar.
Uzatılmış segment çerçeve taşır, yol değil
Köprülere bağlanan ve Ethernet taşıyan bir tünel, iki sahayı tek bir bağlantı katmanı alanının parçası yapar. ARP yayınları karşı tarafa ulaşır ve her köprü hangi MAC adreslerinin nerede olduğunu öğrenir. Linux köprüsü belgeleri bu MAC tabanlı iletme sınırını açıklar.
Burada uzak geçit iki özdeş alt ağ arasında hiç yönlendirme yapmaz. Çerçeveler kendi başına IP yönlendiren bir alt katmandan geçerken köprüler Ethernet konuşmasını uzatır.
Bedel daha büyük bir etki yarıçapıdır. Bilinmeyen hedeflere taşma, döngüler, DHCP dağıtımı ve benzersiz adresleme hepsi iki sahayı kapsayan tek bir plan gerektirir. WAN düştüğünde uçbirimler yerel saydıkları trafiği kaybeder. Köprüdeki filtreleme ve VLAN kuralları neyin geçeceğini sınırlayabilir, ancak taşıma yine de her yerel denetim çerçevesinin ulaşacağını vaat etmez.
Proxy ARP üçüncü tasarımdır
Bir yönlendirici uzak bir adres için ARP’ye yanıt verip sonra oraya yönlendirebilir. Bu, yayın alanını uzatmadan uzak uçbirimi gönderene doğrudan bağlantıda gibi gösterir.
Köprülemeden daha dar bir araçtır: iletmeye, dönüş yollarına ve her adresin net sahibine bağlıdır.
Rastgele IP dışı protokolleri de yönlendirilebilir yapmaz ve bir Ethernet yayın alanını yeniden üretmez. Gereksinim tam olarak bu ikame olduğunda kullanın, ertelenmiş yeniden numaralandırma için kısa yol olarak değil.
Gereksinimden seçin, sonra doğrulayın
Ofisler arası olağan uygulama erişimi için farklı önekler ve açık yollar daha net bir sınır verir. Gereksinim gerçekten bağlantı katmanı komşuluğuysa köprüleyin. Paylaşılan önekin tek nedeni henüz kimsenin bunu yapmamış olmasıysa yeniden numaralandırın.
Gerçekte hangi tasarıma sahip olduğunuzu uçbirime hedefle ne yaptığını sorarak doğrulayın:
ip route get 192.168.77.20
ip neigh show 192.168.77.20
Başarısız komşu kaydıyla doğrudan bağlantı sonucu, eksik bir bağlantı katmanı yoluna işaret eder. via sonucu geçidi adlandırır ve soruyu yönlendirmeye taşır. Bir köprüde, MAC’in tünel üzerinden öğrenilip öğrenilmediğini görmek için iletme veritabanını denetleyin. Her çıktı tasarım sorusunu yeniden başlatmak yerine daraltır.