IPsec ağ geçidi için WireGuard profili: bunun yerine ne sorulmalı

Sessiz bir ağ geçidiyle el sıkışma zaman aşımları genellikle hiç karşılaşmayan iki protokol anlamına gelir. WireGuard eşi Noise konuşurken IPsec ağ geçidi IKE bekler. Doğru adres ve bağlantı noktası bunu değiştirmez.

Bir profilde uç noktayı yeniden kullanmak ikisini birbirine bağlamaz. Sonraki adım, ağ geçidini işleten kişiye bir taleptir.

Birinci talep: protokol sürümü

IPsec tek bir iş akışı değil, bir aile adlandırır. IKEv2 ve IKEv1, alışverişleri, kimlik doğrulama seçenekleri ve ağ değiştiğinde davranışları bakımından farklıdır. Yalnızca IKEv1'i sonlandıran bir ağ geçidi, IKEv2 sunan bir ağ geçidinden çok farklı davranacaktır. İstemci yapılandırması da bununla birlikte değişir.

Hizmetin hangi sürümü sonlandırdığını ve standartlara dayalı bir uygulama mı yoksa kendi istemcisi olan bir satıcı varyantı mı çalıştırdığını sorun. İşletim sistemi menüleri bu yanıtı genellikle tek bir etiketin arkasına saklar. Etiket protokol değildir.

İkinci talep: istemcinin kimlik doğrulama yöntemi

Kimlik doğrulama, gerçek işin büyük bölümünün bulunduğu yerdir. Hizmet belirli bir genişletilmiş anahtar kullanımına sahip makine sertifikası, kullanıcı sertifikası, IKEv2 üzerinden bir EAP yöntemi veya bir kimliğe bağlı önceden paylaşılmış anahtar bekliyor olabilir. Hangisinin geçerli olduğu istemcinin neye ihtiyacı olduğunu belirler.

WireGuard özel anahtarı bunların hiçbiri değildir. Belirli bir el sıkışmada kullanılan bir Curve25519 anahtarıdır. Hiçbir dönüştürme onu sertifikaya veya EAP kimlik bilgisine çevirmez. Aksi iddia eden bir araç dosyayı yeniden adlandırıyor ya da ilgisiz bir şey üretiyordur.

RFC 7296'daki IKEv2 belirtimi o sürümün uygulamasının neleri desteklemesi gerektiğini açıklar. Bu, işletmecinin belirsiz yanıtı için bir başvuru kaynağıdır, istemci yapılandırma kılavuzu değildir.

Üçüncü talep: güvenilir kimlik ve hedefler

Ağ geçidinin kimliğini istemcinin görmesi gerektiği biçimde ve onu doğrulayan güven çıpasıyla birlikte sorun. Ardından hizmetin hangi özel aralıkları ve çözümleyicileri ittiğini sorun. Bu iki yanıt tünelin gerçekte ne taşıdığını belirler.

Bunlar olmadan çalışan bir bağlantı yine de görevi başaramayabilir. İtilmiş bir çözümleyici olmadan ayakta duran tünel iç adları yanıtsız bırakır. Eksik bir trafik seçici, el sıkışma başarılı olsa bile hedefi tünelin dışında bırakır.

Uç nokta yoklaması istemci hatasından farklı bir soruyu yanıtlar. İlişkilendirme olmadan erişilebilen bağlantı noktası kimlik doğrulamaya, erişilemeyen bağlantı noktası ise yola işaret eder.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

İstemcide herhangi bir şeyi değiştirmeden önce bu yoklamayı çalıştırın. Bağlantı noktaları yanıt verip ilişkilendirme hâlâ başarısız oluyorsa sorun kimlik bilgilerindedir ya da politikadadır. Hiç yanıt vermiyorlarsa hiçbir profil düzenlemesi yardımcı olmaz.

İki protokol bir arada var olmak zorunda olduğunda

Her iki ağı da yönetmek, iki protokolü de tutmak için geçerli bir nedendir. Olağan tasarım WireGuard ve IPsec'i ayrı arabirimlerde veya ayrı ağ geçitlerinde sonlandırır. Onaylanan trafik daha sonra aralarında yönlendirilir.

Bu tasarım bir güven ve yetkilendirme sınırı getirir ve bu şekilde kayda geçirilmelidir. Hangi eşlerin geçebileceği, hangi yönde ve kimin politikası altında olduğu bir yönlendirme ve güvenlik duvarı kararıdır. İki protokolden hiçbiri bunu sağlamaz.

Olmadığı şey şeffaf bir dönüşümdür. WireGuard üzerinden gelen trafik IPsec tünelinde yeniden oluşturulur ve aradaki her politika ona uygulanır.

Önce sunucunun protokol ve kimlik doğrulama gereksinimlerini netleştirin. Sonra işletmecinin desteklediği istemciyi ve kayıt yolunu kullanın ve bu olurken özel anahtarları web dönüştürücülerinden uzak tutun.