Bir IPsec güvenlik ilkesi neden yönlendirme tablosunda bir kayıt değildir

Tünelden 10.20.0.5'e ping atın ve hiçbir şey geri dönmüyor, oysa yönlendirme tablosu o alt ağın erişilebilir olduğunda ısrar ediyor. Yönlendirme ve IPsec farklı soruları yanıtlar ve yalnızca biri erişilebilirlikle ilgilidir. İleri arama bir yol seçer, ardından güvenlik ilkesi veritabanı bu yolun korunması, olduğu gibi bırakılması mı yoksa reddedilmesi mi gerektiğine karar verir. İkisi anlaşmazlığa düştüğünde paket sessizce ölür, bu yüzden onları bu sırayla okuyun.

Tabloyla değil, aramayla başlayın

Çekirdeğe gerçekte ne yapacağını sorun: ip route get 10.20.0.5 seçilen rotayı, giden arayüzü ve kullanacağı kaynak adresi yazdırır. Bir önek, bir ilke kuralı, bir işaret veya tercih edilen bir kaynak bu yanıtı değiştirebilir, bu yüzden canlı arama tabloyu gözle okumaktan üstündür.

Korunan aralığın içindeki bir hedefi test edin, ağ geçidi adresini değil. Karşı taraftaki ağ geçidine ulaşmak yalnızca bir rotanın var olduğunu kanıtlar; gerçekten ihtiyaç duyduğunuz alt ağ hakkında hiçbir şey söylemez. Ardından aramanın seçtiği arayüzün tünelin kullanmasını beklediğiniz arayüz olduğunu doğrulayın.

Seçicileri iki tarafta eşleştirin

İlke veritabanının kendi kayıtları vardır ve her biri bir yön, kaynak, hedef ve protokol belirtir, ardından eşleşen paketlere ne olması gerektiğini söyler. Bunları listelemek için ip xfrm policy kullanın; bayraklar eylemin koruma, atlama veya engelleme olduğunu gösterir. Seçicileri test akışınızdan daha geniş veya daha dar olan bir ilke onunla eşleşmez ve paket korumasız çıkar. Aradığınız arıza bu, eksik bir rota değil.

Gerçek değerleri karşılaştırın: kaynak, hedef, protokol ve bağlantı noktaları. Arama bir adres çiftini çözdüyse ama ilke kaydı başka bir çifti kapsıyorsa, iki görünüm farklı trafiği anlatır. Sonuca varmadan önce ikisini de aynı demetle yeniden çalıştırın, yoksa hiç yolda olmamış bir ilkeyi düzenlersiniz.

İlke eşleşmesi kurulu durum değildir

Eşleşen bir ilke yalnızca paketin korunması gerektiğini söyler; korumayı yapmak için çekirdeğin hâlâ bir güvenlik ilişkilendirmesine ihtiyacı vardır. Bunları ip xfrm state ile veya strongSwan görüşmeleri yürüttüğünde swanctl --list-sas ile listeleyin ve her kayıttaki seçicileri ve sayaçları okuyun.

Bir ilke eşleştiğinde ve hiçbir ilişkilendirme aynı seçicileri kapsamadığında, paket açık metin olarak gönderilmek yerine düşürülür. Tünel ayaktayken tek bir alt ağ başarısız olduğunda aranacak düşürme budur. Sayaçlar gerisini söyler: hiç artmayan bir ilişkilendirme hiç seçilmemiştir, artıp yine de düşürmeyle biten ise uzak tarafı işaret eder. Seçicileri düzeltmek ile anahtarları yenilemek farklı onarımlardır, bu yüzden yapılandırmaya dokunmadan önce hangisine ihtiyacınız olduğuna karar verin.

Rota tabanlı bir tünelin hâlâ gerektirdiği şeyler

Bir XFRM arayüzü tüneli yönlendirme yapabileceğiniz bir aygıt gibi gösterir, bu gerçekten yararlıdır. Ancak paket oraya vardığında ne olacağına karar veren ilkeyi ve durumu ortadan kaldırmaz. Rota bir sonraki atlamayı ekler, daha fazlasını değil.

Aygıt varsa ve rota ona işaret ediyorsa ama hiçbir ilişkilendirme iç seçicilerle eşleşmiyorsa, paket atılır ve ne kadar rota düzenleseniz de anahtar veya seçici üretilmez. Arayüzü yönlendirdiğiniz aynı kaynak ve hedefle kontrol edin, sonra bunu durum listesiyle karşılaştırın.

Herhangi bir şeyi düzenlemeden önce sahipliği netleştirin

Ana makinenin güvenlik duvarı, iki veritabanının da bilmediği üçüncü bir karar ekler. Doğru rota artı eşleşen ilke artı kurulu ilişkilendirme yine de düşürülmüş bir paketle sonuçlanabilir ve uygulama yalnızca zaman aşımını bildirir. IPsec'i suçlamadan önce güvenlik duvarının korunan trafiğe izin verdiğini doğrulayın. Tünel aygıtında ve fiziksel arayüzde yakalama, paketin şifrelemenin hangi tarafında kaybolduğunu gösterir.

Yapılandırmanın sahipliği, düzeltmenizin yeniden başlatmadan sonra kalıp kalmayacağını belirler. Bir bileşen durumu kurarken bir diğeri rotaları yönetebilir ve ikincisinde elle yapılan değişiklik tünel bir dahaki sefere kalktığında üzerine yazılır. Sahip olan yapılandırmayı değiştirin, sonra iki görünümü yeniden okuyun; RFC 4301 bu ayrımı başka birine açıklamanız gerektiğinde iki veritabanını ayrı tutar.