iOS-VPN-profiel: passwordReference, niet het wachtwoord

Je installeert een profiel, de tunnel komt op en alles lijkt klaar. Dan herstart de telefoon, on-demand wekt de verbinding zonder app op de voorgrond, en de tunnel weigert te starten. Het profiel staat er nog en het wachtwoord is nog juist, en daarom stuurt deze fout mensen naar de verkeerde plek. Een Network Extension kan je geheim niet uit het profiel lezen: die heeft een keychain-referentie nodig die hij zelf kan oplossen.

De doorloop hieronder volgt één verbindingspoging door die overdracht, van de query die de referentie bouwt tot de herstart die hem test.

Het profiel bewaart een handgreep, niet het geheim

NEVPNProtocol stelt passwordReference en sharedSecretReference niet voor niets beschikbaar. Wanneer de daemon een tunnel start, draait hij misschien niet in jouw proces, dus kan hij je code niet aanroepen en om een wachtwoord vragen. Hij leest een blijvende keychain-referentie, lost die op in zijn eigen context en haalt het item zelf op.

Je bouwt die referentie door de keychain erom te vragen, en dat is een ander verzoek dan het verzoek om de gegevens:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

Geef het teruggegeven object aan het protocol, niet de gegevens van het item. In de praktijk legt het profiel vast waar het geheim woont, en daarom dupliceert een back-up van de configuratie het wachtwoord niet stilletjes in een plist.

Waarom de API -50 antwoordt

errSecParam betekent dat het verzoek of de waarde misvormd was voor de bewerking, en dat is de fout die je het vaakst ziet wanneer de verzoeken om referentie en gegevens door elkaar raken. Gegevens vragen terwijl de ontvangende code een referentie verwacht, ruwe bytes aan passwordReference toewijzen of queryen met een toegangsgroep die de app niet kan gebruiken, allemaal veroorzaken ze hem.

Wrapper-bibliotheken nodigen hiertoe uit. Een helper die bytes teruggeeft is niet uitwisselbaar met een die een referentie teruggeeft, dus de reparatie is meestal een andere query in plaats van een ander wachtwoord.

Dezelfde mismatch verklaart een profiel dat zonder klagen wordt opgeslagen en daarna niet verbindt: wat is opgeslagen is een blob, geen handgreep, en de daemon heeft niets op te lossen.

Slaat prima op, faalt bij het verbinden

Opslaan oefent de context van je app. Verbinden oefent die van de daemon, en beide hebben niet dezelfde toegang. Een profiel kan daarom elke test in de simulator doorstaan en bij de eerste on-demand-start falen.

Dat is ook de vorm van het herstartsymptoom: het werkt zolang de app open is en sterft wanneer het systeem de tunnel zelf start.

Test het achtergrondpad bewust vóór de release. Lok een on-demand-verbinding uit met de app gesloten, en lees dan de console van het apparaat in plaats van het log van de app, want de fout wordt vastgelegd door het proces dat de referentie probeerde op te lossen. Als de console laat zien dat de daemon het item weigert, is de referentie in orde en is de toegankelijkheid van het item het probleem.

Toegankelijkheid bepaalt of een herstart werkt

Het item moet leesbaar zijn voor welk systeemproces de tunnel ook start, en dat is een breder publiek dan je app op de voorgrond. Die beperking kiest het toegankelijkheidsattribuut voor je. Een item dat tot de eerste ontgrendeling is beschermd, is beschikbaar voor een achtergrondstart nadat het apparaat één keer is ontgrendeld; een item dat vereist dat het apparaat nu ontgrendeld is, is dat niet.

De strengere klasse kiezen is verleidelijk en precies dat breekt een on-demand-profiel op een vergrendelde telefoon.

Nadat je de klasse hebt gewijzigd, maak het item opnieuw aan in plaats van attributen op het bestaande te bewerken, en sla het protocol daarna opnieuw op met een verse referentie. Attribuutwijzigingen op een bestaand item leveren niet altijd het gedrag op dat de documentatie suggereert, en een herbouwd item neemt de twijfel weg.

Rotatie is waar opgeslagen profielen wegrotten

Het wachtwoord in de keychain wijzigen verandert niet automatisch waar het opgeslagen profiel naar wijst. Het item verwijderen is erger: het profiel houdt een referentie naar iets dat niet meer bestaat, en de fout lijkt op een afwijzing van authenticatie.

Roteer in één volgorde. Werk het item bij, vraag een nieuwe blijvende referentie op, sla het protocol opnieuw op en verbind daarna met de app gesloten om te bewijzen dat de daemon hem nog kan oplossen. Houd het gebruikerswachtwoord en het gedeelde geheim in aparte items zodat elk volgens zijn eigen schema roteert, en log nooit het querywoordenboek of de referentie zelf. De handgreep is geen geheim, maar wel een kaart ernaartoe.