IKEv2 Android'de neden standart dışı bir UDP bağlantı noktasında başarısız olur

Yerel IKEv2 formu bir adres alır, bağlantı noktası almaz. İstemcinin bunu desteklediğini doğrulayın, sunucunun iki bağlantı noktasını ayarlayın, ardından çerçevelemeye ve günlüklere bakın.

Ağ geçidi IKEv2'ye UDP 4443 üzerinde bir nedenle yanıt veriyor, profilde Server adlı bir alan var, ana bilgisayar adını ve bağlantı noktasını yazıyorsunuz ve telefon sunucuya ulaşamadığını veya adresi çözümleyemediğini bildiriyor. Hiçbir şey engellenmiyor. Android'in yerel formu bir ana bilgisayar bekler ve aynısı Windows'ta da geçerlidir. Özel bir bağlantı noktası, sunucu ayarı olmadan önce istemci yeteneğidir ve bunu ifade etmenize yalnızca bazı istemciler izin verir. Üç bölümü sırayla inceleyin: istemci ne söyleyebilir, sunucu neyi dinliyor ve iki uç paketleri aynı şekilde mi çerçeveliyor.

Telefonun gerçekte gönderdiği

Ad için tasarlanmış bir alandaki host:port dizesi ad olarak çözümlenir. Çözümleyici vpn.example.net:4443 için hiçbir şey döndürmez ve gördüğünüz hata bağlantı noktasında zaman aşımı değil, ad çözümleme veya erişilemezlik hatasıdır. Bu ayrım önemlidir, çünkü daha kısa bir adla veya başka bir ağla yeniden denemek formun ayrıştıramadığı bir dizeyi asla düzeltmez.

Android'deki yerel IKEv2 profili, Windows'un yerleşik VPN istemcisi gibi standart IKE bağlantı noktalarına sabitlenmiştir. Hiçbiri bir bağlantı noktası alanı göstermez ve hiçbir profil düzenlemesi bir tane eklemez. Operatörün dinleyicisi gerçekten 4443 üzerindeyse, yerleşik istemci yanlış yapılandırılmış değil, yanlış araçtır.

Bağlantı noktasını gösteren bir istemci kullanın

strongSwan'ın Android istemcisi, gelişmiş profil ayarlarında yapılandırılabilir bir sunucu bağlantı noktası belgeler, bu nedenle bu tasarım için çalışan neredeyse her tarifte görünür. Bu destek o istemciye aittir: başka bir IKEv2 uygulaması veya aynı uygulamanın bir satıcı çatalı, alttaki strongSwan arka plan programı desteklese bile aynı alanı göstermeyebilir.

Operatörden tüm seti bir seferde isteyin: ağ geçidi adı, UDP bağlantı noktası, kimlik doğrulama yöntemi ve istemcinin beklemesi gereken sunucu kimliği. Özel bir bağlantı noktası, sertifika denetimini kapatmak veya protokolleri değiştirmek için bir neden değildir. Bağlantı noktasını kurulu istemcinin beklediği yere girin ve o istemcide böyle bir alan yoksa yanıt, tahmin edilmiş bir geçici çözüm değil, başka bir onaylı istemcidir.

Sunucunun iki bağlantı noktası vardır ve ikisi de eşleşmelidir

IKE UDP 500 üzerinde başlar ve NAT geçişi genellikle IKE ile kapsüllenmiş ESP'yi UDP 4500'e taşır. Bunlar strongSwan'da ayrı ayarlardır, bu yüzden tek bir özel bağlantı noktasına taşınan sunucu ikisini de aynı değere değiştirmelidir:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Tek bir bağlantı noktası iki rolü de üstlendiğinde, arka plan programı aynı sokette IKE'yi ESP-içinde-UDP'den ayırmalıdır; bunu IKE iletisinden önce gelen ve ESP olmayan dört baytlık işaretle yapar. Bu nedenle istemci özel bağlantı noktasında anlaşıp sonra sessizce 4500'de devam edemez ve bu nedenle “sadece bağlantı noktasını değiştir” ifadesi bir çerçeveleme gereksinimini gizler.

Yönlendirme bir dinleyici değildir

4443'ü sıradan bir IKE dinleyicisine yönlendirmek, neredeyse başarılı görünen arıza biçimidir. İlk değiş tokuş gelir, sunucu yanıtlar ve ardından bağlantı durur veya anahtarları hiçliğe yeniden üretir, çünkü yanıt başka bir bağlantı noktasından çıkar ve sonraki kapsüllenmiş trafik iki ucun oluşturduğu durumla asla eşleşmez. Dinleyiciyi taşımadan hedef bağlantı noktasını yeniden yazan bir kural tam olarak bu yarı açık sonucu verir.

Yol ayrıca UDP'ye uçtan uca izin vermelidir. TCP 443'ün bir otel veya operatör ağından geçmesi, aynı numarayla bile olsa UDP bağlantı noktasındaki IKEv2 hakkında hiçbir şey söylemez. Yalnızca TCP 443'e izin verilen yerlerde, özel bir UDP bağlantı noktası IKEv2'yi HTTPS yapmaz ve doğru yanıt bir başka bağlantı noktası denemesi değil, başka bir erişim yolu olabilir.

Test ederken üç aşamayı ayırın

İstemci bir kez denerken sunucuda yakalayın. Hiç gelmeyen istek bir uç nokta veya güvenlik duvarı sorunudur; yanıtsız gelen istek bir dinleyici veya ilke sorunudur; ardından sessizlik gelen yanıt ise çerçeveleme veya kimlik sorunudur.

tcpdump -ni eth0 -vv udp port 4443

Ardından istemcinin dönen göstergesini değil iletisini okuyun. Teklif hatası algoritmaların eşleşmediği anlamına gelir, kimlik doğrulama hatası kimliklerin veya sertifikaların eşleşmediği anlamına gelir ve yanıtsız yinelenen yeniden iletimler o bağlantı noktasında hiçbir şeyin yanıt vermediği anlamına gelir. Her seferinde bir aşamayı test edin ve denemeler arasında tek bir alanı değiştirin; strongSwan'ın NAT geçişi belgeleri, yakalamanın size gösterdiği işareti ve bağlantı noktası davranışını açıklar.

İlgili makaleler