To telefonar, éin profil og eit mønster som verkar overnaturleg til nokon ser på gatewayen. Éi eining held tunnelen, den andre koplar til, og den første mistar han innan sekund. Den første koplar til på nytt, og den andre fell ut. Batterisparing, Wi-Fi-roaming og NAT-en til operatøren får skulda, medan den eigentlege årsaka sit i eit tekstfelt som vart kopiert med alt anna. IKEv2 identifiserer ein peer ved eit namn, og begge telefonane viser det same.

Identiteten er nøkkelen serveren lagrar deg under

Inne i ein IKEv2-utveksling oppgir kvar side kven ho er: initiativtakaren sender ein lokal identifikator, responderaren svarar med sin eigen, og responderaren kontrollerer òg identiteten initiativtakaren hevda, mot policyen. Gatewayen held tilstanden sin per identitet i staden for per eining, fordi ei eining ikkje er noko han kan sjå. To telefonar med éin identifikator kjem difor som éin peer, og den andre utvekslinga må skriva over den første. Problemet viser seg berre medan begge er i bruk, og difor gjenskaper ein test med éin telefon det aldri.

Ingenting av dette er ein feil i klienten. Klienten sende nøyaktig det profilen bad han senda.

Korleis kollisjonen ser ut frå gatewayen

Sjå på peer-lista medan begge telefonane er vakne og i bruk. Ein kollisjon viser éi oppføring der adressa endrar seg når telefonane byter, og teljaren for aktive økter når aldri to. Nedtaking på førespurnad ser annleis ut, og å skilja dei krev éi observasjon i staden for ein teori.

ObservationShared identityIdle teardown
Peer entries while both are awakeOne, with a changing addressOne per phone, or none
What triggers the dropThe other device connectingTime without traffic
What restores itThe other device disconnectingAny app needing the tunnel

Skriv ned begge hendingane med tidsstempel medan det skjer. Eit brot som fell saman med tilkoplinga til den andre eininga, peikar på identifikatoren, og eit brot som kjem éin inaktiv periode etter den siste pakken, peikar på ein timer.

Kvar duplikata kjem frå

Å eksportera éin fungerande konfigurasjon og berre redigera serveradressa gjev ei andre fil der identiteten til den første fila framleis er inne. Det er den vanlege vegen til denne feilen, og han skjer vanlegvis når ei lita gruppe vert teken i bruk i all hast.

Feltnamna gjer det lett å oversjå. Den eksterne identifikatoren namngir gatewayen telefonen ventar, og å kopiera han er rett. Den lokale identifikatoren namngir denne eininga overfor gatewayen, og å kopiera den verdien er heile problemet.

Utsted ein verdi per eining

Bruk noko som er unikt for eininga og stabilt gjennom heile levetida, som einingsidentifikatoren frå inventaret eller ein verdi styringssystemet ditt genererer per registrering. Ei avdelingsetikett, eit delt tenestekontonamn eller e-postadressa til brukaren kolliderer alle så snart den personen har ei andre eining.

Generer nyttelasta per eining i staden for å distribuera éi fil. Noter kva verdi som høyrer til kva eining, slik at ei utskifting ikkje gjenopprettar den gamle profilen og sender den nye telefonen rett tilbake i same kollisjon.

Kontroller serversida òg. Ein gateway som mappar identiteten til ei fast tunneladresse kan framleis kollidera når to ulike identifikatorar får same tildeling, så stadfest at poolen har plass og at tildelingane ikkje er låste per brukar.

Verifiser med begge telefonane vakne

Kopla til den første, nå ein privat ressurs, kopla deretter til den andre og la begge vera inaktive i eitt minutt. Begge øktene skal vara, og peer-lista skal visa to identitetar. Lås og lås opp kvar telefon for å stadfesta at inaktivtilfellet framleis oppfører seg rett.

Viss éi enkelt økt framleis fell ut éin gong om dagen utan at noko anna koplar til, er ikkje identiteten lenger den mistenkte. Gå vidare til inaktive timar og øktsgrenser på serveren i staden for å redigera profilen på nytt.

Relaterte artiklar