VPN için Kiralık Hat mı? Önce Gereksinimi Çevirin

Teklif, ofis VPN'i için belirli bir kiralık hattı adlandırıyor ve sayı hiçbir açıklama olmadan geliyor. İmzalamadan önce cümleyi gerçekte sakladığı dört gereksinime ayırın: fiziksel teslim, IP dağıtım düzeni, her iki yönde kapasite ve devrenin arkasındaki destek taahhüdü. Bunları tam bu sırayla kapı olarak işletin, çünkü teslimde başarısız olan bir devreyi daha büyük bir bant genişliği sayısı kurtaramaz. Sonra teslim edileni yazdıklarınızla karşılaştırın.

Ürün adını değil, gereksinimi çevirin

IPsec trafiği IP katmanında korur ve taşımayı satın aldığınız devreye bırakır. IPsec mimarisi trafiğin eşler arasında nasıl korunduğunu açıklar; teslim türü, garantili hızlar veya onarım süreleri hakkında hiçbir şey söylemez. Bunlar bir hizmet sözleşmesinin özellikleridir.

Bu ayrım, bir devre gereksiniminin meşru olup yine de VPN gereksinimi olmamasının tüm nedenidir. Yalnızca seri arayüzü olan bir ağ geçidi gerçekten seri teslim gerektirir ve bu protokol değil donanım kısıtıdır. Cihazı değiştirin, kısıt kaybolur. Her gereksinimi «ağ geçidine X gerekli çünkü Y» biçiminde yazın ve tamamlanamayan her satırı reddedin.

Hızdan önce teslimi adlandırın

Teslim, sınır noktasındaki fiziksel ve bağlantı katmanı bağlantısıdır: bakır Ethernet, belirli alıcı-vericili fiber, seri arayüz veya yalnızca mevcut cihazda olduğu için var olan daha eski bir şey. Burada hata yapmak, bant genişliğinde asla olmayan bir biçimde pahalıdır, çünkü genellikle iki uçta da yeni donanım anlamına gelir. Eksik optik bir kapasite sorunu değildir ve hiçbir yükseltme onu düzeltmez.

Konnektörü, hız pazarlığını ve medya dönüştürücüyü veya yönlendiriciyi kimin sağladığını doğrulayın. Sonra sorumluluğunuzun nerede bittiğini doğrulayın, çünkü hat 03:00'te düştüğünde kimin neye dokunabileceğine sınır noktası karar verir. Bu sınırı devre tanımlayıcısının yanındaki kayda yazın. Destek çağrısını bir saatlik aktarım yerine beş dakikalık bir konuşmaya çeviren tek satır odur.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

Yalnızca adresi değil, IP dağıtımını doğrulayın

Hizmetin gerçekte hangi adresi veya öneki dağıttığını ve statik olup olmadığını sorun. Dinamik adres veren bir devre, siteler arası ağ geçidine pek uygun değildir, çünkü eş yapılandırması planlamadığınız bir değişikliğe dayanmalıdır. Önek uzunluğunu da doğrulayın, çünkü tek adres ve yönlendirilmiş bir /29 farklı ürünlerdir.

Sonra size ulaşmadan önce bir şeyin adresi çevirip çevirmediğini sorun. Hizmetin önündeki sağlayıcı tarafı NAT veya operatör düzeyi NAT, gelen oturumları bozar, bu yüzden uzak sitelerden IPsec kabul etmeyi bekleyen bir ağ geçidine ulaşılamaz. Hız bunu telafi etmez: kontrol etmediğiniz bir çeviricinin arkasındaki hızlı bir hat, kimsenin yönlendirmediği bir bağlantı noktasına gelen bağlantıyı yine kabul edemez.

Yönlendiricinin ve DNS'in kime ait olduğunu kaydedin. Yönlendiriciyi sağlayıcı sağlıyorsa, onun ürün yazılımını, NAT davranışını ve varsayılan yol hakkındaki fikrini devralırsınız ve sonraki her değişiklik bir talep üzerinden geçer. Ağınızın dışından birinden, erişilebilir olmasını beklediğiniz bağlantı noktasına gelen bir bağlantı denemesini isteyin, çünkü çeviri hikâyesini kanıtlayan tek test budur.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

Kapasiteyi iş yükünden, iki yönde hesaplayın

Kapasite, kullanıcı başına bir sayıyla değil, işle tanımlanmalıdır. Toplu dosya erişimi, etkileşimli yönetim ve gece yedeklemesi her biri farklı bir trafik deseni üretir ve yalnızca biri sürekli yukarı yönlü aktarım hızını önemser. Koltuk başına bant genişliği sayısı bir satış kolaylığıdır, model değil.

Her iki yönü tahmin edin, kapsülleme ek yükünü ekleyin ve trafiğin ani mi sürekli mi olduğunu not edin. Sonra sözleşmenin reklam hızını değil garantili hızını kontrol edin, çünkü birkaç saniye sonra sona eren ani izin, gece yedeklemesine yardımcı olmaz. Ağ geçidinin kendi sınırlarını da aynı bütçeye koyun, çünkü şifreleme işlemesi ve eşzamanlı oturum sayısı devreden çok önce sınır olabilir. Daha hızlı bir hat doymuş bir ağ geçidini düzeltmez.

Operasyonel taahhütleri sabitleyin

Kullanılabilirlik, onarım yanıtı, yükseltme yolu ve bakım bildirimi yazılı olmalı ve ölçüm yöntemi adlandırılmalıdır. Reklamı yapılan internet hızı bu özelliklerin hiçbirini kurmaz; kesintiyi tanımlamadan güvenilirlik vaat eden bir pazarlama sayfası da kurmaz. Saatin nasıl başladığını sorun, çünkü sağlayıcının kendi onayından ölçülen yanıt süresi, sizin izleme uyarınızdan ölçülenle aynı sayı değildir. Bu iki tanım, kimse yalan söylemeden saatlerce farklı olabilir.

Destek sınırını da kaydedin. Sağlayıcının sorumluluğu, kendi yönlendiricinizin sonlandırdığı bir teslimde bitiyorsa, her olayın ilk saati hatanın kimde olduğunu belirlemeye gider ve hiçbir SLA saati bunu kapsamaz.

Devreyi yazılı koşullara göre doğrulayın

Hizmet devreye girdiğinde, kurulumcunun gösterdiği özellikleri değil, gerçekten sözleştiğiniz özellikleri ölçün. Gerçek yoldaki aktarım hızı, gecikme ve kayıp kanıttır ve adlandırabileceğiniz bir zamanda ve konumdan kaydedilmelidir. Ölçümü yalnızca teslimde değil, yoğun bir saatte de tekrarlayın. Sakin bir günde 10:00'da yapılan kabul testi, 15:00'teki hat hakkında çok az şey söyler.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

Sonuçları sözleşmeyle birlikte saklayın, çünkü temel çizgi olmadan performans tartışması izlenimler üzerine bir tartışmadır. Bir ölçüm taahhüdü karşılamıyorsa, kanıt tazeyken ve hizmet hâlâ sözleşmenin sağladığı kabul penceresi içindeyken gündeme getirin. İstekte adlandırılmış bir ana bilgisayar TLS el sıkışmasını da geçerli tutar, böylece bir sertifika uyarısı başarısız bir devreyle karıştırılmaz.

Son olarak, dört kapıyı teslim edilene göre yeniden okuyun. Teslim, IP dağıtımı, kapasite ve destek koşullarının her birinin kayıtta bir satırı vardır ve her satırın yanında bir ad vardır.