Rotirea unei PSK AWS VPN: care tunel cade și când

Tunelul cade în momentul în care cele două capete nu sunt de acord asupra cheii prepartajate și rămâne jos până când ambele părți poartă noua valoare. Acea parte este de așteptat: AWS tratează schimbarea ca o întrerupere a tunelului selectat, iar partenerul nu va termina IKE cât timp cheile diferă. Ce surprinde oamenii este a doua jumătate. Celălalt tunel nu preia traficul de la sine decât dacă ați verificat că îl poate duce. Rotiți în această ordine și întreruperea rămâne în interiorul unui singur tunel.

Ce se întâmplă de fapt când cheia se schimbă

ModifyVpnTunnelOptions rescrie opțiunile unui tunel, identificat prin adresa IP externă. Tunelul este demolat și reconstruit, așa că IKE și IPsec negociază de la zero cu cheia nouă. AWS precizează că întreruperea poate dura câteva minute, suficient pentru ca un protocol de rutare să o observe. Celălalt tunel din aceeași conexiune nu este afectat de apel.

Există un al doilea efect pe care merită să-l știți înainte de a trimite ceva. Operația de modificare preia întregul set de opțiuni ale tunelului, așa că un câmp omis este rescris cu valoarea sa implicită. Dacă ați reglat duratele de viață ale fazei 1 sau fazei 2, ori setările de detectare a partenerului mort, transmiteți valorile curente în aceeași cerere sau planificați restaurarea lor după aceea.

Citiți mai întâi valorile curente, apoi schimbați un singur câmp. Acea ordine este toată disciplina acestei sarcini.

Potriviți mai întâi tunelul AWS cu partenerul corect

Consola etichetează tunelurile după ordine, iar dispozitivul dvs. nu folosește acea etichetă. Identificați tunelul prin adresa IP externă și potriviți-l cu secțiunea de partener de pe gateway-ul clientului. Tunelul 1 într-o configurație locală nu este dovada că editați tunelul pe care AWS îl numește tunelul 1.

Începeți de la conexiunea în sine, care enumeră ambele tuneluri și cheia pe care o deține fiecare acum:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

Cheia returnată este cea folosită chiar acum. Comparați-o cu configurația partenerului înainte de a schimba ceva, pentru că o nepotrivire care există deja explică un tunel care nu a fost niciodată stabil.

Lăsați mai întâi celălalt tunel să ducă traficul

Două tuneluri într-o conexiune nu dovedesc că dispozitivul dvs. le-a configurat pe ambele, că ambele anunță prefixele de care aveți nevoie sau că traficul se mișcă între ele. Verificați negocierea tunelului alternativ, rutele sale și un flux real de aplicație în ambele direcții. Cu BGP, o vecinătate activă este o dovadă utilă, dar nu este același lucru cu confirmarea prefixelor. Cu rutare statică, confirmați cum alege gateway-ul calea și ce face când cea preferată dispare.

Dacă alternativul nu poate duce volumul de lucru, programați întreruperea sau reparați tunelul alternativ înainte de a atinge cheia. Un bec de stare pe o pagină de consolă nu este o promisiune de serviciu neîntrerupt.

Rotiți un tunel, apoi verificați cu trafic real

După ce calea alternativă este dovedită, secvența este scurtă. Notați adresa tunelului, partenerul său și setările care nu sunt secrete, și păstrați o cale de administrare către gateway care nu depinde de tunelul pe care urmează să-l rupeți.

1. Actualizați partenerul gateway-ului clientului pentru adresa externă aleasă sau pregătiți schimbarea astfel încât să intre în vigoare la câteva secunde după apelul API.
2. Trimiteți apelul de modificare cu cheia nouă plus duratele de viață și valorile DPD curente.
3. Așteptați întoarcerea IKE și IPsec, apoi confirmați rutele și prefixele necesare.
4. Trimiteți un flux reprezentativ de aplicație prin acel tunel și urmăriți ambele direcții.

Tunelul este inutilizabil cât timp capetele nu sunt de acord și cât timp AWS aplică modificarea, așa că actualizarea partenerului trebuie să urmeze imediat, nu după prânz. Doar când tunelul modificat duce trafic real ar trebui să repetați procedura pe celălalt.

Opriți-vă dacă recuperarea sau rutarea sunt încă incerte după primul tunel. Două tuneluri pe jumătate funcționale sunt mai rele decât unul despre care știți că funcționează.

Când recuperarea se blochează, citiți partea IKE

Un tunel care rămâne jos după ce ambele capete au cheia nouă este de obicei o nepotrivire de politică pe care rotirea a expus-o, nu a creat-o. Propunerile, identitatea trimisă de partener și selectoarele de trafic trebuie toate să fie de acord cu partea AWS, iar o valoare care a supraviețuit unui tunel stabilit poate fi totuși respinsă în timpul unei noi negocieri. Citiți starea negocierii și mesajul atașat înainte de a schimba cheia a doua oară.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Dacă schimbarea trebuie anulată, nu restaurați cheia veche doar pentru că funcționa înainte. Tratați o cheie compromisă ca fiind compromisă și reparați mai degrabă negocierea. Încheiați cu ambele tuneluri verificate și inventarul de secrete actualizat, astfel încât fiecare partener să noteze ce valoare deține, și țineți documentația opțiunilor de tunel AWS lângă runbook.