Çift yığın VPN havuzları: strongSwan'da iki adres ailesini birden ele almak

İç IPv4 ve IPv6 havuzları, korunan önekler ve dış tünelin ailesi birbirinden ayrı üç karardır. Buna çift yığın demeden önce her birini planlayın.

Bir ağ geçidi gezici bir kullanıcıya hem IPv4 hem de IPv6 sanal adresi verebilir; dış tünel ise hâlâ IPv4 üzerinden gider. Bunlar bağımsız kararlardır ve onları tek karar gibi ele almak, çift yığın planlarının genellikle dağıldığı yerdir. İstemcinin iç aileleri, erişebileceği korunan önekler ve kapsüllemeyi taşıyan aktarım birbirinden ayrı üç seçimdir.

Karışıklığın çoğu, çift yığın sözcüğünün yalnızca tek bir yerde çift yığın olan bir tasarıma uygulanmasından kaynaklanır. Bir hizmet içeride çift yığın, dış adresinde tek yığın olabilir ve yine de istemciler için gayet iyi çalışabilir. Yapamayacağı şey, tesadüfen çalışmaktır.

İçeride iki aile, dışarıda tek yol

Dış bağlantı UDP üzerinden IKE'dir ve istemci nerede olursa olsun oradan erişilebilen tek bir adres ailesine ihtiyaç duyar. İç IPv6 adresi IPv6 destekli bir sağlayıcı gerektirmez, çünkü iç paket dış paketin içindeki yüktür. Pek çok çalışan kurulum IPv6 öneklerini yalnızca IPv4 olan bir yukarı bağlantı üzerinden taşır.

Dış yolun gerçekten sınırladığı şey erişilebilirlik ve NAT geçişidir. Ağ geçidi yalnızca bir IPv4 adresi duyurursa, yalnızca IPv6 olan bir ağdaki istemci, hangi havuzları yapılandırmış olursanız olun hiç bağlanamaz. Dış aileyi istemci kitlenize göre belirleyin, iç adres planına göre değil.

İstemciye her ailede bir adres verin

İki aileyi birden istemek istemci tarafında tek satırlık bir ifadedir; yeter ki ağ geçidinin dağıtacak bir şeyi olsun. Adlandırılmış havuzlar kaynakları hizmet ağlarından ayrı tutar ve güvenlik duvarı kurallarını altı ay sonra da okunabilir kılan özellik budur.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Değer vips her aileden bir adres ister ve havuz listesi bu adreslerin nereden geldiğini belirler.strongSwan'ın sanal IP belgeleri birden çok isteği ve havuz atamasını kapsar; belirli bir adres isteyen istemcinin yalnızca yanıtlayanın geçersiz kılabileceği bir tercih belirttiği noktası da buna dahildir. İstemcinin her zaman aynı değeri aldığını varsayan bir erişim kuralı kurmayın.

Örneği kopyalamak yerine kendi benzersiz yerel önekinizi üretin. Her ikisini de fd42::/16 uygulayan iki kuruluş, ilk kez birbirine bağlandıklarında çakışmayı keşfeder ve bunu teşhis etmek hoş değildir.

Seçiciler hedefleri tanımlar, kaynakları değil

Alt SA'nın yerel trafik seçicileri ağ geçidinin arkasında hangi korunan ağların olduğunu söyler, uzak seçiciler ise istemcinin kaynak olarak neyi kullanabileceğini tanımlar. Sanal havuz adresi o politikanın kaynak tarafına aittir; onu hedef listesine koymak yapılandırmanın yaygın bir yanlış okunmasıdır.

Her iki aile de ağ geçidinde dönüş yollarına ve izin verilen yönlendirmeye ihtiyaç duyar. Havuza geri dönüş yolu olmadan bir seçiciye önek eklemek, kurulan, trafiğin tek yönünü geçiren ve yanıtı sessizce düşüren bir tünel üretir. Seçici politikadır, yönlendirme değil.

Havuzları ve hizmet öneklerini adres planınızın ayrı bloklarında tutun. Üst üste bindiklerinde, korunan bir ana bilgisayara ulaşması gereken bir yol bir havuz adresiyle eşleşip tünelin içinde kaybolabilir.

DNS ve yanıt yolu, bunun bitmiş hissettirip hissettirmediğine karar verir

Çözümleyici yanıtları, çözümleyiciye ulaşmak için kullanılan aktarımdan bağımsızdır. Bir ad A kaydı, AAAA kaydı veya ikisini birden döndürebilir ve istemci kendi tercih kurallarına göre seçer. Bir iç hizmet AAAA kaydı yayımlıyor ama o öneki hiçbir şey yönlendirmiyorsa, çift yığın ağlardaki istemciler önce IPv6 yolunu deneyecek ve başarısız olana kadar orada bekleyecektir. Bu olurken tünel yapılandırmasında hiçbir şey yanlış görünmez.

Bu yüzden her ad için hangi ailelerin kullanılabilir olması gerektiğine karar verin, sonra ilgili önekin seçicide olduğunu ve bir dönüş yolu bulunduğunu doğrulayın. Bu, hizmet başına bir karardır. İki kayıt türünü ayrım yapmadan yayımlamak, yalnızca IPv4 ile çalışan bir hizmetin kullanıcılarının yarısı için zaman aşımına uğramaya başlamasının yoludur.

Bitmiş demeden önce iki aileyi de doğrulayın

Yüklenen yapılandırma, çalışan yapılandırma değildir. Arka plan programının bildirdiği durumu okuyun, havuz atamalarını doğrulayın, sonra istemcinin gerçekte kurduğu yollara bakın.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

İlk iki komut kurulmuş alt SA'ları ve hangi havuzlarda hâlâ adres bulunduğunu gösterir; böylece ilk istemci için çalışıp onuncuda başarısız olan bir plan görünür hale gelir. Son iki komut, istemcinin havuzdan küresel bir IPv6 adresi alıp almadığını ve korunan bir öneke giden trafiğin gerçekte nereye varacağını gösterir. Atanan adresi yapılandırdığınız havuzla karşılaştırın, umduğunuz adresle değil. Yanıtlayan kendi politikası uyarınca başka bir değer seçtiyse, yollar ve güvenlik duvarı kuralları yine de onun seçimiyle uyuşmalıdır.

Sonra her aile için bir korunan ana bilgisayar ve her ikisine de çözülen bir ad test edin. Tek aileli bir test, alıştırma yapmadığınız plan yarısı hakkında size hiçbir şey söylemez ve eksik yol genellikle o yarıda bulunur.

İlgili makaleler