IKEv2 en Windows kaj FortiGate: tri agordoj, kiujn homoj kunfandas
IKE-ŝlosilinterŝanĝo, protekto de CHILD SA kaj aŭtentigo de la partnero estas tri apartaj vicoj. Samaj grupnumeroj en du dialogoj ne kunfandas ilin.
Interkonsento IKEv2 inter Windows-kliento kaj FortiGate-pordego daŭre malsukcesas, kaj la serĉado de neegala numero produktas pli longan liston de numeroj. La listo fariĝas regebla nur kiam ĝi dividiĝas en tri vicojn, kiuj malsukcesas sendepende: la ŝlosilinterŝanĝo, kiu protektas IKE, la protekto aplikata al la CHILD SA, kaj la aŭtentigo, kiu pruvas, kiu estas ĉiu flanko. Grupnumeroj aperas en du el tiuj vicoj kaj signifas malsamajn aferojn.
Tri vicoj, kiuj malsukcesas sendepende
La unua vico estas la ŝlosilinterŝanĝo ene de IKE mem, kiu produktas la ŝlosilojn, kiuj protektas la intertraktadon. La dua estas la propono por la CHILD SA, kiu protektas la trafikon, kiun la tunelo portas. La tria estas aŭtentigo, kiu decidas, kion ĉiu flanko prezentas kaj kiel la alia ĝin validigas.
Malsukcesoj falas en malsamajn lokojn. Interŝanĝa malsukceso haltigas la intertraktadon antaŭ ol ekzistas ajna tunelo. CHILD SA-malsukceso okazas post kiam aŭtentigo sukcesas, foje nur ĉe ŝlosila renovigo. Aŭtentiga malsukceso povas en la protokoloj aspekti kiel interŝanĝa malsukceso, se vi legas nur la unuan eraron.
Dividi la vicojn ne estas librotenado. Ĝi ŝanĝas, kiun agordon indas ŝanĝi, kaj ĝi malhelpas la plej multekostan movon en ĉi tiu tuta kampo, nome regeneri funkciantajn atestilojn por ripari malkongruon en la propono. Ŝanĝo de unu vico neniam devus devigi la aliajn du ŝanĝiĝi kun ĝi. Tiu sendependeco estas la tuta celo skribi ilin aparte.
Kion regas la du kampoj de Windows
Windows tenas du kampojn aparte: DHGroup agordas la IKE-interŝanĝon mem, dum PfsGroup agordas la IPsec-politikon, kiu protektas la trafikon en la tunelo. Ili apartenas al malsamaj fazoj. Kompari Windows-IKE-kampon kun FortiGate-valoro de fazo 2 testas la malĝustan paron, kaj la numeroj povas kongrui dum la suba interŝanĝo ankoraŭ malsukcesas.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSALa dua kaj tria komandoj raportas la sekurecajn asociojn, kiuj efektive ekzistas, kaj tio estas la plej proksima afero al respondo, kiun kliento povas doni al vi. Ĉefreĝima asocio sen rapidreĝima asocio estas CHILD SA-problemo, kaj ĝi estas la signo de malkongruo de fazo 2, ne de atestila problemo.
Notu, kio estis proponita kaj kio elektita en unu provo. Proponita listo, kiu enhavas akcepteblan proponon, kaj elektita propono, kiu ne kongruas kun la politiko de la pordego, estas agorda malkonsento, ne mistero de interagado.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Elipsa-kurba grupo ne elektas vian subskriban ŝlosilon
La plej persista malĝusta konkludo en ĉi tiu kampo estas, ke elekti DH-grupon de elipsa kurbo postulas atestilon de elipsa kurbo. DH-grupo provizas materialon por ŝlosilinterŝanĝo; la subskriba algoritmo estas intertraktata de la aŭtentiga kadro, kaj tiuj estas du apartaj decidoj en IKEv2.
RFC 7427 ekzistas ĝuste ĉar tiuj decidoj antaŭe estis interplektitaj, kaj ĝi difinas, kiel subskribaj algoritmoj estas anoncitaj kaj elektitaj sendepende de la ŝlosilinterŝanĝo. Pordego povas samtempe subteni kurbogrupon kaj elekton de subskribaj skemoj.
Do kiam intertraktado malsukcesas post grupa ŝanĝo, rigardu la aŭtentigan metodon antaŭ ol rigardi la ŝlosiltipon de la atestilo. Ŝanĝi atestilon estas malrapida kaj riska operacio, kiu malofte estas la respondo, kaj fari ĝin unue detruas vian kapablon konstati, kiu ŝanĝo fakte helpis. Legu la aŭtentigan vicon antaŭ ol tuŝi la atestilan konservejon.
Tenu ambaŭ en apartaj vicoj de la interkonsenta folio kaj la eraro ĉesos esti tentiga. Unu vico listigas grupojn, la alia listigas subskribajn skemojn kaj identecojn, kaj neniu estas pruvo pri la alia.
Metu ĉiun privatan ŝlosilon ĉe ĝia efektiva posedanto
Pordego, kiu prezentas sian propran atestilon, bezonas la privatan ŝlosilon, kiu kongruas kun ĝi. Partnero, kiu validigas ĉenon, bezonas la CA-atestilon kaj precize ne bezonas la subskriban ŝlosilon de la CA. Konfuzi tiujn tri artefaktojn estas kiel homoj finas importi privatan CA-ŝlosilon en VPN-aparaton por igi atestilon aperi en alia kategorio.
En FortiOS la roloj estas apartaj: loka atestilo kun sia ŝlosilo, fora atestilo uzata por identigi partneron, kaj enskribo de fora CA, kiu starigas fidon al atestiloj, kiujn tiu CA subskribis. Enskribo de fora CA sen privata ŝlosilo ne estas nekompleta; ĝi estas ĝusta por sia celo.
Importitaj CA-subskribaj ŝlosiloj larĝigas la aŭtoritaton de iu ajn, kiu povas legi tiun aparaton. Ili ankaŭ ne solvas ordinaran partneran validigadon, ĉar validigado bezonas la publikan atestilon kaj la fidan decidon, ne la kapablon eldoni novajn atestilojn.
Tenu la CA-subskriban ŝlosilon ĉe la procezo de la eldonanto mem, kaj notu, kiun ŝlosilon tenas kiu aparato. Mallonga tabelo de posedantoj valoras pli ol pli longa tabelo de algoritmoj, kiam revizio demandas, kiun povus imiti kiun. Neniu importas ŝlosilon, kiun li scias estas nur por inventaro. Skribu la inventaron antaŭ la okazaĵo, ne post ĝi.