De NEVPNManager-status is ongeldig tot de instellingen zijn geladen

Start de app opnieuw, vraag de manager naar de verbindingsstatus, en hij meldt verbroken terwijl het systeemmenu duidelijk een actieve tunnel toont. Of een opslaan-aanroep geeft een fout die niets verklaart, of een gedeeld geheim wordt seconden na toewijzing als ontbrekend gemeld. Drie symptomen, één mechanisme: de manager is een weergave op een systeemopslag, en een weergave leest leeg tot iemand hem laadt.

Voordat je hier iets van debugt, bepaal welke API je hoort te gebruiken. Een systeemtunnel met IPsec of IKEv2 past bij de ingebouwde manager; een protocol dat het systeem niet implementeert vereist een tunnelprovider met je eigen pakketafhandeling, en geen enkele combinatie van velden verandert dat.

De manager is een weergave op een opslag

Maak of haal de manager, vraag hem zijn instellingen te laden en laat de completion-handler aflopen voordat je status leest of protocolinstellingen wijzigt. Als de taak is om opgeslagen configuraties op te sommen, gebruik dan de aanroep voor alle varianten in plaats van één instantie voor twee doelen te hergebruiken. Voordat het laden aankomt is de status meestal ongeldig, en ongeldig als uit interpreteren is precies de bug waardoor een app pas na een herstart verkeerd lijkt.

Schrijven volgt dezelfde volgorde. Een opslagpoging op een manager die nooit iets heeft geladen kan mislukken zonder bruikbare melding, omdat er geen opgeslagen identiteit is waarop de wijziging kan worden toegepast. Laad, wijzig, sla op en lees daarna de status opnieuw. Het object waarmee het systeem verbindt is het opgeslagen profiel, niet degene die je in het geheugen bewerkte.

Statuswijzigingen komen alleen terwijl je kijkt

Zodra de instellingen zijn geladen, loopt de status door verbroken, verbinden, verbonden, opnieuw bevestigen en verbreken. Initialiseer de interface met één lezing en luister daarna naar de wijzigingsmelding in plaats van te pollen met een timer. Pollen werkt op de voorgrond en liegt op de achtergrond, en zo blijven apps zitten met een spinner die nooit wordt opgelost.

Meldingen komen alleen binnen terwijl de app op de voorgrond is. Alles wat de toestand op de achtergrond bijhoudt, ziet er na een herstart verouderd uit, dus ververs bij het starten en opnieuw wanneer de app terugkeert naar de voorgrond. Als een provider de tunnel bezit, bestuur hem dan via het bijbehorende sessieobject; de gewone verbindingseigenschap modelleert de levenscyclus van een provider niet.

Geheimen zijn referenties, geen strings

De melding dat een gedeeld geheim ontbreekt, betekent zelden dat niemand er een heeft toegewezen. Het protocolobject wil een referentie: één voor het gebruikerswachtwoord en één voor de vooraf gedeelde IPsec-sleutel. nil doorgeven, of een referentie die is afgeleid van de verkeerde keychain-entry, levert dezelfde klacht op als een lege plek. De fout benoemt het symptoom en verbergt de oorzaak, daarom voeren mensen hetzelfde geheim meerdere keren opnieuw in.

Schrijf het geheim eerst als een generiek wachtwoorditem en lees daarna een blijvende referentie erop terug. Een blijvende referentie overleeft een herstart, anders dan een pointer in het geheugen, en het is de representatie die het profiel serialiseert. Kies een toegankelijkheidsklasse die nog toegang toestaat zodra het apparaat is ontgrendeld, anders faalt een tunnel die op een vergrendeld scherm opnieuw moet verbinden op authenticatie met een volkomen geldig geheim.

De extensie heeft zijn eigen keychain-weergave

Een netwerkextensie is een apart proces, dus de standaard keychain-toegang van de app bereikt hem niet. Geef beide targets dezelfde keychain-toegangsgroep in hun entitlements, sla het item één keer binnen die groep op, en laat elk proces het lezen. Zonder de groep vindt de extensie niets en meldt een inloggegevensfout die de app niet kan reproduceren.

Als de provider wordt geconfigureerd via zijn providerconfiguratieobject, sluit het geheim dan niet ook in de app in. Twee kopieën lopen uiteen, en de divergentie presenteert zich als slechte inloggegevens in plaats van als duplicatie. Een widget of een tweede proces dat een andere status meldt heeft dezelfde verklaring: elk heeft de groep nodig, en elk moet de instellingen laden voordat het leest.

Stem de API af op het protocol

De ingebouwde manager draagt IPsec- en IKEv2-protocolobjecten. Hij wordt door extra velden geen generieke SSL VPN-client, en een niet-passend profiel kan netjes worden opgeslagen en toch nooit verbinden. Bepaal in welke categorie je valt voordat je de status onderzoekt, want een statusbug en een niet-ondersteund protocol zien er van buiten identiek uit.

Voor de volgende herstart is de checklist kort: laad de instellingen, lees de status, houd wijzigingsabonnementen op de voorgrond, bouw de referenties opnieuw op uit de gedeelde groep, en bevestig dat het protocolobject overeenkomt met de API die je hebt geïmplementeerd. Die lijst doorlopen kost een minuut; eraan raden kost een middag.