IPsec içinde IPsec: dış tünel hangi adresleri taşımalı

İç içe IPsec, iki katman farklı makinelerde sonlandığında akılda canlandırması daha kolaydır. Dört ağ geçidi, iki tünel ve tasarımın çalışıp çalışmadığını belirleyen tek bir soru: iç tünel paketle işini bitirdiğinde dış tünel gerçekte ne görür? Buna cevap verin, seçiciler, rotalar ve sorun giderme sırası kendiliğinden gelir. Yanılırsanız teknik olarak ayakta duran bir tüneli hata ayıklayarak bir gün geçirirsiniz.

Dört ağ geçidi modeli

Dış ağ geçitleri A ve B iki saha arasındaki ilk tüneli kurar. A'nın arkasında geçiş adresi 10.60.0.2 olan iç ağ geçidi C, B'nin arkasında geçiş adresi 10.70.0.2 olan iç ağ geçidi D bulunur. Uygulama ağları C ve D'nin arkasında yaşar ve örnekteki her adres kasıtlı olarak çakışmaz.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Katmanları dört ana makineye bölmek, her makinenin bir sınır uygulaması demektir. İki katmanı tek bir ana makinede çalıştırmak, iki politika kümesini, iki yönlendirme tablosunu ve iki arıza modunu tek makinede bağdaştırmayı gerektirir; bu mümkündür ve gözlemlenmesi çok daha zordur.

Her katman yalnızca kendi korumasını kaldırır

C, D için bir uygulama paketini şifreler. Sonuç C'den D'ye adreslenir ve A'ya ulaşan da budur. Aşağıdaki her şey bu yeniden yazmaya bağlıdır.

A onu B için tekrar şifreler. B dış katmanın şifresini çözer, C'den D'ye giden bir paket görür ve onu hâlâ şifreli olarak iletir. D iç korumayı kaldırır ve uygulama paketini teslim eder.

Yani A ve B iç uç noktaları ve üst verilerini görür, ancak uygulama yükünün şifresini çözen taraflar değildir. Bu tasarımın gerçek bir özelliğidir; C, D veya uygulama ana makinelerinin güvenilir olduğu iddiası değildir.

Dış seçiciler iç ağ geçitlerini adlandırır

Bu tür yapıların çoğu burada başarısız olur. Politika tabanlı bir dış tünel için müzakere ettiğiniz seçiciler, A ve B'nin gerçekte işlediği adresleri içermelidir: 10.60.0.2/32 ve 10.70.0.2/32, doğru yerel ve uzak sırayla.

Nihai uygulama alt ağlarını dış seçicilere koymak işe yaramaz, çünkü bir paket A'ya ulaştığında iç kapsülleme A'nın koruması gerekeni çoktan yeniden yazmıştır. O zaman dış politika hiçbir şeyle eşleşmez ve tünel veri taşımadan ayaklanır.

Dış izni UDP 500'e daraltmayın. İç bağlantının kendi veri yolu vardır; müzakere edilene göre ESP veya UDP kapsülleme kullanır ve dış politika bu protokole izin vermelidir.

Sonucu her ağ geçidinde swanctl --list-sas ile kontrol edin ve alt güvenlik birliklerinin amaçladığınız adresleri bildirdiğini, varsaydıklarınızı değil, doğrulayın. Liste uygulama alt ağlarını gösteriyorsa dış politika yanlış katman için yazılmıştır. Yönlendirmede hata ayıklamadan önce seçicileri düzeltin, çünkü yönlendirme doğru görünecek ve sayaçlar hareket etmeyecektir.

İletim ve özyineleme tuzağı

Seçiciler yönlendirmenin yerini almaz. A ve B, C ile D arasındaki trafiği iki yönde iletmelidir; bu, etkin IP iletimi, tünele işaret eden rotalar ve karşı tarafta var olan bir dönüş yolu anlamına gelir.

Dış tünel XFRM arayüzleri kullanıyorsa rotalar arayüzü seçerken müzakere edilen politikalar hâlâ ne taşıdığını sınırlar. Bir arayüz korunan alanı genişletmez; yalnızca çekirdeğin paketi nasıl aldığını değiştirir.

Tuzak özyinelemedir. A'nın B'nin dış uç noktasına rotası, A'nın kurduğu tüneli değil alt katmanı izlemelidir; aksi hâlde kapsülleme kendi içinde yolculuk etmeye çalışır ve bağlantı asla tamamlanmaz.

Katman eklemeden önce çeviriyi inceleyin

Başka bir şeyi ayarlamadan önce A ve B'deki her kaynak NAT'a bakın. IPsec politikası uygulanmadan önce C'nin adresini yeniden yazan bir kural, anlaşılan seçicileri bozabilir ve D'nin karşı tarafta ne aldığını da değiştirebilir.

Geniş maskeleme iki katman olduğu için daha güvenli olmaz. Uzak tarafın hangi adresi gördüğünü saklar ve tünel ayaktayken uygulama çalışmadığında tam olarak bu bilgiye ihtiyacınız olur.

NAT kuralı gerçekten gerekliyse, her tarafın hangi adresle konuştuğunu sandığını yazın. O tek satır, suçun tünelde mi yoksa çeviride mi olduğuna dair tartışmaların çoğunu çözer. Ayrıca bir yıl sonra kural kaldırıldığında sıradaki mühendise nereye bakacağını söyler. Ping bunların hiçbirini yapmaz.

fail-closed'ı kanıtlayın ve MTU'yu kontrol edin

Bir rotanın kaybolması tek başına fail-closed politikası değildir. Başka bir tablo, varsayılan rota veya politika kuralı sessizce yedek bir yol sağlayabilir ve bunu bilmenin tek yolu dış tüneli indirip uygulama trafiğinin ne yaptığını gözlemlemektir. Bunu kazara keşfetmek yerine bakım penceresinde bilerek yapın.

Üç durumu test edin: dış tünel kapalı, iç tünel kapalı ve ikisi de geri döndükten sonra toparlanma. Her ağ geçidinde politika sayaçlarını kullanın, çünkü kurulmuş iki IKE oturumu yalnızca kontrol düzlemi müzakeresinin başarılı olduğunu kanıtlar.

Her iki kapsüllemeyi de bütçeleyin. Çalışan IKE küçük paketlerin sonucudur ve tam boyutlu uygulama paketleri iki başlık eklendiğinde hâlâ başarısız olabilir; sayıların toplandığını varsaymak yerine gerçek yolda bilinen bir yük boyutuyla test edin. Aritmetik kolay, yol değil.