FortiGate Azure-herlewing: peer SA-voorstel pas nie by die plaaslike beleid nie

Die tonnel het opgekom, verkeer het gevloei, en later sê die log peer SA proposal not match local policy. Die meeste mense lees daardie reël as bewys dat die twee konfigurasies nooit gepas het nie. Dit beteken gewoonlik iets smaller: hulle het vir die eerste CHILD SA gepas en opgehou pas by die eerste hernuwing, want die eerste assosiasie het nooit die uitruiling nodig gehad wat latere wel doen nie. Daardie onderskeid bepaal waar jy kyk.

Die eerste CHILD SA erf, latere onderhandel

In IKEv2 word die aanvanklike CHILD SA tydens IKE_AUTH geskep, en sy sleutels word van die IKE SA-sleutelmateriaal afgelei. Daar is op daardie punt geen aparte Diffie-Hellman-uitruiling nie, so ’n PFS-groep wat een peer nie kan aanvaar nie, word eenvoudig nog nie getoets nie. Die tonnel lyk gesond omdat die vereiste wat jy later gaan faal nooit getoets is nie.

’n CHILD_SA-herlewing is ’n ander boodskapreeks. Wanneer PFS gekonfigureer is, voer die peers ’n vars sleuteluitruiling uit en moet hulle ooreenkom op ’n groep wat beide kante aanvaar, plus die ESP-voorstel vir die nuwe assosiasie. Dit is die oomblik waarop die wanverhouding sigbaar word, en dit is waarom die fout ’n voorstel noem eerder as ’n roete.

Dus sê “dit het gister gewerk” vir jou niks oor die voorstel nie. Dit sê die aanvanklike uitruiling het geslaag, wat jy al geweet het.

Lees die mislukte uitruiling, nie die eerste ping nie

Versamel die suksesvolle IKE-verifikasie, die aanvanklike CHILD SA en die mislukte vervanging van beide kante voordat jy iets verander. Benoem dan die bewerking presies: IKE SA-herlewing, IKE-herverifikasie en CHILD SA-herlewing is drie verskillende gebeure, en “fase 2” dek hulle almal in gewone gesprekke.

Vergelyk die velde hieronder vir die verbinding wat misluk het, nie vir die tonnel in die algemeen nie.

Op FortiGate maak jy die fase-2-voorstel, die PFS-instelling en die aanvaarde DH-groepe vir daardie tonnel oop. Lees die gelaaide waardes eerder as om hulle af te lei uit ’n verbinding wat vroeër tot stand gekom het. ’n Skermkiekie van die GUI-bladsy is swakker bewyse as die lopende konfigurasie, want die twee kan ná ’n opgradering verskil. Eksporteer die afdeling wat jy verander het en hou dit by die kaartjie.

Azure se standaardbeleid is steeds ’n beleid

Geen pasgemaakte beleid wat aan die verbinding geheg is nie beteken nie dat Azure geen toepas nie. Die verbinding val terug op die gateway se standaardvoorstelstel, wat wyer of nouer kan wees as wat jou FortiGate bied. As die twee stelle oorvleuel vir IKE maar nie vir ESP met PFS nie, kry jy presies hierdie foutpatroon.

Hierdie lees-alleen-aansig wys die beleid wat werklik geheg is, sonder om geheime uit te stort:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Gebruik jou werklike hulpbronname. Wanneer ’n eksplisiete beleid nodig is, stel dit op die verbindingshulpbron. Dit is nie ’n gateway-wye skakelaar nie, en dit geld nie stilweg vir ander tonnels op dieselfde gateway nie.

In die portaal is daardie verbinding se Configuration-bladsy waar ’n pasgemaakte IPsec/IKE-beleid hoort. Microsoft se gids vir pasgemaakte beleide lys die ondersteunde parameters en SKU-vereistes. Azure neem een volledige kombinasie per verbinding, so jy spesifiseer die IKE-velde en die IPsec-velde saam, nie een op ’n slag nie.

PFS is ’n vereiste, nie ’n skakelaar om om te flip nie

As jou sekuriteitsbasislyn PFS vereis, is die oplossing ’n groep wat beide peers aan beide kante aanvaar, uitgedruk deur ’n passende beleid. Om PFS af te skakel sodat die fout verdwyn, verander die sekuriteitseienskap wat jy wou behou, en dit verskyn gewoonlik later weer as ’n ander wanverhouding.

Een Azure-spesifieke lokval: wanneer jy GCM vir ESP kies, moet die enkripsie- en integriteitskeuses dieselfde GCM-algoritme en sleutellengte noem. Om ’n GCM-syfer met ’n aparte integriteitsalgoritme te meng, lewer ’n kombinasie wat die diens verwerp, wat soos ’n peer-wanverhouding lyk totdat jy die beleid noukeurig lees.

Kies die sterkste kombinasie wat beide kante ondersteun en jou vereiste toelaat, en skryf dit dan in die veranderingsrekord neer. Die volgende persoon sal teen daardie rekord vergelyk, nie teen ’n herinnering aan ’n werkende tonnel nie. Sit die PFS-groep en die ESP-voorstel daarin, nie net die beleid se naam nie. Wanneer iemand later vra waarom ’n oudit misluk het of waarom ’n herlewing stadig is, antwoord daardie reël albei vrae.

Verifieer die uitruiling wat misluk het

Beplan die verandering met ’n herstelpad, want die wysiging van die beleid kan die tonnel onderbreek wat jy probeer regmaak. Nadat verkeer terugkeer, wag vir of aktiveer ’n CHILD_SA-hernuwing en bevestig dat die nuwe assosiasie met die beoogde PFS-groep tot stand gekom het. Bevestig dan dat toepassingsverkeer daardeur voortduur.

Twee dwaalspore is die moeite werd om te noem. SA-lewensduur is plaaslike spesifikasies, so ongelyke waardes is normaal en om hulle te verander skuif net wanneer die probleem verskyn. DPD bepaal of ’n peer lewendig is; om die tydlimiet te verhoog, pas nie ESP- of PFS-keuses in lyn nie.

Teken die onderhandelde resultaat en die volgende gebeurtenis ná die verandering aan. As die verbinding nou misluk voordat IKE-verifikasie voltooi is, kyk jy na die IKE-instellings wat jy pas verander het, nie na die oorspronklike CHILD-hernuwingsfout nie.