iPhone Always On VPN: du tuneloj povas kunhavigi unu virtualan IP

Sur gvatata iPhone kun administrata Always On-profilo la telefono tenas tunelon por ĉiu aktiva IP-interfaco, do la poŝreto kaj la Wi-Fi ĉiu ricevas sian propran. La servilo poste listigas du IKE-sekurecajn asociojn por unu aparato, ofte kunhavigante unu virtualan adreson, kaj la unua instinkto estas nomi tion reŝlosada buklo kaj komenci ŝanĝi tempigilojn. Tiu instinkto kutime malpravas. Trairu la subajn paŝojn laŭ la ordo, en kiu la pruvoj aperas en la servilo, kaj lasu la telefonajn agordojn trankvilaj ĝis la servilo diros al vi, kiun kazon vi havas.

Komencu per la du vicoj, kiujn la servilo jam havas

Listigu la asociojn per swanctl --list-sas kaj legu kvar kampojn en ambaŭ rikordoj: la malproksiman adreson, la aŭtentikigitan identecon, la atribuitan virtualan IP kaj la kreotempon. Du malsamaj eksteraj adresoj kun unu identeco kaj unu virtuala IP estas la formo, kiu komencis ĉi tiun demandon, kaj indas skribi ĝin antaŭ ajna ŝanĝo. Poste kontrolu la idajn asociojn ligitajn al ĉiu el ili, ĉar la trafikaj selektiloj decidas, ĉu celoserĉo iam povus distingi la du tunelojn. Paro, kiu aperas kaj malaperas ene de sekundoj, estas alia besto ol paro, kiu ambaŭ vivas dum horoj.

Ordigi la liston laŭ kreotempo antaŭ ol fari konkludon. Apudeco en la eligo signifas nenion, kaj tabela listo invitas ĝuste tiun eraron.

Decidu, kiun interkovron vi rigardas

IKEv2-reŝlosado kaj make-before-break-reaŭtentikigo intence kreas mallongan interkovron, establante la novan asocion antaŭ ol forigi la malnovan. Tempomarkoj solvas la kazon, ĉar malnova SA, kiu malaperas sekundon aŭ du post la apero de la nova, estas renovigo, kiu faras sian laboron. Sendependaj interfacaj tuneloj neniam aspektas tiel, ĉar ĉiu daŭras dum ĝia interfaco estas supre, kaj forigo de unu ne sekvas el kreo de la alia.

La administrata Always On-konduto de Apple estas laŭ interfaco, tial gvatata aparato povas laŭleĝe aspekti pli okupata ol permane agordita profilo. La aŭtomata konektilo de provizanta aplikaĵo ne implicas la samon, kaj ordinara on-demand-regulo ankaŭ ne. La superrigardo pri deplojo de Apple priskribas la modelon laŭ interfaco; komparu viajn du vicojn kun ĝi antaŭ ol supozi buklon. Ambaŭ formoj ankaŭ ĉerpas el la sama servila provizo, do la interkovro estas via sola frua signalo.

Vidu, kial unu virtuala adreso por du tuneloj rompas respondojn

Respondo al la telefono estas adresita al la interna adreso, kaj la kerno elektas elirantan tunelon laŭ celo kaj politiko, ne laŭ la interfaco, kiun la telefono uzis. Du samtempaj asocioj tenante la saman virtualan IP kun koincidaj politikoj lasas la enkursigan decidon sen maniero diri, al kiu sesio respondo apartenas. Iuj respondoj prenas la malĝustan tunelon, kaj la telefono montras konekton, kiu funkcias unudirekte aŭ mortas, kiam la Wi-Fi aperas. Du komandeligoj pruvas la staton: swanctl --list-sas montras la saman virtualan IP sur ambaŭ SA, kaj ip xfrm policy montras du identajn selektilojn.

Ĝuste tiun paron de eligoj vi enmetas en la ŝanĝprotokolon. Neniu sola estas konvinka, ĉar ĉiu povas aspekti kredebla aparte.

Tio estas adresado kaj politiko ĉe la servila flanko, ne miskonduto de la telefono, kaj neniu klienta agordo apartigas du identajn internajn adresojn. La provizo eldonis la saman valoron dufoje kaj la politika instalilo akceptis ĝin. Legu la rezulton de la servila flanko antaŭ ol kulpigi la klienton.

Ŝanĝu la provizon aŭ la samtempecan modelon, ne la reŝlosadan tempigilon

En swanctl-agordo unikeco estas eksplicita politiko sur la konekto: unique = replace forigas pli malnovan konekton, kiam nova establiĝas, kaj unique = keep rifuzas la novveninton. Ambaŭ valoroj agas, kiam konekto estas starigata, ne sur la idaj SA ene de ĝi.

connections {
  ios-alwayson {
    unique = replace
  }
}

Neniu valoro estas neŭtrala por laŭinterfaca kliento. keep restarigas ordan statusan ekranon rifuzante la duan tunelon kaj rompas la administritan dezajnon, dum replace disŝiras la pli malnovan tunelon kaj estas la sama kompromiso en la alia direkto. Se ambaŭ tuneloj vere necesas, la proviza malantaŭo devas eldoni malsamajn luojn por unu identeco, kaj ĝia lua ŝlosilo devas distingi la petojn. Statika identeco-al-adresa tabelo volonte redonos la saman adreson dufoje kaj reproduktos la originan problemon kun pli da agordo. Kontrolu, kiel la malantaŭo ŝlosilas luojn, antaŭ ol aldoni duan statikan mapadon.

Testu la transirojn, kiujn vi efektive liveras

Eliru el la Wi-Fi-atingo kun aktiva sesio, poste reeniru, kaj kontrolu, ke respondoj alvenas en ambaŭ direktoj. Faru tion dufoje, ĉar ĉe la dua transiro kutime aperas kaduka politiko. Testu per servo, kiu respondas sur la konekto, kiun vi malfermis, kaj ripetu la eliron dum la tunelo portas trafikon anstataŭ sidi senokupa. Telefono, kiu povas sendi sed ne ricevi, aspektas sana en manprema protokolo kaj rompita en retumilo.

Statusa ekrano reduktita al unu vico ne estas pruvo de funkcianta dezajno, nur pruvo, ke unu tunelo foriris. Ambaŭ direktoj devas funkcii antaŭ ol transiro pasas. Notu, kion vi observis, kune kun la du eligoj de la interkovra kontrolo, por ke la sekva inĝeniero povu kompari anstataŭ ripeti la promenon.