Waarom je IPsec-tunnel werkt tot de eerste CHILD SA-sleutelvernieuwing

De tunnel kwam omhoog, de ping antwoordde en iedereen tekende af. Vier uur later valt de sessie weg, de peers loggen een voorstel- of sleuteluitwisselingsfout, en de eerste veronderstelling is dat er iets op het netwerk is veranderd. Er is niets veranderd. Een tunnel die verkeer draagt, heeft bewezen dat de twee peers het eens zijn over hoe ze authenticeren en hoe ze de eerste onderliggende associatie beschermen, en hij heeft niets bewezen over de sleuteluitwisseling die ze bij de vernieuwing zullen eisen. De mismatch zit in de kloof tussen die twee gebeurtenissen.

Verbonden betekent niet dat de PFS-instellingen overeenkomen

Met IKEv2 wordt de eerste onderliggende associatie tijdens de authenticatie-uitwisseling aangemaakt, en de sleutels worden afgeleid uit materiaal dat de IKE-associatie al heeft geproduceerd. Voor die onderliggende associatie vindt geen aparte Diffie-Hellman-uitwisseling plaats, dus een beleid dat er bij de vernieuwing een eist, wordt bij het opkomen niet getest.

De vernieuwing is een andere uitwisseling. Wanneer de sleutel van een onderliggende associatie wordt vernieuwd, kunnen de peers een nieuwe sleuteluitwisseling doen met de groep die in hun voorstellen staat, en dat is het eerste moment waarop de groepinstellingen worden vergeleken. Twee peers die het oneens zijn, kunnen dus authenticeren, een onderliggende associatie installeren en verkeer doorlaten, en daarna bij de vernieuwing falen.

Waar de mismatch zich in de voorstelstring verbergt

In strongSwan wordt de groep aan het onderliggende voorstel toegevoegd, daarom ziet een string als aes256gcm16-prfsha256-ecp256 eruit als een coderingskeuze maar draagt hij ook een eis voor sleuteluitwisseling. Een peer die alleen aes256gcm16-prfsha256 aanbiedt, heeft die eis niet, en de twee lijsten overlappen op codering terwijl ze verschillen op de uitwisseling.

Lees het onderliggende voorstel en het IKE-voorstel als aparte lijsten. Een groep die in de IKE-lijst voorkomt, zegt niets over de onderliggende lijst, en het ene bewerken terwijl je het andere leest is de gebruikelijke manier waarop dit gemist wordt.

Lees de fout, niet het bestand dat je hebt bewerkt

Zoek de notify die de uitwisseling beëindigde. Een onderliggende sleutelvernieuwing die »geen aanvaardbaar voorstel« teruggeeft, wijst op de voorstellijsten; een vernieuwingsverzoek dat nooit antwoord krijgt, wijst op het pad of op een peer die stopte met luisteren. Die twee vragen om verschillende correcties, en de formulering van de logregel scheidt ze.

Bevestig de draaiende configuratie en niet die op schijf. Een bestand dat is opgeslagen maar niet geladen, of een verbinding die opnieuw uit een andere include is gelezen, levert een mismatch op die geen enkele bewerking van het zichtbare bestand kan verhelpen.

Drie gebeurtenissen die allemaal sleutelvernieuwing worden genoemd

Het vernieuwen van de sleutel van de IKE-associatie, IKE-herauthenticatie en het vernieuwen van de sleutel van de onderliggende associatie zijn aparte bewerkingen met aparte voorstelregels. Een fout die bij een van hen wordt gemeld, zegt niets rechtstreeks over de andere, en een log die ze mengt, leest als één terugkerend defect terwijl het er drie zijn.

Let op welke gebeurtenis de peer noemt, en controleer dan alleen de voorstellen voor die gebeurtenis. Wijzig één lijst, herlaad en forceer dezelfde gebeurtenis opnieuw. Als het log een herauthenticatie noemt, is het IKE-voorstel het voorstel dat je moet lezen. Als het een onderliggende sleutelvernieuwing noemt, draagt het onderliggende voorstel de groep die ertoe doet.

Vernieuwing uitschakelen is geen oplossing

De vernieuwingstijd op nul zetten onderdrukt de uitwisseling die faalt, en de tunnel overleeft daarna tot hij wordt afgebroken of de peer opnieuw start. Wat je hebt gekocht, is een langer levende sleutel en een mismatch die je opnieuw zult tegenkomen tijdens een migratie, een audit of een leveranciersupdate. Hetzelfde geldt voor levensduren die veel verder worden opgerekt dan het beleid dat de andere kant verwacht.

Lijn de voorstellen in plaats daarvan uit. Kies een groep die beide peers implementeren, zet die aan beide kanten in het onderliggende voorstel, en houd het vernieuwingsbeleid binnen het bereik dat de organisatie werkelijk eist.

Bewijs het met de uitwisseling die faalde

Verkort de onderliggende vernieuwingstijd in een onderhoudsvenster zodat de gebeurtenis in minuten komt in plaats van uren, of start een handmatige onderliggende sleutelvernieuwing. Let daarna op een geslaagde vernieuwing en bevestig dat verkeer er doorheen blijft gaan, want een nieuwe handshake die een onderliggende associatie installeert maar de applicatiestroom laat vallen is een ander defect.

Herstel daarna de normale levensduur en bewaar beide gebeurtenisregistraties, de mislukte en de geslaagde. Het bewijs dat je wilt, is dat de verbinding haar eigen levenscyclus overleeft, niet dat ze een ping overleefde.