iPhone Always On VPN: dva tunely mohou sdílet jednu virtuální IP

Na dohlíženém iPhonu se spravovaným profilem Always On drží telefon tunel pro každé aktivní IP rozhraní, takže mobilní síť i Wi-Fi mají každé svůj. Server pak vypíše dvě IKE bezpečnostní asociace pro jedno zařízení, často sdílející jednu virtuální adresu, a první instinkt je nazvat to smyčkou obnovy klíče a začít měnit časovače. Ten instinkt je obvykle špatný. Projděte kroky níže v pořadí, v jakém se důkazy objevují na serveru, a nechte nastavení telefonu na pokoji, dokud vám server neřekne, o který případ jde.

Začněte dvěma řádky, které server už má

Vypište asociace pomocí swanctl --list-sas a přečtěte čtyři pole u obou záznamů: vzdálenou adresu, ověřenou identitu, přidělenou virtuální IP a čas vytvoření. Dvě různé vnější adresy s jednou identitou a jednou virtuální IP jsou tvarem, který tuto otázku spustil, a stojí za to si jej zapsat před jakoukoli změnou. Pak zkontrolujte podřízené asociace připojené ke každé z nich, protože selektory provozu rozhodují o tom, zda by vyhledání cíle mohlo oba tunely vůbec rozlišit. Pár, který se objeví a zmizí během sekund, je jiné zvíře než pár, který oba žije hodiny.

Před vyvozením závěru seřaďte seznam podle času vytvoření. Sousedství ve výstupu nic neznamená a tabulkový výpis k této chybě přímo vybízí.

Určete, na které překrytí se díváte

Obnova klíče IKEv2 a reautentizace make-before-break záměrně vytvářejí krátké překrytí: nová asociace se naváže dřív, než se stará smaže. Časová razítka případ rozhodnou, protože stará SA, která zmizí sekundu nebo dvě po objevení nové, je obnova, která dělá svou práci. Nezávislé tunely na rozhraních tak nikdy nevypadají, protože každý přetrvává, dokud je jeho rozhraní aktivní, a smazání jednoho nevyplývá z vytvoření druhého.

Spravované chování Always On od Applu je na rozhraní, proto dohlížené zařízení může legitimně vypadat vytíženější než ručně nastavený profil. Přepínač automatického připojení v aplikaci poskytovatele neznamená totéž a obyčejné pravidlo on-demand také ne. Přehled nasazení Applu popisuje model na rozhraní; porovnejte své dva řádky s ním, než budete předpokládat smyčku. Oba tvary také čerpají ze stejného fondu na serveru, takže překrytí je váš jediný časný signál.

Podívejte se, proč jedna virtuální adresa pro dva tunely rozbíjí odpovědi

Odpověď telefonu je adresována na vnitřní adresu a jádro vybírá odchozí tunel podle cíle a zásady, ne podle rozhraní, které telefon použil. Dvě souběžné asociace držící stejnou virtuální IP se shodnými zásadami nechávají rozhodnutí o směrování bez způsobu, jak říct, ke které relaci odpověď patří. Některé odpovědi jdou špatným tunelem a telefon ukazuje spojení, které funguje jedním směrem nebo umře, když se objeví Wi-Fi. Dva výstupy příkazů stav dokazují: swanctl --list-sas ukazuje stejnou virtuální IP na obou SA a ip xfrm policy ukazuje dva totožné selektory.

Právě tuto dvojici výstupů vložíte do záznamu o změně. Ani jeden sám o sobě není přesvědčivý, protože každý může vypadat věrohodně zvlášť.

Tohle je adresování a zásady na straně serveru, ne špatné chování telefonu, a žádné nastavení klienta dvě totožné vnitřní adresy neoddělí. Fond vydal stejnou hodnotu dvakrát a instalátor zásad ji přijal. Přečtěte výsledek ze strany serveru, než obviníte klienta.

Změňte fond nebo model souběžnosti, ne časovač obnovy klíče

V konfiguraci swanctl je jedinečnost výslovnou zásadou na spojení: unique = replace odstraní starší spojení, když se nové naváže, a unique = keep nováčka odmítne. Obě hodnoty působí při navazování spojení, ne na podřízené SA uvnitř něj.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ani jedna hodnota není pro klienta na rozhraní neutrální. keep obnoví uklizenou stavovou obrazovku tím, že druhý tunel odmítne, a rozbije spravovaný návrh, zatímco replace starší tunel strhne a je stejným kompromisem opačným směrem. Pokud jsou oba tunely skutečně potřeba, backend fondu musí pro jednu identitu vydávat odlišné lease a jeho klíč lease musí požadavky rozlišit. Statická tabulka identita-adresa ráda vrátí stejnou adresu dvakrát a původní problém reprodukuje s více konfigurací. Než přidáte druhé statické mapování, zkontrolujte, jak backend klíčuje lease.

Testujte přechody, které skutečně nasazujete

Odejděte z dosahu Wi-Fi s aktivní relací, pak se vraťte a zkontrolujte, že odpovědi dorazí v obou směrech. Udělejte to dvakrát, protože při druhém přechodu se obvykle objeví zastaralá zásada. Testujte službou, která odpovídá na spojení, které jste otevřeli, a odchod zopakujte, když tunel nese provoz, místo aby stál nečinně. Telefon, který umí odesílat, ale ne přijímat, vypadá zdravě v protokolu handshake a rozbitě v prohlížeči.

Stavová obrazovka zúžená na jeden řádek není důkazem funkčního návrhu, jen důkazem, že jeden tunel je pryč. Než přechod projde, musí fungovat oba směry. Zapište, co jste pozorovali, spolu se dvěma výstupy z kontroly překrytí, aby příští inženýr mohl porovnávat místo opakování procházky.