Bir müşteri tünelin bağlandığını, ping’in yanıt verdiğini, giriş sayfasının yüklendiğini ve ardından aktarımın her denemede aynı noktada donduğunu bildiriyor. Bu örüntü çok şey söylüyor: erişilebilirlik çalışıyor, sürekli throughput çalışmıyor. Güvenlik duvarını açmadan önce VPN’in bu arızada herhangi bir payı olup olmadığını belirleyin. Büyük TCP’yi yolda tünel olmadan aynı ağ geçidinden geçirin; o da donuyorsa OpenVPN hiç işin içinde olmamıştır.

virtio ağ kartı kullanan bir pfSense konuğunun tam olarak bu biçimde başarısız olması için çok iyi bir nedeni vardır.

Küçük paketler geçer, büyük TCP takılır

El sıkışmalar, DNS yanıtları ve ICMP yankıları küçüktür ve genellikle geçer. Sürekli aktarımlar konuğu segmentlemeye zorlar ve hasarlı offload yolu tam orada ortaya çıkar. Arıza simetrik olmak zorunda değildir: giden trafik temizken gelen trafik düşebilir ya da tersi, bu yüzden kullanıcı oturum açabilir ve ardından ilk büyük yanıtta takılabilir. Aynı istemci başka bir ağ geçidi üzerinden çalıştığı için suç en yeni bileşene yıkılır.

Bu yüzden ağ geçidini tünelsiz test edin. Birkaç saniye sürecek kadar büyük bir LAN’dan WAN’a indirme yeterlidir ve sonraki karşılaştırmanın anlamlı olması için herhangi bir ayar değişikliğinden önce yapılmalıdır.

offload gerçekte ne vaat ediyor

virtio paravirtualdir: ana makine ve konuk işi paylaşır, ana makine sağlama toplamı ve segmentleme yeteneklerini duyurur ve konuğun başladığını bitirmesini bekler. Konuğun yığını bunu yapmazsa çerçeveler eksik sağlama toplamlarıyla çıkar ya da ana makine tarafından düşürülür. Emüle edilmiş E1000 daha basit ve daha yavaş bir model sunar; orada sorun pfSense’te tek bir değişiklik olmadan kaybolur. Yetenek pazarlığı her aygıt için ayrı yapılır, bu da bir konuğun aylarca çalışırken yeniden kurulan ikizinin ilk günde neden başarısız olduğunu açıklar.

Pazarlığı yapılan küme, içe aktardığınız yapılandırmaya değil, hypervisor sürümüne ve seçilen ağ kartı modeline bağlıdır.

Tek bir onay kutusu virtio’yu korur

pfSense arayüzünde Sistem, ardından Gelişmiş, ardından Ağ yolu Donanım sağlama toplamı offload’ını devre dışı bırak adlı bir onay kutusu içerir. İşaretlendiğinde konuk sağlama toplamlarını yazılımda hesaplar, bu da pfSense’in arkasındaki FreeBSD yığınının paravirtual bir aygıttan beklediğiyle örtüşür. Aynı sayfadaki iki ilgili seçenek donanım TCP segmentleme offload’ını ve donanım büyük alma offload’ını kapsar. El sıkışmalar başarılı ama büyük aktarımlar başarısız olduğunda bunlara başvurun.

Değişikliği yaparken ağ kartını virtio olarak bırakın. E1000’e geçmek VM’in tüm ömrü boyunca her pakette CPU yakar ve yapılandırma sorununu ana makineyi devralan herkesten gizler; bu, biraz daha yavaş ama öngörülebilir bir veri yolundan daha kötü bir takastır.

Az önce kabul ettiğiniz maliyeti ölçün

Yazılım sağlama toplamı işi konuğa taşır, bu yüzden hiçbir maliyeti olmadığını varsaymak yerine sonrasında throughput ölçün. Küçük bir VM’de ceza gerçektir ama sessiz bir kaybın aksine görünür ve kararlıdır. Değişiklikten önce ve sonra arayüz hata sayaçlarını ve konuğun çekirdek günlüğünü karşılaştırın. Köprüyü filtreleyen bir hypervisor farklı kanıtlara sahip ayrı bir arızadır ve hiçbir offload bayrağı onu iyileştirmez.

Her testte tek bir şey değiştirin ve menü yolunu, işaretlediğiniz kutuyu ve ölçtüğünüz sayıyı yazın. Bir sonraki yeniden kurulan konukla karşılaşan kişi üçünü de isteyecektir.

BSD tabanlı diğer güvenlik duvarları kendi arayüz ayarlarında eşdeğer denetim sunar, bu nedenle menü yolu uymasa bile gerekçe geçerlidir.

İlgili makaleler