Site VPN'inden önce alt ağları planlayın: yeniden numaralandırın veya çevirin

İki ofis de 192.168.1.0/24 kullanıyor çünkü kimse başka türlü planlamamış ve tünelin bunu çözeceği bekleniyor. Çözemez: bir yönlendirici aynı özel adresin iki farklı yeri ifade etmesini sağlayamaz. Bunu önleyen iş, ilk tünel parametresi yazılmadan önce yapılır.

Unuttuklarınız dahil her aralığı envanterleyin

LAN'ları, sunucu segmentlerini, uzaktan erişim istemci havuzlarını, bulut VPC aralıklarını ve ana makinelerin ulaşması gereken tüm konteyner veya kaplama ağlarını toplayın. İstemci havuzları insanların unuttuğu olanlardır ve ikisi de aynı varsayılandan seçildiği için bir ofis aralığıyla şaşırtıcı sıklıkla çakışırlar. Yönetim ağını ve bant dışı her segmenti dahil edin.

Sahibini, ağ geçidini, amacını ve önekin diğer siteden erişilebilir olması gerekip gerekmediğini kaydedin. Tünelden hiç geçmesi gerekmeyen bir önekin benzersiz olması gerekmez ve bunu bilmek yeniden numaralandırma işini azaltır.

IPv6'yı ayrı yapın, çünkü planı ve çakışmaları bağımsızdır.

Tanıdık adresleri değil, önekleri karşılaştırın

Farklı ana makine adreslerine sahip iki ağ yine de çakışabilir, çünkü çakışma maskelerin özelliğidir, insanların hatırladığı sayıların değil. 10.20.0.0/16, 10.20.30.0/24'ü içerir; kimse bunu yüksek sesle söylesin ya da söylemesin. Tam önek çiftlerini karşılaştırın ve toplamları içlerindeki daha küçük ağlara karşı kontrol edin. Bu yüzden bu kontrol birinin kafasına değil, bir elektronik tabloya aittir.

Aynı kontrol VPN'in kendi istemci havuzu ve tanıtmayı planladığınız her çevrilmiş aralık için de geçerlidir, çünkü çakışan çevrilmiş bir aralık özgün çakışmadan daha kötüdür.

Maskeli önek tablosu yeterlidir; maskesiz bir diyagram değil.

Gerçekte neyin geçmesi gerektiğine karar verin

Bir sitede otuz alt ağ olabilirken bir hizmet ağı uzaktan erişim gerektirebilir. Bu gereksinimden başlayın ve yalnızca ihtiyaç duyduğunu duyurun, çünkü daha küçük duyurular ve eşleşen erişim kuralları gözden geçirmesi daha kolay ve kazara genişletilmesi daha zordur. Kullanımdaki her özel aralığı duyurmak, tüneli köprüye çeviren bir alışkanlıktır. Duyuru ne kadar dar olursa gelecekteki bir hatanın etki yarıçapı o kadar küçük olur.

Özel DNS, amaçlanan istemcilerin ulaşabileceği adresleri döndürmelidir, bu yüzden duyurulmamış veya çakışan bir aralığa işaret eden bir ad, arama başarılı olsa bile bozuk kalır.

Erişim listesini tünel yapılandırmasından önce yazın, başarısız olduktan sonra değil.

Yeniden numaralandırın veya çevirin, maliyeti bilin

Bir ağı yeniden numaralandırmak genellikle en net uzun vadeli çözümdür ve rezervasyonlara, cihazlara, DNS'e, güvenlik duvarı kurallarına ve yapılandırmaya adresi gömülü her şeye dokunur. Erişim aralığını çevirmek, yeniden numaralandırma pratik olmadığında alternatiftir ve kaynak kimliğine ek olarak adresleri yüke gömen bir protokol sınıfına mal olur. Birini seçin ve bitirin, çünkü yarısı yeniden numaralandırılmış bir ağ iki seçenekten de kötüdür.

Hangisini seçerseniz seçin, hem özgün hem de sunulan adresi belgeleyin, çünkü sonraki her sorun giderme konuşması ikisine de ihtiyaç duyar.

Dönüş yolu olmayan bir geçici çözüm geçici çözüm değildir.

Kabul testi olarak bir yol matrisi kullanın

Bir matrisle bitirin: yerel önek, uzak önek, izin verilen hizmet ve dönüş ağ geçidi. Bu tablo tünel açıldığında kabul testidir ve aynı zamanda bir sonraki mühendisin okuyacağı belgedir. Ağ geçitlerinden değil, seçilen alt ağlardaki gerçek ana makinelerden test edin.

Tünel adresleri arasındaki ping, tünelin var olduğunu kanıtlar ve arkasındaki adres planı hakkında hiçbir şey söylemez.

Matrisi tünel yapılandırmasıyla birlikte saklayın ve bir sonraki site eklemesi hafızadan değil veriden başlar. Plan oluştuğunda strongSwan yönlendirme kılavuzu ağ geçidi tarafını kapsar.