FortiGate Azure -avaimen uusinta: peer SA -ehdotus ei vastaa paikallista käytäntöä
Toimiva IKEv2-tunneli voi silti hylätä korvaavan CHILD SA:n. Vertaa ehdotusta, josta uusinta todella neuvottelee, älä sitä, jota ensimmäinen ping käytti.
Tunneli nousi, liikenne kulki, ja myöhemmin loki sanoo peer SA proposal not match local policy. Useimmat lukevat tuon rivin todisteena siitä, etteivät kaksi kokoonpanoa koskaan täsmänneet. Yleensä se tarkoittaa kapeampaa asiaa: ne täsmäsivät ensimmäisen CHILD SA:n osalta ja lakkasivat täsmäämästä ensimmäisessä uusinnassa, koska ensimmäinen assosiaatio ei koskaan tarvinnut vaihtoa, jonka myöhemmät tekevät. Juuri tämä ero ratkaisee, mistä etsiä.
Ensimmäinen CHILD SA perii, myöhemmät neuvottelevat
IKEv2:ssa alkuperäinen CHILD SA luodaan IKE_AUTHin aikana ja sen avaimet johdetaan IKE SA:n avainmateriaalista. Tuossa vaiheessa ei ole erillistä Diffie-Hellman-vaihtoa, joten PFS-ryhmää, jota toinen peer ei voi hyväksyä, ei yksinkertaisesti vielä testata. Tunneli näyttää terveeltä, koska vaatimusta, jonka kohdalla myöhemmin epäonnistut, ei koskaan testattu.
CHILD_SA:n avaimen uusinta on erilainen viestijakso. Kun PFS on määritetty, peerit tekevät uuden avainvaihdon ja niiden on sovittava ryhmästä, jonka molemmat osapuolet hyväksyvät, sekä uuden assosiaation ESP-ehdotuksesta. Juuri silloin epäjohdonmukaisuus tulee näkyväksi, ja siksi virhe nimeää ehdotuksen eikä reitin.
Joten “eilen se toimi” ei kerro sinulle mitään ehdotuksesta. Se kertoo, että alkuvaihto onnistui, minkä tiesit jo.
Lue epäonnistunut vaihto, älä ensimmäistä pingiä
Kerää molemmista päistä onnistunut IKE-todennus, alkuperäinen CHILD SA ja epäonnistunut korvaaja ennen kuin muutat mitään. Nimeä sitten toimenpide täsmällisesti: IKE SA:n avaimen uusinta, IKE-uudelleentodennus ja CHILD SA:n avaimen uusinta ovat kolme eri tapahtumaa, ja “vaihe 2” kattaa ne kaikki arkikielessä.
Vertaa alla olevia kenttiä epäonnistuneen yhteyden osalta, älä tunnelin yleisesti.
| Kerros | Vertailtavat arvot |
|---|---|
| IKE | Versio, salaus ja eheys tai PRF-järjestely, DH-ryhmä |
| IPsec / CHILD | ESP:n salaus ja eheys, aiottu PFS- tai avainvaihtoryhmä |
| Suojattu liikenne | Paikalliset ja etävalitsimet sekä mahdollinen käytäntöpohjainen valitsinasetus |
Avaa FortiGatessa kyseisen tunnelin vaihe-2-ehdotus, PFS-asetus ja hyväksytyt DH-ryhmät. Lue ladatut arvot sen sijaan, että päättelet ne aiemmin muodostetusta yhteydestä. GUI-sivun kuvakaappaus on heikompi todiste kuin käynnissä oleva kokoonpano, koska ne voivat erota päivityksen jälkeen. Vie muuttamasi osio ja säilytä se tiketin kanssa.
Azuren oletuskäytäntö on yhä käytäntö
Se, ettei yhteyteen ole liitetty mukautettua käytäntöä, ei tarkoita, ettei Azure sovella mitään. Yhteys palaa yhdyskäytävän oletusehdotusjoukkoon, joka voi olla laajempi tai kapeampi kuin mitä FortiGatesi tarjoaa. Jos joukot menevät päällekkäin IKE:n osalta mutta eivät ESP:n osalta PFS:n kanssa, saat juuri tämän epäonnistumiskuvion.
Tämä vain luku -näkymä näyttää todella liitetyn käytännön paljastamatta salaisuuksia:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesKäytä resurssiesi oikeita nimiä. Kun nimenomaista käytäntöä tarvitaan, aseta se yhteyden resurssiin. Se ei ole koko yhdyskäytävän kytkin, eikä se sovellu hiljaisesti muihin saman yhdyskäytävän tunneleihin.
Portaalissa Configuration-sivu on se paikka, johon kyseisen yhteyden mukautettu IPsec/IKE-käytäntö kuuluu. Microsoftin mukautettujen käytäntöjen opas luettelee tuetut parametrit ja SKU-vaatimukset. Azure ottaa yhden täydellisen yhdistelmän yhteyttä kohden, joten määrität IKE-kentät ja IPsec-kentät yhdessä, et yksi kerrallaan.
PFS on vaatimus, ei kytkin, jota käännetään
Jos tietoturvasi perustaso edellyttää PFS:ää, ratkaisu on ryhmä, jonka molemmat peerit hyväksyvät molemmilla puolilla, ilmaistuna vastaavalla käytännöllä. PFS:n sammuttaminen virheen poistamiseksi muuttaa sitä turvaominaisuutta, jota yritit säilyttää, ja se palaa yleensä myöhemmin erilaisena epäjohdonmukaisuutena.
Yksi Azure-kohtainen ansa: kun valitset ESP:lle GCM:n, salauksen ja eheyden valintojen on nimettävä sama GCM-algoritmi ja sama avaimen pituus. GCM-salakirjoituksen sekoittaminen erilliseen eheysalgoritmiin tuottaa yhdistelmän, jonka palvelu hylkää, ja se näyttää peerien epäjohdonmukaisuudelta, kunnes luet käytännön tarkasti.
Valitse vahvin yhdistelmä, jota molemmat päät tukevat ja vaatimuksesi sallii, ja kirjaa se sitten muutosrekisteriin. Seuraava henkilö vertaa siihen rekisteriin, ei muistoonsa toimivasta tunnelista. Kirjaa siihen PFS-ryhmä ja ESP-ehdotus, ei vain käytännön nimeä. Kun joku myöhemmin kysyy, miksi auditointi epäonnistui tai miksi avaimen uusinta on hidasta, tuo rivi vastaa molempiin kysymyksiin.
Vahvista epäonnistunut vaihto
Ajoita muutos palautumispolun kanssa, koska käytännön muokkaaminen voi katkaista tunnelin, jota yrität korjata. Kun liikenne palaa, odota tai käynnistä CHILD_SA-uusinta ja vahvista, että uusi assosiaatio muodostetaan aiotulla PFS-ryhmällä. Vahvista sitten, että sovellusliikenne jatkuu sen yli.
Kaksi harhautusta kannattaa nimetä. SA:n elinajat ovat paikallisia määrityksiä, joten erisuuruiset arvot ovat normaaleja ja niiden muuttaminen vain siirtää sitä, milloin ongelma ilmenee. DPD havaitsee, onko peer elossa; sen aikarajan nostaminen ei kohdista ESP- tai PFS-valintoja.
Kirjaa neuvoteltu tulos ja seuraava tapahtuma muutoksen jälkeen. Jos yhteys nyt epäonnistuu ennen IKE-todennuksen valmistumista, katsot juuri muokkaamiasi IKE-asetuksia, et alkuperäistä CHILD-uusinnan epäonnistumista.