FortiGate Azure rekey: propunerea peer SA nu corespunde politicii locale

Tunelul a pornit, traficul a curs, iar mai târziu jurnalul spune peer SA proposal not match local policy. Majoritatea oamenilor citesc acea linie ca dovadă că cele două configurații nu au corespuns niciodată. De obicei înseamnă ceva mai îngust: au corespuns pentru prima CHILD SA și au încetat să corespundă la prima reînnoire, pentru că prima asociere nu a avut niciodată nevoie de schimbul pe care îl fac cele ulterioare. Această distincție decide unde să priviți.

Prima CHILD SA moștenește, cele ulterioare negociază

În IKEv2, CHILD SA inițială este creată în timpul IKE_AUTH, iar cheile ei sunt derivate din materialul de chei al IKE SA. În acel moment nu există un schimb Diffie-Hellman separat, așa că un grup PFS pe care un peer nu îl poate accepta pur și simplu nu este încă testat. Tunelul pare sănătos pentru că cerința la care veți eșua mai târziu nu a fost niciodată testată.

Un rekey CHILD_SA este o altă secvență de mesaje. Când PFS este configurat, peerii execută un schimb de chei nou și trebuie să cadă de acord asupra unui grup acceptat de ambele părți, plus propunerea ESP pentru noua asociere. Acela este momentul în care discrepanța devine vizibilă și de aceea eroarea numește o propunere, nu o rută.

Așadar „ieri funcționa” nu vă spune nimic despre propunere. Vă spune că schimbul inițial a reușit, ceea ce știați deja.

Citiți schimbul eșuat, nu primul ping

Adunați autentificarea IKE reușită, CHILD SA inițială și înlocuirea eșuată de la ambele capete înainte de a schimba ceva. Apoi numiți operațiunea precis: rekey-ul IKE SA, reautentificarea IKE și rekey-ul CHILD SA sunt trei evenimente diferite, iar „faza 2” le acoperă pe toate în conversația obișnuită.

Comparați câmpurile de mai jos pentru conexiunea care a eșuat, nu pentru tunel în general.

Pe FortiGate, deschideți propunerea de faza-2, setarea PFS și grupurile DH acceptate pentru acel tunel. Citiți valorile încărcate în loc să le deduceți dintr-o conexiune stabilită anterior. O captură de ecran a paginii GUI este o dovadă mai slabă decât configurația în execuție, pentru că cele două pot diferi după o actualizare. Exportați secțiunea pe care ați modificat-o și păstrați-o împreună cu tichetul.

Politica implicită a Azure rămâne o politică

Absența unei politici personalizate atașate conexiunii nu înseamnă că Azure nu aplică niciuna. Conexiunea revine la setul implicit de propuneri al gateway-ului, care poate fi mai larg sau mai îngust decât ceea ce oferă FortiGate-ul dumneavoastră. Dacă cele două seturi se suprapun pentru IKE, dar nu pentru ESP cu PFS, obțineți exact acest model de eșec.

Această vizualizare doar-citire arată politica atașată de fapt, fără a divulgă secrete:

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

Folosiți numele reale ale resurselor. Când este nevoie de o politică explicită, setați-o pe resursa conexiunii. Nu este un întrerupător la nivel de gateway și nu se aplică în tăcere altor tuneluri de pe același gateway.

În portal, pagina Configuration a acelei conexiuni este locul unde merge o politică IPsec/IKE personalizată. Ghidul Microsoft despre politici personalizate enumeră parametrii acceptați și cerințele SKU. Azure ia o singură combinație completă per conexiune, așa că specificați câmpurile IKE și câmpurile IPsec împreună, nu unul câte unul.

PFS este o cerință, nu un întrerupător de comutat

Dacă linia de bază de securitate necesită PFS, soluția este un grup acceptat de ambii peeri pe ambele părți, exprimat printr-o politică potrivită. Dezactivarea PFS pentru ca eroarea să dispară modifică proprietatea de securitate pe care încercați să o păstrați, iar aceasta reapare de obicei mai târziu ca o altă discrepanță.

O capcană specifică Azure: când alegeți GCM pentru ESP, selecțiile de criptare și integritate trebuie să numească același algoritm GCM și aceeași lungime de cheie. Amestecarea unui cifru GCM cu un algoritm de integritate separat produce o combinație pe care serviciul o respinge, iar aceasta arată ca o discrepanță între peeri până când citiți cu atenție politica.

Alegeți cea mai puternică combinație pe care ambele capete o acceptă și pe care cerința dumneavoastră o permite, apoi notați-o în registrul de modificări. Următoarea persoană va compara cu acel registru, nu cu memoria unui tunel funcțional. Includeți grupul PFS și propunerea ESP, nu doar numele politicii. Când cineva întreabă mai târziu de ce a eșuat un audit sau de ce un rekey este lent, acea linie răspunde la ambele întrebări.

Verificați schimbul care a eșuat

Planificați modificarea cu o cale de revenire, pentru că editarea politicii poate întrerupe tunelul pe care încercați să îl reparați. După ce traficul revine, așteptați sau declanșați o reînnoire CHILD_SA și confirmați că noua asociere este stabilită cu grupul PFS dorit. Apoi confirmați că traficul aplicațiilor continuă prin ea.

Două indicii false merită numite. Duratele de viață ale SA sunt specificații locale, așa că valorile inegale sunt normale, iar schimbarea lor mută doar momentul în care apare problema. DPD detectează dacă un peer este viu; creșterea timpului limită nu aliniază alegerile ESP sau PFS.

Înregistrați rezultatul negociat și următorul eveniment după modificare. Dacă acum conexiunea eșuează înainte de finalizarea autentificării IKE, priviți setările IKE pe care tocmai le-ați editat, nu eșecul original al reînnoirii CHILD.