iPhone Always On VPN: iki tünel tek bir sanal IP'yi paylaşabilir

Arabirim başına Always On tünelleri başarısız bir rekey değildir. Sunucudaki iki SA'yı karşılaştırın, ardından tek bir kimliğin iki iç adresi tutup tutamayacağına karar verin.

Yönetilen bir Always On profiline sahip gözetimli bir iPhone'da telefon, her etkin IP arabirimi için bir tünel tutar, böylece hücresel ve Wi-Fi kendi tünellerini alır. Sunucu ardından tek bir cihaz için iki IKE güvenlik ilişkilendirmesi listeler, genellikle tek bir sanal adresi paylaşır ve ilk dürtü buna rekey döngüsü demek ve zamanlayıcıları değiştirmeye başlamaktır. Bu dürtü genellikle yanlıştır. Aşağıdaki adımları kanıtların sunucuda görünme sırasına göre izleyin ve sunucu hangi durumda olduğunuzu söyleyene kadar telefon ayarlarına dokunmayın.

Sunucunun zaten sahip olduğu iki satırla başlayın

İlişkilendirmeleri swanctl --list-sas ile listeleyin ve her iki kayıtta dört alanı okuyun: uzak adres, kimliği doğrulanmış kimlik, atanan sanal IP ve oluşturulma zamanı. Tek kimlik ve tek sanal IP ile iki farklı dış adres bu soruyu başlatan biçimdir ve herhangi bir değişiklikten önce bunu yazmakta fayda var. Ardından her birine bağlı alt ilişkilendirmeleri kontrol edin, çünkü trafik seçicileri bir hedef aramasının iki tüneli birbirinden ayırt edip edemeyeceğine karar verir. Saniyeler içinde görünüp kaybolan bir çift, ikisinin de saatlerce yaşadığı bir çiftten başka bir hayvandır.

Sonuca varmadan önce listeyi oluşturulma zamanına göre sıralayın. Çıktıdaki komşuluk hiçbir anlam taşımaz ve tablo biçimli bir liste tam da bu hataya davetiye çıkarır.

Hangi örtüşmeye baktığınıza karar verin

IKEv2 rekey ve make-before-break yeniden kimlik doğrulaması kasıtlı olarak kısa bir örtüşme yaratır: yeni ilişkilendirme, eski silinmeden önce kurulur. Zaman damgaları durumu belirler, çünkü yeni olan ortaya çıktıktan bir iki saniye sonra kaybolan eski SA, işini yapan bir yenilemedir. Bağımsız arabirim tünelleri asla böyle görünmez, çünkü her biri arabirimi açık olduğu sürece varlığını sürdürür ve birinin silinmesi diğerinin oluşturulmasından kaynaklanmaz.

Apple'ın yönetilen Always On davranışı arabirim başınadır, bu yüzden gözetimli bir cihaz elle yapılandırılmış bir profilden meşru olarak daha meşgul görünebilir. Sağlayıcı uygulamasının otomatik bağlanma anahtarı aynı şeyi ifade etmez, sıradan bir on-demand kuralı da etmez. Apple'ın dağıtım genel bakışı arabirim başına modeli açıklar; bir döngü varsaymadan önce iki satırınızı onunla karşılaştırın. İki biçim de aynı sunucu havuzundan çeker, bu yüzden örtüşme tek erken sinyalinizdir.

İki tünel için tek sanal adresin yanıtları neden bozduğunu görün

Telefona giden yanıt iç adrese yönlendirilir ve çekirdek giden tüneli hedefe ve politikaya göre seçer, telefonun kullandığı arabirime göre değil. Aynı sanal IP'yi çakışan politikalarla tutan iki eşzamanlı ilişkilendirme, yönlendirme kararını bir yanıtın hangi oturuma ait olduğunu söyleme yolu olmadan bırakır. Bazı yanıtlar yanlış tünele gider ve telefon tek yönlü çalışan ya da Wi-Fi yükseldiğinde ölen bir bağlantı gösterir. İki komut çıktısı durumu kanıtlar: swanctl --list-sas her iki SA'da aynı sanal IP'yi gösterir ve ip xfrm policy iki özdeş seçiciyi gösterir.

Değişiklik kaydına yapıştırdığınız şey tam olarak bu çıktı çiftidir. Hiçbiri tek başına ikna edici değildir, çünkü her biri tek başına makul görünebilir.

Bu, telefonun yanlış davranışı değil, sunucu tarafında adresleme ve politikadır ve hiçbir istemci ayarı iki özdeş iç adresi ayırmaz. Havuz aynı değeri iki kez verdi ve politika yükleyicisi bunu kabul etti. İstemciyi suçlamadan önce sonucu sunucu tarafından okuyun.

Havuzu veya eşzamanlılık modelini değiştirin, rekey zamanlayıcısını değil

swanctl yapılandırmasında benzersizlik bağlantı üzerinde açık bir politikadır: unique = replace yeni bir bağlantı kurulduğunda daha eski bir bağlantıyı kaldırır ve unique = keep yeni geleni reddeder. Her iki değer de bir bağlantı kurulurken etkilidir, içindeki alt SA'larda değil.

connections {
  ios-alwayson {
    unique = replace
  }
}

Hiçbir değer arabirim başına bir istemci için nötr değildir. keep ikinci tüneli reddederek düzenli bir durum ekranını geri getirir ve yönetilen tasarımı bozar, replace ise daha eski tüneli yıkar ve diğer yönde aynı uzlaşmadır. İki tünel gerçekten gerekliyse havuzun arka ucu tek bir kimlik için farklı kiralamalar vermeli ve kiralama anahtarı istekleri ayırt etmelidir. Statik kimlik-adres tablosu aynı adresi iki kez memnuniyetle döndürür ve asıl sorunu daha fazla yapılandırmayla yeniden üretir. İkinci statik eşlemeyi eklemeden önce arka ucun kiralamaları nasıl anahtarladığını kontrol edin.

Gerçekten kullanıma aldığınız geçişleri test edin

Etkin bir oturumla Wi-Fi menzilinin dışına çıkın, sonra geri dönün ve yanıtların iki yönde de geldiğini kontrol edin. Bunu iki kez yapın, çünkü ikinci geçiş eski bir politikanın genellikle ortaya çıktığı yerdir. Açtığınız bağlantıda yanıt veren bir hizmetle test edin ve tünel boşta durmak yerine trafik taşırken çıkışı tekrarlayın. Gönderebilen ama alamayan bir telefon handshake günlüğünde sağlıklı, tarayıcıda bozuk görünür.

Tek satıra indirgenmiş bir durum ekranı çalışan bir tasarımın kanıtı değildir, yalnızca bir tünelin gittiğinin kanıtıdır. Bir geçişin geçmesi için iki yön de çalışmalıdır. Gözlemlediklerinizi örtüşme kontrolünün iki çıktısıyla birlikte yazın, böylece sonraki mühendis yürüyüşü tekrarlamak yerine karşılaştırabilsin.

İlgili makaleler