Android-də IKEv2 qeyri-standart UDP portunda niyə işləmir

Yerli IKEv2 forması port deyil, ünvan qəbul edir. Müştərinin bunu dəstəklədiyini təsdiqləyin, iki server portunu təyin edin, sonra kadrlaşdırmaya və jurnallara baxın.

Şlüz IKEv2-yə UDP 4443 portunda cavab verir, profildə Server adlı sahə var, siz host adını və portu yazırsınız, telefon isə serverə çata bilmədiyini və ya ünvanı həll edə bilmədiyini bildirir. Heç nə bloklanmır. Android-in yerli forması host gözləyir, eyni şey Windows-da da keçərlidir. Fərdi port server parametrindən əvvəl müştəri imkanıdır və yalnız bəzi müştərilər onu ifadə etməyə imkan verir. Üç hissəni ardıcıllıqla işləyin: müştərinin nə deyə bildiyi, serverin nəyi dinlədiyi və hər iki tərəfin paketləri eyni şəkildə kadrlaşdırıb-kadrlaşdırmadığı.

Telefon əslində nə göndərdi

Ad üçün nəzərdə tutulmuş sahədə host:port sətri ad kimi həll olunur. Həlledici vpn.example.net:4443 üçün heç nə qaytarmır və gördüyünüz xəta portda vaxt aşımı deyil, ad həlli və ya əlçatmazlıq xətasıdır. Bu fərq vacibdir, çünki daha qısa adla və ya başqa şəbəkə ilə yenidən cəhd etmək formanın ayrışdıra bilmədiyi sətri heç vaxt düzəltməyəcək.

Android-dəki yerli IKEv2 profili, quraşdırılmış Windows VPN müştərisi kimi, standart IKE portlarına bağlanıb. Heç biri port sahəsi göstərmir və profil redaktəsi ilə onu əlavə etmək mümkün deyil. Əgər operatorun dinləyicisi həqiqətən 4443 portundadırsa, o zaman quraşdırılmış müştəri yanlış konfiqurasiya edilmiş deyil, sadəcə yanlış vasitədir.

Portu göstərən müştəri istifadə edin

strongSwan-ın Android müştərisi qabaqcıl profil parametrlərində konfiqurasiya edilə bilən server portunu sənədləşdirir, buna görə də bu dizayn üçün demək olar ki, hər işlək reseptdə görünür. Bu dəstək həmin müştəriyə aiddir: başqa IKEv2 proqramı və ya eyni proqramın satıcı fork-u, əsas strongSwan demonu dəstəkləsə də, eyni sahəni göstərməyə bilər.

Operatorndan bütün dəsti bir dəfəyə istəyin: şlüz adı, UDP portu, autentifikasiya üsulu və müştərinin gözləməli olduğu server kimliyi. Fərdi port sertifikat yoxlamasını söndürmək və ya protokolu dəyişmək üçün səbəb deyil. Portu quraşdırılmış müştərinin gözlədiyi yerə daxil edin və əgər o müştəridə belə sahə yoxdursa, cavab təxmin edilmiş bir keçici həll deyil, başqa təsdiqlənmiş müştəridir.

Serverin iki portu var və hər ikisi uyğun olmalıdır

IKE UDP 500 portunda başlayır və NAT keçidi adətən IKE ilə inkapsulyasiya edilmiş ESP-ni UDP 4500 portuna köçürür. Bunlar strongSwan-da ayrı parametrlərdir, ona görə tək fərdi porta köçürülmüş server hər ikisini eyni dəyərə dəyişməlidir:

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

Hər iki rol üçün bir port olduqda demon həmin soketdə IKE-i UDP içindəki ESP-dən ayırmalıdır və bunu IKE mesajından əvvəl gələn dörd baytlıq qeyri-ESP markeri ilə edir. Buna görə müştəri fərdi portda razılaşıb sonra 4500 portunda səssizcə davam edə bilməz və buna görə “sadəcə portu dəyiş” ifadəsi kadrlaşdırma tələbini gizlədir.

Yönləndirmə dinləyici deyil

4443 portunu adi IKE dinləyicisinə yönləndirmək demək olar ki, uğurlu görünən uğursuzluq modelidir. İlk mübadilə gəlir, server cavab verir, sonra bağlantı dayanır və ya açarları yeniləyib boşalır, çünki cavab başqa portdan çıxır və sonrakı inkapsulyasiya edilmiş trafik iki tərəfin yaratdığı vəziyyətə heç vaxt uyğun gəlmir. Dinləyicini köçürmədən təyinat portunu yenidən yazan qayda məhz bu yarım-açıq nəticəni verir.

Marşrut UDP-yə başdan-başa icazə verməlidir. Otel və ya operator şəbəkəsindən TCP 443 keçməsi UDP portundakı IKEv2 haqqında heç nə demir, hətta nömrə eyni olsa belə. Yalnız TCP 443-ə icazə verildiyi yerdə fərdi UDP portu IKEv2-ni HTTPS-ə çevirmir və düzgün cavab başqa port təcrübəsi deyil, başqa giriş yolu ola bilər.

Test edərkən üç mərhələni ayırın

Müştəri bir dəfə cəhd edərkən serverdə tutun. Heç gəlməyən sorğu son nöqtə və ya firewall məsələsidir; gəlib cavab verməyən sorğu dinləyici və ya siyasət məsələsidir; cavabdan sonra sükut gəlirsə, bu kadrlaşdırma və ya kimlik məsələsidir.

tcpdump -ni eth0 -vv udp port 4443

Sonra müştərinin fırlanan göstəricisini deyil, mesajını oxuyun. Təklif xətası alqoritmlərin uyğun gəlmədiyini bildirir, autentifikasiya xətası kimliklərin və ya sertifikatların uyğun gəlmədiyini bildirir və cavabsız təkrar göndərişlər o portda heç nəyin cavab vermədiyini bildirir. Hər dəfə bir mərhələni sınaqdan keçirin və cəhdlər arasında bir sahəni dəyişin; strongSwan-ın NAT keçidi sənədləri tutmanın sizə göstərdiyi markeri və port davranışını təsvir edir.

Əlaqəli məqalələr