IKEv2 op Windows en FortiGate: drie instellingen die mensen samenvoegen

Een IKEv2-overeenkomst tussen een Windows-client en een FortiGate-gateway blijft mislukken, en de zoektocht naar een nummer dat niet klopt levert een langere lijst nummers op. De lijst wordt pas beheersbaar wanneer hij in drie regels wordt gesplitst die onafhankelijk falen: de sleuteluitwisseling die IKE beschermt, de beveiliging die op de CHILD SA wordt toegepast, en de authenticatie die bewijst wie elke kant is. Groepsnummers komen in twee van die regels voor en betekenen verschillende dingen.

Drie regels die onafhankelijk falen

De eerste regel is de sleuteluitwisseling binnen IKE zelf, die de sleutels maakt die de onderhandeling beschermen. De tweede is het voorstel voor de CHILD SA, dat het verkeer beschermt dat de tunnel draagt. De derde is authenticatie, die bepaalt wat elke kant presenteert en hoe de andere kant dat valideert.

Fouten landen op verschillende plaatsen. Een uitwisselingsfout stopt de onderhandeling voordat er een tunnel bestaat. Een CHILD SA-fout treedt op nadat authenticatie is geslaagd, soms alleen bij een sleutelvernieuwing. Een authenticatiefout kan in de logboeken op een uitwisselingsfout lijken als je alleen de eerste fout leest.

De regels scheiden is geen boekhouding. Het verandert welke instelling de moeite waard is om te wijzigen, en het voorkomt de duurste stap in dit hele gebied, namelijk werkende certificaten opnieuw genereren om een voorstelverschil te verhelpen. Een wijziging in één regel mag de andere twee nooit dwingen mee te veranderen. Die onafhankelijkheid is het hele punt van ze apart opschrijven.

Wat de twee Windows-velden besturen

Windows houdt twee velden gescheiden: DHGroup configureert de IKE-uitwisseling zelf, terwijl PfsGroup het IPsec-beleid configureert dat het verkeer in de tunnel beschermt. Ze horen bij verschillende fasen. Een Windows IKE-veld vergelijken met een FortiGate-fase-2-waarde test het verkeerde paar, en de nummers kunnen overeenkomen terwijl de onderliggende uitwisseling nog steeds mislukt.

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

De tweede en derde opdracht rapporteren de beveiligingskoppelingen die werkelijk bestaan, en dat is het dichtst bij een antwoord dat een client u kan geven. Een hoofdmodus-koppeling zonder snelmodus-koppeling is een CHILD SA-probleem, en het is de signatuur van een fase-2-verschil en niet van een certificaatprobleem.

Noteer wat is aangeboden en wat in één poging is geselecteerd. Een aangeboden lijst met een aanvaardbaar voorstel en een geselecteerd voorstel dat niet overeenkomt met het beleid van de gateway is een configuratiegeschil, geen interoperabiliteitsraadsel.

Een elliptische-krommegroep kiest uw signatuursleutel niet

De hardnekkigste verkeerde gevolgtrekking in dit gebied is dat het kiezen van een DH-groep op een elliptische kromme een certificaat op een elliptische kromme vereist. Een DH-groep levert materiaal voor sleuteluitwisseling; het signatuuralgoritme wordt onderhandeld door het authenticatieraamwerk, en dat zijn twee afzonderlijke beslissingen in IKEv2.

RFC 7427 bestaat juist omdat die beslissingen eerder verweven waren, en definieert hoe signatuuralgoritmen onafhankelijk van de sleuteluitwisseling worden aangekondigd en geselecteerd. Een gateway kan tegelijk een krommegroep en een keuze aan signatuurschema's ondersteunen.

Dus wanneer een onderhandeling na een groepswijziging mislukt, kijk dan naar de authenticatiemethode voordat u naar het sleuteltype van het certificaat kijkt. Een certificaat vervangen is een langzame en riskante bewerking die zelden het antwoord is, en het als eerste doen vernietigt uw vermogen om te bepalen welke wijziging echt hielp. Lees de authenticatieregel voordat u het certificaatarchief aanraakt.

Houd beide in afzonderlijke regels van het overeenkomstblad en de fout houdt op verleidelijk te zijn. De ene regel somt groepen op, de andere signatuurschema's en identiteiten, en geen van beide is bewijs over de andere.

Plaats elke privésleutel bij de werkelijke eigenaar

Een gateway die zijn eigen certificaat presenteert, heeft de bijbehorende privésleutel nodig. Een peer die een keten valideert, heeft het CA-certificaat nodig en heeft juist niet de signatuursleutel van de CA nodig. Deze drie artefacten door elkaar halen is hoe mensen een privé-CA-sleutel in een VPN-apparaat importeren om een certificaat in een andere categorie te laten verschijnen.

Op FortiOS zijn de rollen verschillend: een lokaal certificaat met zijn sleutel, een extern certificaat dat wordt gebruikt om een peer te identificeren, en een externe CA-vermelding die vertrouwen vestigt in certificaten die die CA heeft ondertekend. Een externe CA-vermelding zonder privésleutel is niet onvolledig; hij is correct voor zijn doel.

Geïmporteerde CA-signatuursleutels vergroten de bevoegdheid van iedereen die dat apparaat kan lezen. Ze lossen ook de gewone peer-validatie niet op, omdat validatie het openbare certificaat en de vertrouwensbeslissing nodig heeft, niet het vermogen om nieuwe certificaten uit te geven.

Houd de CA-signatuursleutel bij het proces van de uitgever zelf, en noteer welk apparaat welke sleutel heeft. Een korte tabel met eigenaren is meer waard dan een langere tabel met algoritmen wanneer een audit vraagt wie zich voor wie kon uitgeven. Niemand importeert een sleutel waarvan hij weet dat die alleen voor de inventaris is. Schrijf de inventaris vóór het incident, niet erna.