iPhone Always On VPN: iki tunel bir virtual IP-ni paylaşa bilər

İdarə olunan Always On profili olan nəzarətli iPhone-da telefon hər aktiv IP interfeysi üçün tunel saxlayır, buna görə mobil şəbəkə və Wi-Fi hər biri öz tunelini alır. Sonra server bir cihaz üçün iki IKE təhlükəsizlik assosiasiyası sadalayır, çox vaxt bir virtual ünvanı paylaşır və ilk instinkt bunu açar yenilənmə döngəsi adlandırıb taymerləri dəyişməyə başlamaqdır. Bu instinkt adətən səhvdir. Aşağıdakı addımları sübutların serverdə görünmə sırası ilə keçin və server hansı halda olduğunuzu söyləyənə qədər telefon parametrlərinə toxunmayın.

Serverin artıq saxladığı iki sətirdən başlayın

Assosiasiyaları swanctl --list-sas ilə sadalayın və hər iki qeyd üzrə dörd sahəni oxuyun: uzaq ünvan, doğrulanmış kimlik, təyin edilmiş virtual IP və yaradılma vaxtı. Bir kimlik və bir virtual IP ilə iki fərqli xarici ünvan bu sualı başladan formadır və hər hansı dəyişiklikdən əvvəl onu yazmağa dəyər. Sonra hər birinə bağlı uşaq assosiasiyalarına baxın, çünki trafik seçiciləri təyinat axtarışının iki tuneli heç vaxt ayıra biləcəyini müəyyən edir. Saniyələr içində görünüb yox olan cüt, saatlarla yaşayan cütdən fərqli bir şeydir.

Nəticə çıxarmazdan əvvəl siyahını yaradılma vaxtına görə sıralayın. Çıxışda qonşuluq heç nə ifadə etmir və cədvəl formasında siyahı məhz bu səhvi dəvət edir.

Hansı üst-üstə düşməyə baxdığınızı müəyyən edin

IKEv2 açar yenilənməsi və make-before-break yenidən doğrulama qəsdən qısa üst-üstə düşmə yaradır: yeni assosiasiya köhnə silinməzdən əvvəl qurulur. Vaxt nişanları məsələni həll edir, çünki yenisinin görünməsindən bir-iki saniyə sonra yox olan köhnə SA yenilənmənin öz işini gördüyünü göstərir. Müstəqil interfeys tunelləri heç vaxt belə görünmür, çünki hər biri öz interfeysi işlədiyi müddətdə qalır və birinin silinməsi digərinin yaradılmasından irəli gəlmir.

Apple-ın idarə olunan Always On davranışı interfeys üzrədir, buna görə nəzarətli cihaz əl ilə qurulmuş profildən qanuni olaraq daha məşğul görünə bilər. Provayder tətbiqinin avtomatik qoşulma açarı eyni şeyi ifadə etmir, adi on-demand qaydası da etmir. Apple yerləşdirmə icmalı interfeys üzrə modeli təsvir edir; döngə olduğunu düşünməzdən əvvəl iki sətrinizi onunla müqayisə edin. Hər iki forma da eyni server hovuzundan götürür, buna görə üst-üstə düşmə sizin yeganə erkən siqnalınızdır.

Bir virtual ünvanın iki tunel üçün cavabları niyə pozduğunu görün

Telefona cavab daxili ünvana ünvanlanır və kernel çıxan tuneli təyinat və siyasətə görə seçir, telefonun istifadə etdiyi interfeysə görə yox. Eyni virtual IP-ni saxlayan və siyasətləri üst-üstə düşən iki paralel assosiasiya marşrut qərarını cavabın hansı sessiyaya aid olduğunu deyə bilməyəcək vəziyyətdə qoyur. Bəzi cavablar səhv tuneldən gedir və telefon bir istiqamətdə işləyən, Wi-Fi qalxanda isə ölən bir bağlantı göstərir. İki əmr çıxışı vəziyyəti sübut edir: swanctl --list-sas hər iki SA-da eyni virtual IP-ni göstərir və ip xfrm policy iki eyni seçici göstərir.

Məhz bu iki çıxış dəyişiklik qeydinə yapışdırdığınız şeydir. Təkbaşına heç biri inandırıcı deyil, çünki hər biri özlüyündə inandırıcı görünə bilər.

Bu, telefonun səhv davranışı deyil, server tərəfində ünvanlama və siyasətdir və heç bir müştəri parametri iki eyni daxili ünvanı ayırmır. Hovuz eyni dəyəri iki dəfə verib və siyasət quraşdırıcısı onu qəbul edib. Müştərini günahlandırmazdan əvvəl nəticəni serverin tərəfindən oxuyun.

Hovuzu və ya paralellik modelini dəyişin, açar yenilənmə taymerini yox

swanctl konfiqurasiyasında unikallıq bağlantı üzərində açıq siyasətdir: unique = replace yeni bağlantı qurulanda köhnəni silir, unique = keep isə yeni gələni rədd edir. Hər iki dəyər bağlantı qurularkən işə düşür, içindəki uşaq SA-lara yox.

connections {
  ios-alwayson {
    unique = replace
  }
}

Heç bir dəyər interfeys üzrə müştəri üçün neytral deyil. keep ikinci tuneli rədd edərək səliqəli status ekranını bərpa edir və idarə olunan dizaynı pozur, replace isə köhnə tuneli sökür və digər istiqamətə baxan eyni güzəştdir. Əgər hər iki tunel həqiqətən lazımdırsa, hovuz arxası bir kimlik üçün ayrı icarələr verməlidir və onun icarə açarı sorğuları fərqləndirməlidir. Statik kimlik-ünvan cədvəli eyni ünvanı iki dəfə qaytaracaq və ilkin problemi daha çox konfiqurasiya ilə təkrarlayacaq. İkinci statik xəritə əlavə etməzdən əvvəl arxa tərəfin icarələri necə açarladığını yoxlayın.

Həqiqətən yayımladığınız keçidləri sınayın

Aktiv sessiya ilə Wi-Fi əhatəsindən çıxın, sonra geri qayıdın və cavabların hər iki istiqamətdə gəldiyini yoxlayın. Bunu iki dəfə edin, çünki köhnəlmiş siyasət adətən ikinci keçiddə üzə çıxır. Açdığınız bağlantıda cavab verən xidmətlə sınaq keçirin və tunel boş dayanmaq əvəzinə trafik daşıyarkən çıxışı təkrarlayın. Göndərə bilən amma qəbul edə bilməyən telefon əl sıxma jurnalında sağlam, brauzerdə isə pozulmuş görünür.

Bir sətrə endirilmiş status ekranı işlək dizaynın sübutu deyil, yalnız bir tunelin getdiyinin sübutudur. Keçid keçməzdən əvvəl hər iki istiqamət işləməlidir. Müşahidə etdiklərinizi üst-üstə düşmə yoxlamasının iki çıxışı ilə birlikdə yazın ki, növbəti mühəndis gəzintini təkrarlamaq əvəzinə müqayisə edə bilsin.