strongSwan'da tam tünel her iki tarafta 0.0.0.0/0 gerektirir

Tam tünel, istemcinin remote_ts ve ağ geçidinin local_ts değeri olarak 0.0.0.0/0'a, ayrıca yönlendirmeye, NAT'a ve dönüş yoluna ihtiyaç duyar. Dördünü de denetleyin.

Tek bir özel alt ağ için çalışan bir strongSwan bağlantısı, birisi tek bir satırı düzenledi diye internet trafiğini taşımaz. Tam tünel, child SA'nın hangi adresleri koruduğuna dair iki taraf arasındaki bir anlaşmadır ve her taraf diğerini kendine göre adlandırır. Bir tarafı doğru, diğerini yanlış yapın; child SA ya kalkmaz ya da amaçlanandan daha dar kalkar. Aşağıdaki beş denetim bu anlaşmayı istemciden ağ geçidine ve oradan internete kadar izler.

Önce istemcinin seçicisini denetleyin

İstemci, uzak tarafta neyi korumak istediğini remote_ts olarak tanımlar ve gönderdiği her şey kendi atanmış adresinden çıkar. İnternet trafiği için bu değer, kullanıcının gerçekten ulaşacağı hedefleri kapsamalıdır; bu da pratikte tüm IPv4 uzayı anlamına gelir. Hâlâ tek bir alt ağ listeleyen istemci, arayüzde profil ne adla geçerse geçsin bölünmüş tünel istiyor demektir. Kaynak tarafı genellikle dynamic olur çünkü adres bağlantı sırasında atanır. Oraya yazılmış sabit bir kaynak, adres havuzu değişir değişmez bozulur.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Bu parça tam bir bağlantı dosyası değildir ve kimlik doğrulama, kimlikler ve sanal adres havuzunun zaten yapılandırıldığını varsayar. İstemcinin kaynak seçicisi ile sunucunun atadığı adres hâlâ eşleşmelidir, yoksa child SA iki tarafın da beklemediği bir kapsamla kalkar. swanctl --load-all ile yükleyin ve başarı varsaymadan önce çıktıyı okuyun. Ayrıştırılan bir dosya, diğer tarafın önerisiyle örtüşmeyen bir seçici yüzünden yine de reddedilebilir.

Ağ geçidinin seçicisini kendi tarafında denetleyin

Ağ geçidi aynı kavramı ters yönden okur. İnternet hedefleri ağ geçidi için yereldir, bu yüzden onun local_ts geniş olanıdır ve remote_ts istemci havuzunu tanımlar. Bu tersine dönme, tam tünel yapılandırmasındaki en yaygın hatadır ve iki satır tek başına makul göründüğü için incelemeden geçer.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

İstemci parçasını ağ geçidinin dosyasına kopyalamak, her iki taraf da aynı rolü talep edeceği için yararlı hiçbir şey tanımlamayan bir seçici çifti üretir. strongSwan yönlendirme kılavuzu istemci ve ağ geçidi eşleşmesini açıkça belgeler ve hatadan sonra değil, bağlantı dosyasının yanında okunmaya değer. Ağ geçidi dosyası ayrıca remote_ts'nin başvurduğu havuz tanımına ihtiyaç duyar. Var olmayan bir havuz adlandıran seçici şikâyetsiz yüklenir ve bağlanırken başarısız olur.

Eski ipsec.conf farklı anahtarlarla sol ve sağ rolleri kullanır ve rightsubnet satırı swanctl değerinin doğrudan yerine geçmez. İki sözdizimini birini diğerine yapıştırmak yerine ayrı dosyalarda tutun. İkisini tek bir dizinde karıştırmak, çalışan bir bağlantının yeniden başlatmadan sonra sessizce geri düşme biçimidir.

Dosyayı değil, görüşülen child SA'yı denetleyin

Kaydedilmiş bir yapılandırma niyeti kanıtlar ve başka bir şeyi değil. Karşı taraf isteneni daraltabilir ve var olan bir child SA yalnızca altındaki dosya değişti diye değiştirilmez. Başka bir şeyi değiştirmeden önce gerçekte neyin kurulu olduğunu doğrulayın.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

