FortiGate Azure ŝlosila renovigo: la peer SA propono ne kongruas kun la loka politiko
Funkcianta IKEv2 tunelo ankoraŭ povas malakcepti la anstataŭan CHILD SA. Komparu la proponon, kiun la renovigo efektive intertraktas, ne tiun, kiun uzis la unua ping.
La tunelo leviĝis, trafiko fluis, kaj poste la protokolo diras peer SA proposal not match local policy. Plej multaj homoj legas tiun linion kiel pruvon, ke la du agordoj neniam kongruis. Kutime ĝi signifas ion pli mallarĝan: ili kongruis por la unua CHILD SA kaj ĉesis kongrui ĉe la unua renovigo, ĉar la unua asocio neniam bezonis la interŝanĝon, kiun faras la postaj. Tiu distingo decidas, kie vi rigardu.
La unua CHILD SA heredas, la postaj intertraktas
En IKEv2 la komenca CHILD SA estas kreata dum IKE_AUTH, kaj ĝiaj ŝlosiloj deriviĝas el la ŝlosila materialo de la IKE SA. En tiu momento ne ekzistas aparta Diffie-Hellman interŝanĝo, do PFS grupo, kiun unu peer ne povas akcepti, simple ankoraŭ ne estas testata. La tunelo aspektas sana, ĉar la postulo, kiun vi poste malsukcesos, neniam estis testita.
CHILD_SA ŝlosila renovigo estas alia mesaĝsekvenco. Kiam PFS estas agordita, la peer efektivigas novan ŝlosilan interŝanĝon kaj devas konsenti pri grupo, kiun ambaŭ flankoj akceptas, plus la ESP propono por la nova asocio. Tiu estas la momento, kiam la malkongruo fariĝas videbla, kaj tial la eraro nomas proponon anstataŭ itineron.
Do “ĝi funkciis hieraŭ” diras al vi nenion pri la propono. Ĝi diras, ke la komenca interŝanĝo sukcesis, kion vi jam sciis.
Legu la malsukcesan interŝanĝon, ne la unuan ping
Antaŭ ol ŝanĝi ion, kolektu la sukcesan IKE aŭtentikigon, la komencan CHILD SA kaj la malsukcesan anstataŭon de ambaŭ flankoj. Poste nomu la operacion precize: IKE SA ŝlosila renovigo, IKE reaŭtentikigo kaj CHILD SA ŝlosila renovigo estas tri malsamaj eventoj, kaj “fazo 2” kovras ilin ĉiujn en ordinara konversacio.
Komparu la subajn kampojn por la konekto, kiu malsukcesis, ne por la tunelo ĝenerale.
| Tavolo | Valoroj kompareblaj |
|---|---|
| IKE | Versio, ĉifrado kaj integreco aŭ PRF aranĝo, DH grupo |
| IPsec / CHILD | ESP ĉifrado kaj integreco, celata PFS aŭ ŝlosilinterŝanĝa grupo |
| Protektata trafiko | Lokaj kaj malproksimaj selektiloj, plus ajna politikbazita selektila agordo |
En FortiGate malfermu la fazo-2 proponon, la PFS agordon kaj la akceptitajn DH grupojn por tiu tunelo. Legu la ŝargitajn valorojn anstataŭ dedukti ilin el konekto, kiu establiĝis pli frue. Ekrankopio de la GUI paĝo estas pli malforta pruvo ol la kuranta agordo, ĉar la du povas malkongrui post ĝisdatigo. Eksportu la sekcion, kiun vi ŝanĝis, kaj konservu ĝin kun la bileto.
La defaŭlta politiko de Azure restas politiko
Tio, ke neniu propra politiko estas alligita al la konekto, ne signifas, ke Azure aplikas neniun. La konekto refalas al la defaŭlta proponaro de la pordego, kiu povas esti pli larĝa aŭ pli mallarĝa ol tio, kion via FortiGate proponas. Se la du aroj interkovras por IKE sed ne por ESP kun PFS, vi ricevas ĝuste tiun ĉi malsukcesan ŝablonon.
Ĉi tiu nurlega vido montras la politikon efektive alligitan, sen elverŝi sekretojn:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesUzu viajn realajn rimednomojn. Kiam eksplicita politiko necesas, agordu ĝin sur la konekta rimedo. Ĝi ne estas pordeglarĝa ŝaltilo, kaj ĝi ne silente aplikiĝas al aliaj tuneloj sur la sama pordego.
En la portalo, la paĝo Configuration de tiu konekto estas la loko, kie iras propra IPsec/IKE politiko. La gvidilo de Microsoft pri propraj politikoj listigas la subtenatajn parametrojn kaj SKU postulojn. Azure prenas unu kompletan kombinaĵon por konekto, do vi specifas la IKE kampojn kaj la IPsec kampojn kune, ne unu post unu.
PFS estas postulo, ne ŝaltilo por turni
Se via sekureca bazlinio postulas PFS, la solvo estas grupo, kiun ambaŭ peer akceptas ambaŭflanke, esprimita per kongrua politiko. Malŝalti PFS por ke la eraro malaperu ŝanĝas la sekurecan econ, kiun vi klopodis konservi, kaj ĝi kutime reaperas poste kiel alia malkongruo.
Unu Azure-specifa kaptilo: kiam vi elektas GCM por ESP, la elektoj de ĉifrado kaj integreco devas nomi la saman GCM algoritmon kaj la saman ŝlosilan longon. Miksi GCM ĉifron kun aparta integreca algoritmo produktas kombinaĵon, kiun la servo malakceptas, kaj tio aspektas kiel peer-malkongruo ĝis vi atente legos la politikon.
Elektu la plej fortan kombinaĵon, kiun ambaŭ finoj subtenas kaj via postulo permesas, poste skribu ĝin en la ŝanĝprotokolon. La sekva persono komparos kun tiu protokolo, ne kun memoro pri funkcianta tunelo. Enmetu la PFS grupon kaj la ESP proponon, ne nur la politikan nomon. Kiam iu poste demandos, kial aŭdito malsukcesis aŭ kial renovigo estas malrapida, tiu linio respondas ambaŭ demandojn.
Kontrolu la interŝanĝon, kiu malsukcesis
Planu la ŝanĝon kun reakira vojo, ĉar redakti la politikon povas interrompi la tunelon, kiun vi provas ripari. Post kiam trafiko revenos, atendu aŭ ekigu CHILD_SA renovigon kaj konfirmu, ke la nova asocio establiĝis kun la celata PFS grupo. Poste konfirmu, ke aplika trafiko daŭras tra ĝi.
Du falsaj spuroj indas esti nomataj. SA vivdaŭroj estas lokaj specifikoj, do malegalaj valoroj estas normalaj kaj ŝanĝi ilin nur movas, kiam la problemo aperas. DPD detektas, ĉu peer vivas; plialtigi ĝian limtempon ne vicigas ESP aŭ PFS elektojn.
Registru la intertraktitan rezulton kaj la sekvan eventon post la ŝanĝo. Se la konekto nun malsukcesas antaŭ ol IKE aŭtentikigo finiĝos, vi rigardas la IKE agordojn, kiujn vi ĵus redaktis, ne la originan CHILD-renovigan malsukceson.