FortiGate Azure kaaifernijing: peer SA-foarstel past net by it pleatslike belied
In wurkjende IKEv2-tunnel kin de ferfangende CHILD SA dochs ôfwize. Ferlykje it foarstel dat de fernijing echt ûnderhannelt, net dat wat de earste ping brûkte.
De tunnel kaam omheech, ferkear rûn, en letter seit it log peer SA proposal not match local policy. De measte minsken lêze dy rigel as bewiis dat de twa konfiguraasjes nea pasten. Meastentiids betsjut it eat smeller: se pasten foar de earste CHILD SA en holden op mei passen by de earste fernijing, om't de earste assosjaasje nea de útwikseling nedich hie dy't lettere dogge. Krekt dat ûnderskie bepaalt wêr't jo sjogge.
De earste CHILD SA erft, lettere ûnderhannelje
Yn IKEv2 wurdt de earste CHILD SA makke by IKE_AUTH, en syn kaaien wurde ôflaat fan it kaaimateriaal fan de IKE SA. Op dat stuit is der gjin aparte Diffie-Hellman-útwikseling, dus in PFS-groep dy't ien peer net akseptearje kin, wurdt gewoan noch net test. De tunnel liket sûn, om't de eask dêr't jo letter op falle sil nea test is.
In CHILD_SA-kaaifernijing is in oare berjochtrige. As PFS konfigurearre is, dogge de peers in nije kaaiútwikseling en moatte se it iens wurde oer in groep dy't beide kanten akseptearje, plus it ESP-foarstel foar de nije assosjaasje. Dat is it momint dat it misferstân sichtber wurdt, en dêrom neamt de flater in foarstel ynstee fan in rûte.
Dat “it wurke juster” seit jo neat oer it foarstel. It seit dat de earste útwikseling slagge, wat jo al wisten.
Lês de mislearre útwikseling, net de earste ping
Sammeleje earst fan beide kanten de slagge IKE-autentikaasje, de earste CHILD SA en de mislearre ferfanging foardat jo eat feroarje. Neam dan de operaasje krekt: IKE SA-kaaifernijing, IKE-herautentikaasje en CHILD SA-kaaifernijing binne trije ferskillende barrens, en “fase 2” beslacht se allegear yn gewoan petear.
Ferlykje de fjilden hjirûnder foar de ferbining dy't mislearre, net foar de tunnel yn 't algemien.
| Laach | Wearden om te ferlykjen |
|---|---|
| IKE | Ferzje, fersifering en yntegriteit of PRF-opset, DH-groep |
| IPsec / CHILD | ESP-fersifering en -yntegriteit, bedoelde PFS- of kaaiútwikselingsgroep |
| Beskerme ferkear | Pleatslike en fiere selektors, plus elke beliedsbasearre selektor-ynstelling |
Iepenje op it FortiGate it fase-2-foarstel, de PFS-ynstelling en de akseptearre DH-groepen foar dy tunnel. Lês de laden wearden ynstee fan se ôf te lieden út in ferbining dy't earder ta stân kaam. In skermôfbylding fan 'e GUI-side is swakker bewiis as de rinnende konfiguraasje, om't de twa nei in upgrade ferskille kinne. Eksportearje de seksje dy't jo feroare hawwe en bewarje dy by it ticket.
Azure syn standertbelied is noch altyd in belied
Gjin oanpaste belied oan 'e ferbining taheakke betsjut net dat Azure gjinien tapast. De ferbining falt werom op 'e standertfoarstel-set fan 'e gateway, dy't breder of smeller wêze kin as wat jo FortiGate biedt. As de twa sets oerlaapje foar IKE mar net foar ESP mei PFS, krije jo krekt dit mislearringspatroan.
Dizze allinnich-lêzen werjefte lit it belied sjen dat echt taheakke is, sûnder geheimen te fersprieden:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesBrûk jo echte boarnenammen. As in eksplisyt belied nedich is, set it dan op 'e ferbining-boarne. It is gjin skeakel foar de hiele gateway en it jildt net stil foar oare tunnels op deselde gateway.
Yn it portaal is de side Configuration fan dy ferbining it plak dêr't in oanpast IPsec/IKE-belied heart. Microsoft syn hânlieding foar oanpast belied listet de stipe parameters en SKU-easken op. Azure nimt ien folsleine kombinaasje per ferbining, dus jo spesifisearje de IKE-fjilden en de IPsec-fjilden tagelyk, net ien foar ien.
PFS is in eask, gjin skeakel om om te setten
As jo feiligensbasisline PFS easket, is de oplossing in groep dy't beide peers oan beide kanten akseptearje, útdrukt troch in passend belied. PFS útsette om de flater ferdwine te litten feroaret de feiligens-eigenskip dy't jo besochten te behâlden, en it komt letter meastentiids werom as in oar misferstân.
Ien Azure-spesifike falstrik: as jo GCM foar ESP kieze, moatte de fersifering- en yntegriteitskarren deselde GCM-algoritme en deselde kaailingte neame. In GCM-sifer mei in aparte yntegriteitsalgoritme minge jout in kombinaasje dy't de tsjinst ôfwiist, en dat liket op in misferstân tusken peers oant jo it belied goed lêze.
Kies de sterkste kombinaasje dy't beide einen stypje en jo eask tastean, en skriuw dy dan yn it feroaringsregister. De folgjende persoan sil ferlykje mei dat register, net mei in oantins oan in wurkjende tunnel. Set de PFS-groep en it ESP-foarstel deryn, net allinnich de namme fan it belied. As immen letter freget wêrom't in audit mislearre of wêrom't in kaaifernijing stadich is, antwurdet dy rigel op beide fragen.
Ferifiearje de útwikseling dy't mislearre
Plen de feroaring mei in werstelpaad, om't it bewurkjen fan it belied de tunnel ûnderbrekke kin dy't jo besykje te reparearjen. Nei't it ferkear werom is, wachtsje op of trigger in CHILD_SA-fernjijing en befêstigje dat de nije assosjaasje mei de bedoelde PFS-groep ta stân komt. Befêstigje dêrnei dat applikaasjeferkear der trochhinne trochgiet.
Twa falske spoaren binne it neamen wurdich. SA-libben binne pleatslike spesifikaasjes, dus ûngelikense wearden binne normaal en se feroarje ferpleatst allinnich wannear't it probleem ferskynt. DPD detektearret oft in peer libbet; it ferheegjen fan syn tiidlimit bringt ESP- of PFS-karrens net yn oerienstimming.
Registrearje it ûnderhannele resultaat en de folgjende barren nei de feroaring. As de ferbining no mislearret foar't de IKE-autentikaasje foltôge is, sjogge jo nei de IKE-ynstellingen dy't jo krekt bewurke hawwe, net nei de oarspronklike CHILD-fernjijingsflater.