Dezelfde IKEv2-identiteit op twee iPhones? Ze verbinden om de beurt

Twee telefoons, één profiel en een patroon dat bovennatuurlijk lijkt tot iemand naar de gateway kijkt. Eén apparaat houdt de tunnel, de tweede verbindt, en de eerste verliest hem binnen enkele seconden. De eerste verbindt opnieuw en de tweede valt weg. Batterijbesparing, Wi-Fi-roaming en de NAT van de provider krijgen de schuld, terwijl de echte oorzaak in een tekstveld zit dat met al het andere is meegekopieerd. IKEv2 identificeert een peer aan de hand van een naam, en beide telefoons presenteren dezelfde.

De identiteit is de sleutel waaronder de server je opslaat

Binnen een IKEv2-uitwisseling geeft elke kant aan wie zij is: de initiator stuurt een lokale identificatie, de responder antwoordt met de zijne, en de responder controleert ook de identiteit die de initiator claimt tegen het beleid. De gateway houdt zijn status per identiteit bij in plaats van per apparaat, omdat een apparaat niet iets is dat hij kan zien. Twee telefoons met één identificatie komen daarom als één peer aan, en de tweede uitwisseling moet de eerste overschrijven. Het probleem verschijnt alleen terwijl beide in gebruik zijn, en daarom reproduceert een test met één telefoon het nooit.

Niets hiervan is een fout in de client. De client stuurde precies wat het profiel hem opdroeg te sturen.

Hoe de botsing er vanaf de gateway uitziet

Kijk naar de peer-lijst terwijl beide telefoons wakker en in gebruik zijn. Een botsing toont één vermelding waarvan het adres verandert wanneer de telefoons wisselen, en de teller van actieve sessies bereikt nooit twee. Het afbreken op verzoek ziet er anders uit, en ze onderscheiden vraagt één observatie in plaats van een theorie.

Schrijf beide gebeurtenissen met tijdstempels op terwijl het gebeurt. Een onderbreking die samenvalt met het verbinden van het andere toestel wijst op de identificatie, en een onderbreking die één inactief interval na het laatste pakket komt, wijst op een timer.

Waar de duplicaten vandaan komen

Eén werkende configuratie exporteren en alleen het serveradres aanpassen levert een tweede bestand op met de identiteit van het eerste bestand er nog in. Dat is de gebruikelijke weg naar deze fout, en hij gebeurt meestal bij het haastig onboarden van een kleine groep.

De veldnamen maken het makkelijk om dit te missen. De externe identificatie noemt de gateway die de telefoon verwacht, en die kopiëren is correct. De lokale identificatie noemt dit toestel bij de gateway, en die waarde kopiëren is het hele probleem.

Geef per apparaat een waarde uit

Gebruik iets dat uniek is voor het toestel en stabiel gedurende zijn hele levensduur, zoals de apparaatidentificatie uit de inventaris of een waarde die uw beheersysteem per inschrijving genereert. Een afdelingslabel, een gedeelde serviceaccountnaam of het e-mailadres van de gebruiker botsen allemaal zodra die persoon een tweede apparaat heeft.

Genereer de payload per apparaat in plaats van één bestand te verspreiden. Noteer welke waarde bij welk toestel hoort, zodat een vervanging het oude profiel niet herstelt en de nieuwe telefoon meteen weer in dezelfde botsing laat belanden.

Controleer ook de serverkant. Een gateway die de identiteit aan een vast tunneladres koppelt, kan nog steeds botsen wanneer twee verschillende identificaties dezelfde toewijzing krijgen, dus bevestig dat de pool ruimte heeft en dat toewijzingen niet per gebruiker vastgezet zijn.

Verifieer met beide telefoons wakker

Verbind de eerste, bereik een privébron, verbind dan de tweede en laat beide een minuut inactief. Beide sessies moeten blijven bestaan en de peer-lijst moet twee identiteiten tonen. Vergrendel en ontgrendel daarna elke telefoon om te bevestigen dat het inactieve geval zich nog goed gedraagt.

Als één sessie nog steeds één keer per dag wegvalt zonder dat er iets anders verbindt, is de identiteit niet langer de verdachte. Ga verder naar inactieve timers en sessielimieten van de server in plaats van het profiel opnieuw aan te passen.