OpenVPN UDP tüneli içinde TCP üzerinden NFS: iki taşıyıcı
Bağlama protokolü ile tünel protokolü ayrı ayarlardır. İkisini de kaydedin, sonra takılmanın dosya hizmetine mi yoksa taşıyıcıya mı ait olduğuna karar verin.
UDP taşıyan bir tünelin içinde TCP kullanan bir NFS konuşmasını taşımak tamamen tutarlıdır ve insanları şaşırtır çünkü aynı anda iki taşıyıcıyı adlandırır. TCP, istemci ile NFS sunucusu arasındaki dosya hizmeti konuşmasıdır. UDP, VPN uç noktaları arasındaki şifreli taşıyıcıdır. Hiçbiri diğeri hakkında bir şey ima etmez.
Herhangi bir şeyi ayıklamaya başlamadan önce ikisini ayrı ayrı yazın; bu olayların çoğu birinin yanlış katmanı değiştirmesiyle başlar.
İki katman, iki ayar
Bağlama seçeneği proto=tcp, NFS istemcisinin NFS sunucusuyla nasıl konuştuğunu açıklar. VPN profilindeki proto udp ayarı, tünel uç noktalarının kapsüllenmiş paketleri nasıl değiştirdiğini açıklar. Bir bağlama seçeneğini değiştirmek tüneli değiştirmez ve tünelin taşıyıcısını değiştirmek NFS istemcisinin üzerinde anlaştığını değiştirmez. Etkin bağlama seçeneklerini fstab satırı yerine nfsstat -m ile doğrulayın ve VPN taşıyıcısını gerçekten kullanılan profilden doğrulayın.
Sonra bunları olay notlarında iki ayrı alan olarak kaydedin. Görünürdeki bir iyileşme ancak not hangi katmanın değiştiğini söylüyorsa izlenebilir.
Gözatmak toplu okuma değildir
Bir dizin listesi bazı işlemlerin tamamlandığını kanıtlar. Sürekli bir okumanın, bir yazmanın, bir kilidin veya depolama arka ucunun aynı koşullarda tamamlanacağını kanıtlamaz. Büyük bir dosyanın ortasında takılma, hiç başarılı olmayan bir bağlamadan farklı bir gözlemdir ve farklı katmanlara işaret ederler.
Başarısız olan işlemi tam olarak tanımlayın: yol, yön, takılmanın yaklaşık noktası ve istemci, sunucu ile VPN günlüklerindeki son ilgili olay. Ardından trafiğin nerede sürdüğünü ve nerede durduğunu karşılaştırın.
MTU bir hipotezdir, tanı değil
Paket boyutuna bağlı kayıp, tünel büyük segmentler taşıdığında gerçek bir olasılıktır ve tam olarak gözatmanın çalışıp okumanın takıldığı örüntüyü üretir. Ancak bu örüntü bir MTU sorununu kanıtlamaz, çünkü sunucu yavaşken, bir güvenlik duvarı uzun süreli bağlantıyı zaman aşımıyla kapatırken veya disk meşgulken de aynı biçim ortaya çıkar. Hipotezi her yerde MTU düşürüp zafer ilan etmek yerine kontrollü bir denemeyle sınayın.
Tek başına bir zaman aşımı, UDP'nin değiştirilmesi gerekip gerekmediği konusunda hiçbir şey söylemez. Birden çok olası sahibi olan bir belirtidir.
Her seferinde bir değişken değiştirin
Taşıyıcıları karşılaştırırken NFS iş yükünü ve diğer tüm ayarları sabit tutun. Bağlama taşıyıcısını, tünel protokolünü ve MTU'yu aynı bakım penceresinde değiştirmek kimsenin ilişkilendiremeyeceği bir sonuç verir. Aynı dosya işlemini önce ve sonra çalıştırın ve her adımda sonucu kaydedin.
Önceki değerleri de kayıtta saklayın. Bir değişiklik durumu kötüleştirirse geri dönüş, birinin eskiden nasıl olduğuna dair hatırası değil belgelenmiş bir sayı olmalıdır.
Başarısız olan katmanı okuyun
Tünel ayaktaysa ve NFS isteği bekliyorsa VPN başarısız olmadı; dosya hizmeti başarısız oldu. Tünel düştüyse NFS isteğinin başarısızlığı bir sonuçtur, neden değil. İki katmanın günlük satırlarını eşleştirmek bu iki durumu ayırmanın en hızlı yoludur ve dosya yöneticisinden tahmin etmekten daha iyidir.
Sonucu iki cümle olarak yazın, her katman için bir tane. Bu, bir sonraki kişinin hangi taşıyıcının hangisi olduğunu yeniden türetmeden testi yinelemesi için yeterlidir.