İlk komut daemon'ın neyi yüklediğini, ikincisi kurulan child SA'ları, üçüncüsü çekirdeğin uygulayacağı politikaları gösterir. Dosya 0.0.0.0/0 diyor ve liste tek bir alt ağ gösteriyorsa, görüşme kapsamı daraltmıştır ve dosyayı yeniden okumak bunu açıklamaz. child'ı sonlandırın, yeniden başlatın ve üç çıktıyı yeniden karşılaştırın. Aynı dar kapsamla dönen child, yerel dosya tarafından değil uzak taraf tarafından daraltılıyordur ve bu yerel bir düzenleme değil, diğer yöneticiyle bir konuşmadır.

Politika listesinde iki yönü de okuyun, çünkü bir yönü kurup diğerini kurmayan tünel, yapılandırma kılığında bir yönlendirme sorunudur. İleri ve geri politikalar aynı seçici çiftini ayna görüntüsünde adlandırmalıdır ve eksik ayna seçici metninde değil, daemon'da veya öneride bir kusurdur.

Yönlendirmeyi ve dönüş yolunu denetleyin

Bir seçici trafiği ağ geçidine kabul eder, ancak ağ geçidini o trafiği ileriye yönlendirmeye zorlamaz. Yönlendirme etkin olmalı, güvenlik duvarı akışa izin vermeli ve yanıt istemci havuzuna dönüş yolunu bulmalıdır. Bunlar üç ayrı gereksinimdir ve her biri farklı bir belirtiyle başarısız olur. Eksik bir yönlendirme kuralı kara delik gibi davranırken, eksik bir dönüş yolu tek yönlü tünel gibi davranır.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Özel istemci adresleri genellikle genel bir arayüzden çıkmadan önce bilinçli kaynak çevirisine ihtiyaç duyar, açıkça yönlendirilmiş bir tahsis ise farklı bir işlem gerektirir. NAT işin içindeyse, bir güvenlik politikasının denetlemesi gereken trafiğin onu atlayarak çevrilmemesi için uygulamanın desteklediği istisnaları koruyun. Başka bir ağ geçidinden kopyalanmış geniş bir masquerade kuralı, yazarının amaçladığından çok daha fazla akışı değiştirir. Kuralı yalnızca istemci havuzu için yazın ve neden var olduğunu açıklayan bir yorum bırakın.

İstemcide, varsaydığınız yolları değil backend'in kurduğu yolları doğrulayın. Yol kurulumu devre dışı bir yönetici, elle sürdürülen bir yönlendirme tasarımına ihtiyaç duyar ve bu tasarım tünel her değiştiğinde güncellenmelidir. Yönlendirme tablosunu yeniden bağlandıktan sonra denetleyin, yalnızca yeni bir açılıştan sonra değil.

Tünelin hâlâ neleri kapsamadığını denetleyin

Seçici çifti IPv4'ü kapsar ve başka hiçbir şeyi. IPv6, DNS ve uygulama düzeyindeki her politika ayrı kararlardır ve geniş bir IPv4 seçici bunları sessizce yok sayar. Her IPv4 paketini taşıyan bir tünel bile her ad aramasını sızdırabilir.

Amaçlanan DNS yolunu açıkça belirtin, çünkü adları hâlâ yerel çözümleyici üzerinden çözen tam tünel, sorguları tünelin dışına sızdırır ve özel adları bozar. İstemciye IPv6 adresi atanırsa bu adres ailesi de aynı işleme ihtiyaç duyar, yoksa ana makine tünelin korumadığı bir yolu tercih eder. Yalnızca özel tarafın yanıtlayabildiği bir adla test edin ve genel bir yanıtı sızıntı olarak değerlendirin.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Zinciri bu iki komut ve yukarıdaki listeden görüşülen seçicilerle doğrulayın. traceroute yerel yönlendiriciyi ilk atlama olarak gösteriyorsa seçiciler ne iddia ederse etsin trafik tüneli kullanmıyordur. İnternet erişimi ancak seçilen trafik tasarlanan ağ geçidinden kabul edilip yönlendirilip geri getirildiğinde tamamdır. Bir profilde 0.0.0.0/0 bulmak o zincirin kanıtı değil, başlangıcıdır.

İlgili makaleler