IKEv2 istemcisine atanmış sanal IP'sinde ulaşmak

Ağ geçidinin, IKEv2 üzerinden kendisine bağlı bir dizüstü bilgisayara bağlantı başlatması ve bunun için o istemciye atanmış sanal adresi kullanması gerekir. Tünel ayakta, istemci ağ geçidinin arkasındaki her şeye ulaşıyor, ancak ters yön hâlâ başarısız oluyor. Bu asimetri normaldir: anlaşılan politika hangi adreslerin konuşabileceğini tanımlar, hangi tarafın başlatabileceğini değil. Ağ geçidinden başlatılan bir isteğin çalışması için üç şeyin uyuşması gerekir.

Tünel kaynak adresini düzeltmez

Bir CHILD SA, her iki taraf için birer tane olmak üzere bir çift trafik seçiciyi kapsar ve bu çiftin her iki yönünde trafiğe izin verir. IKE alışverişini hangi eşin önce açtığı hakkında hiçbir şey söylemez. Başlangıçta tüneli dinleyen bir ağ geçidi, seçilen kaynak ve hedef kurulu seçicilerin içinde kaldığı sürece ilk uygulama paketini yine de gönderebilir. İstek yanlış arayüzden çıktığında, tünel için uygun değildir.

İstemciye doğru yönlendirme gereklidir ve yeterli değildir. Politika, gerçekte kullandığınız kaynağı kabul etmelidir.

Kurulu politikayı okuyun, yapılandırma dosyasını değil

Etkin ilişkilendirme ve seçicileriyle başlayın, çünkü dinamik atama çekirdeğe kurulanı değiştirir.

ipsec statusall
ip xfrm policy

Durum çıktısı bağlantının adını, atanmış sanal adresi ve o eş için hâlihazırda geçerli seçicileri belirtir. Politika dökümü aynı seçicileri çekirdek durumu olarak gösterir ve paket seçimi gerçekte ona başvurur. Ağ geçidi tarafındaki seçiciyi uygulamanızın kullanacağı kaynakla karşılaştırın, çünkü uyuşmazlık hatayı hemen açıklar. İstemcinin güncel adresini okuyun, önceki oturumdan kalanı değil, çünkü yeniden atanan VIP eski politikayı geçersiz kılar.

İstemci paketin vardığı yerde dinlemelidir

Kusursuz bir politika bile hizmet yalnızca loopback'e bağlandığında kapalı bir porta ulaşır. Dinleyici atanmış adreste veya yerel bir joker adreste olmalıdır.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Soket listesi portun sanal adrese bağlı olup olmadığını, güvenlik duvarı kuralları da korunan kaynaktan yeni bağlantıların kabul edilip edilmediğini gösterir. Kurulmuş bağlantılar için yazılmış bir kural, ağ geçidinin başlattığı bir bağlantıya izin vermez. Hizmetin kendi kimlik doğrulamasını koruyun, çünkü tünelden gelmek yalnızca paketin hangi ağdan geldiğini belirler. Kendi NAT'ının arkasındaki bir istemci yine gelen port yönlendirmesine ihtiyaç duymaz, çünkü bu istekler mevcut tünelin içinde yol alır.

Yeni yönü tek başına test edin

İstemciden sunucuya çalışan bir istek bu yolu hiçbir zaman denemez. İsteği ağ geçidinden oluşturun ve iki ucu da gözlemleyin.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Rota araması ağ geçidinin hangi kaynağı ve arayüzü kullanacağını yanıtlar ve politikanın kabul etmesi gereken değer budur. Yakalama, isteğin genel arayüzde düz TCP olarak değil ESP içinde çıktığını göstermelidir. İstemcide, varışı ve hizmetin yanıt verip vermediğini doğrulamak için şifresi çözülmüş trafiği yakalayın. İstek hatta ESP olmadan kaybolursa, istemcinin güvenlik duvarından önce kaynak adresten şüphelenin.

Anahtar değişiminden veya yeniden bağlanmadan sonra testi yineleyin, çünkü VIP değişebilir. Yalnızca bir sonraki oturuma kadar çalışan bir yol, çalışan bir yol değildir.