strongSwan ile çift yığınlı IKEv2 özel erişim planlaması

Çift yığınlı bir tünel tek bir karar değil üçtür ve bunlara farklı yanıtlar verilebilir. Dış tünelin hangi aile üzerinden geçtiği, istemcinin içeride hangi aileleri aldığı ve korunan hizmetlerin gerçekte hangi ailelerde yanıt verdiği. Bunları tek bir seçim olarak ele alan bir tasarım ya hiç gerek olmayan IPv6 taşır ya da hiçbir şeyin geri yönlendiremeyeceği adresler dağıtır. Üçünü ayırın, yapılandırmanın geri kalanı neredeyse mekanik hale gelir.

Üç tür adres, ayrı ayrı kararlaştırıldı

Dış adres iki ağ geçidinin birbirine nasıl ulaştığıdır ve iç trafik her iki aileyi taşırken IPv4 olabilir. İç sanal adres istemcinin tünel içindeki kimliğidir ve her ailenin kendi havuzuna ihtiyacı vardır. Korunan önekler istemcinin ulaşabileceği şeylerdir ve tünele değil hizmetlere aittir. Üçüncüyü ikinciyle karıştırmak planlama hatalarının çoğuna neden olur, çünkü ikisi de özel aralık gibi görünür.

Yalnızca IPv4 dış taşıma ile çift yığınlı iç trafik normal ve iyi desteklenen bir düzenlemedir.

Her birini açıkça kararlaştırın ve kararları yazın. Dış yol yalnızca IPv4 ise bunu söyleyin ve IPv6 uç noktalarının erişilebilirliği konusunda endişelenmeyi bırakın. Bir aile içeride atanıyor ama üzerinde hiçbir şey yanıt vermiyorsa ya onu plandan çıkarın ya da o hizmetleri gerçekten çift yığınlı yapın.

Her ailede bir sanal adres ayırın

swanctl yapılandırmasında istemci sanal adres ister ve her ailedeki joker karakter yanıtlayıcıdan her birinden bir tane ayırmasını ister. Yanıtlayıcı bunları havuzlardan alır ve havuzlar ağ geçidinin arkasındaki ağlardan ayrı nesnelerdir. Planda da ayrı tutun, çünkü bir hizmet önekiyle örtüşen havuz, trafik istenmeyen bir yere inene kadar doğru görünen yönlendirme üretir.

Her ikisine ihtiyaç duyduğunuzda iki aileyi, duymadığınızda birini isteyin, çünkü kullanılmayan adres faydası olmayan politika yüzeyidir. Belirli bir istek rezervasyon değil istektir ve yanıtlayıcı kendi politikasına göre başka bir değer döndürebilir. Bu ayrıntı, bir adresin güvenlik duvarı kuralına veya izleme denetimine sabit kodlandığı her yerde önemlidir. Bağlantıda havuzlara adlarıyla atıfta bulunun ve hizmet ağlarını onların dışında tutun.

vips = 0.0.0.0, ::

Kısa bir örnek değeri benimsemek yerine IPv6 havuzu için kendi benzersiz yerel önekinizi oluşturun. Örnek, ayarın biçimini gösterir, devralınacak varsayılan bir değeri değil.

Hedefleri havuzlardan ayrı tanımlayın

Trafik seçicileri her tarafın neyi değiş tokuş etmeyi beklediğini tanımlar, bu yüzden ağ geçidinin yerel seçicileri istemci havuzlarını değil korunan hizmet öneklerini adlandırmalıdır. İstemcinin uzak seçicileri bu niyeti yansıtır. İki liste farklı nesneleri tanımladığında tünel yükselebilir ve yine de yararlı bir şey taşımaz.

Aynı önekler, etkinleştirdiğiniz her aile için ağ geçidinin ağı içinde dönüş yollarına ve izin verilen yönlendirmeye ihtiyaç duyar.

Özel bir IPv6 planının yeterli olmayı bıraktığı yer burasıdır. Benzersiz yerel adresleme özel erişilebilirlik satın alır ve genel IPv6 çıkışı yaratmaz, bu yüzden numarasız ailenin basitçe IPv4 maskeleme kurallarını izleyeceğini varsayan bir tasarım kullanıcılarını hayal kırıklığına uğratacaktır. Genel IPv6 erişimi gereksinimin bir parçasıysa yönlendirilmiş bir plana ve bunu kabul eden bir üst akışa ihtiyaç duyar. Aksi takdirde IPv6 tarafının yalnızca özel olduğunu açıkça söyleyin; bu gizlenecek bir kısıtlama değil dürüst bir sınırdır.

DNS ve dönüş yollarını bilinçli hale getirin

Ad çözümlemesi taşımayı izlemez. Bir çözümleyici yalnızca IPv4 tünelli bir tünel üzerinden A ve AAAA kayıtlarını döndürebilir ve istemci o zaman hiç planlamadığınız bir aileyi dener. Hangi hizmet adlarının kullanılabilir çift yığınlı yanıtlar taşıması gerektiğine karar verin ve bu iki yolu bilinçli hale getirin. Çalışan bir yolu olmayan bir aileye çözülen ad, temiz bir hata yerine duraklama üretir ve duraklamaların teşhisi çok daha zordur.

Dış uç noktanın erişilebilirliğini ayrıca belgeleyin; herhangi bir NAT geçişinin işin içinde olup olmadığını ve hangi aileyi kullandığını da ekleyin.

Sonra planı altı satırda yazın: dış uç nokta, IPv4 havuzu, IPv6 havuzu, IPv4 hizmet öneki, IPv6 hizmet öneki ve her biri için yanıtları elinde tutan yönlendirici. Bu biçimdeki bir plan, bir operatörün gece üçte gerçekten sorduğu soruları yanıtlar. Daha kısa her şey çift yığını yalnızca IPv4 politikasına cıvatalanmış ikinci bir adres olarak bırakır ve genellikle yarı çalışır durumda biter.