iPhone Always On VPN: két alagút oszthat egy virtuális IP-t

Egy felügyelt iPhone-on, kezelt Always On profillal a telefon minden aktív IP-interfészhez alagutat tart, így a mobilhálózat és a Wi-Fi külön-külön kap egyet. A kiszolgáló ezután két IKE-biztonsági társítást listáz egy eszközhöz, gyakran egy virtuális címet megosztva, és az első ösztön az, hogy rekey-huroknak nevezzük, és elkezdjük módosítani az időzítőket. Ez az ösztön általában téves. Járja végig az alábbi lépéseket abban a sorrendben, ahogy a bizonyítékok a kiszolgálón megjelennek, és hagyja békén a telefon beállításait, amíg a kiszolgáló meg nem mondja, melyik eset áll fenn.

Kezdje azzal a két sorral, amely már ott van a kiszolgálón

Listázza a társításokat a swanctl --list-sas paranccsal, és olvasson négy mezőt mindkét bejegyzésben: a távoli címet, a hitelesített identitást, a kiosztott virtuális IP-t és a létrehozás idejét. Két különböző külső cím egy identitással és egy virtuális IP-vel az a forma, amely elindította ezt a kérdést, és érdemes felírni bármilyen változtatás előtt. Ezután ellenőrizze az egyes társításokhoz kapcsolódó gyermektársításokat, mert a forgalomválasztók döntik el, hogy egy célkeresés valaha meg tudná-e különböztetni a két alagutat. Egy pár, amely másodpercek alatt megjelenik és eltűnik, más állat, mint egy pár, amely mindkettő órákig él.

Következtetés levonása előtt rendezze a listát létrehozási idő szerint. A szomszédosság a kimenetben semmit sem jelent, és a táblázatos lista pontosan erre a hibára csábít.

Döntse el, melyik átfedést látja

Az IKEv2 rekey és a make-before-break újrahitelesítés szándékosan rövid átfedést hoz létre, az új társítást a régi törlése előtt létrehozva. Az időbélyegek döntenek, mert egy régi SA, amely egy-két másodperccel az új megjelenése után eltűnik, megújítás, amely végzi a dolgát. A független interfész-alagutak soha nem így néznek ki, mert mindegyik addig áll fenn, amíg az interfésze aktív, és az egyik törlése nem következik a másik létrehozásából.

Az Apple kezelt Always On viselkedése interfészenkénti, ezért egy felügyelt eszköz jogosan tűnhet forgalmasabbnak, mint egy kézzel beállított profil. Egy szolgáltatói alkalmazás automatikus csatlakozás kapcsolója nem ugyanezt jelenti, és egy közönséges on-demand szabály sem. Az Apple telepítési áttekintése az interfészenkénti modellt írja le; hasonlítsa össze a két sorát vele, mielőtt hurokra gondolna. Mindkét forma ugyanabból a kiszolgálóoldali készletből merít, tehát az átfedés az egyetlen korai jelzés.

Nézze meg, miért töri meg a válaszokat egy virtuális cím két alagútnál

A telefonra küldött válasz a belső címre irányul, és a kernel a cél és a házirend alapján választ kimenő alagutat, nem az alapján az interfész alapján, amelyet a telefon használt. Két egyidejű társítás, amely ugyanazt a virtuális IP-t tartja egyező házirendekkel, magára hagyja az útválasztási döntést, hogy ne tudja megmondani, melyik munkamenethez tartozik egy válasz. Néhány válasz a rossz alagutat választja, és a telefon egyirányúan működő vagy a Wi-Fi megjelenésekor meghaló kapcsolatot mutat. Két parancskimenet bizonyítja az állapotot: swanctl --list-sas ugyanazt a virtuális IP-t mutatja mindkét SA-n, és ip xfrm policy két azonos választót mutat.

Pontosan ezt a kimenetpárt illeszti be a változási jegyzőkönyvbe. Egyik sem meggyőző önmagában, mert mindegyik külön-külön is hihetőnek tűnhet.

Ez kiszolgálóoldali címzés és házirend, nem a telefon hibás viselkedése, és semmilyen kliensbeállítás nem választ el két azonos belső címet. A készlet kétszer adta ki ugyanazt az értéket, és a házirend-telepítő elfogadta. A kliens hibáztatása előtt olvassa le az eredményt a kiszolgáló oldaláról.

Módosítsa a készletet vagy a párhuzamossági modellt, ne a rekey-időzítőt

A swanctl konfigurációban az egyediség kifejezett házirend a kapcsolaton: a unique = replace eltávolít egy régebbi kapcsolatot, amikor egy új létrejön, a unique = keep pedig elutasítja az újonnan érkezőt. Mindkét érték a kapcsolat létrehozásakor hat, nem a benne lévő gyermek SA-kra.

connections {
  ios-alwayson {
    unique = replace
  }
}

Egyik érték sem semleges egy interfészenkénti kliens számára. A keep rendezett állapotképernyőt állít vissza azzal, hogy elutasítja a második alagutat, és megtöri a kezelt tervezést, míg a replace lerombolja a régebbi alagutat, és ugyanaz a kompromisszum a másik irányban. Ha valóban mindkét alagútra szükség van, a készlet hátterének külön lízingeket kell kiadnia egy identitáshoz, és a lízingkulcsának meg kell különböztetnie a kéréseket. Egy statikus identitás-cím tábla szívesen visszaadja ugyanazt a címet kétszer, és több konfigurációval reprodukálja az eredeti problémát. Ellenőrizze, hogyan kulcsolja a háttér a lízingeket, mielőtt második statikus leképezést ad hozzá.

Tesztelje azokat az átmeneteket, amelyeket valóban kiszolgál

Sétáljon ki a Wi-Fi hatóköréből aktív munkamenettel, majd jöjjön vissza, és ellenőrizze, hogy a válaszok mindkét irányban megérkeznek. Tegye ezt kétszer, mert a második átmenet az, ahol az elavult házirend általában megjelenik. Teszteljen olyan szolgáltatással, amely az Ön által megnyitott kapcsolaton válaszol, és ismételje meg a kilépést, miközben az alagút forgalmat visz, nem pedig tétlenül áll. Egy telefon, amely tud küldeni, de nem tud fogadni, egészségesnek látszik egy handshake-naplóban, és töröttnek a böngészőben.

Egy sorra csökkentett állapotképernyő nem egy működő tervezés bizonyítéka, csak annak bizonyítéka, hogy egy alagút elment. Mindkét iránynak működnie kell, mielőtt egy átmenet átmegy. Jegyezze fel, mit figyelt meg, az átfedés-ellenőrzés két kimenetével együtt, hogy a következő mérnök össze tudja hasonlítani a séta megismétlése helyett.