De la strongSwan la AWS Site-to-Site: de ce Child SA nu selectează nimic

Un tunel IKE poate fi activ în timp ce asocierea copil exclude subrețelele tale. Compară mai întâi CIDR-ul local și la distanță din AWS cu leftsubnet și rightsubnet.

Consola arată up, strongSwan raportează o asociere IKE stabilită, iar pachetele tot nu ajung. Următorul lucru de comparat nu este cheia prepartajată, ci perechea de prefixe pe care fiecare parte crede că tunelul le protejează. Parcurge verificările de mai jos în ordine, pentru că primele două decid dacă tunelul poate transporta deloc traficul tău.

Tradu numele AWS în termenii strongSwan

AWS descrie conexiunea din partea clientului: adresa gateway-ului clientului și CIDR-ul local sunt ale tale, iar CIDR-ul la distanță aparține VPC-ului. strongSwan numește cele două capete left și right, cu prefixul tău în leftsubnet și prefixul VPC-ului în rightsubnet. Inversarea unei perechi produce un tunel care negociază și selectează traficul greșit.

Descarcă configurația pe care AWS o generează pentru conexiune și trateaz-o ca referință pentru exact acea conexiune, inclusiv adresele și prefixele tunelului. Dacă la creare lași ambele câmpuri CIDR goale, serviciul folosește valoarea implicită 0.0.0.0/0 pe fiecare parte. Un router configurat cu un prefix îngust nu se va potrivi niciodată, așa că fie completează câmpurile, fie lărgește selectorul intenționat.

O nepotrivire aici arată ca o defecțiune de rutare și nu este.

Fixează adresa pe care AWS o vede efectiv

Un router din spatele NAT poate trimite IKE de pe o interfață pe care cealaltă parte nu a cunoscut-o niciodată. Adresa gateway-ului înregistrată în AWS trebuie să fie cea pe care AWS o observă în rețea, iar routerul trebuie fixat pe aceeași adresă locală în loc să urmeze ruta implicită.

conn %default
    local_addrs = 203.0.113.10

În strongSwan, local_addrs selectează adresa sursă pentru IKE, iar configurațiile mai vechi OpenSwan scriu aceeași idee ca left. Îndreapt-o spre interfața care are adresa publică, apoi verifică pe dispozitivul NAT însuși că UDP 500 și 4500 ajung la acea gazdă, pentru că o regulă rămasă de la un router anterior le aruncă în tăcere. O pereche corectă de selectori cu adresa sursă greșită tot eșuează, iar jurnalul va da vina pe propunere. Tocmai această inducere în eroare face ca adresa sursă să merite o verificare proprie.

Confirmă regula de redirecționare în loc să o presupui, pentru că o regulă care era corectă pentru routerul anterior rămâne adesea.

Tratează faza 1 și faza 2 separat

AWS expune opțiunile IKE și ESP ca liste separate. Un set IKE acceptat de ambele părți nu spune nimic despre propunerea ESP, pentru că cele două liste sunt independente. Citește-le pe amândouă din configurația generată și compară-le una câte una.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Sintaxa nu călătorește între implementări. O pereche care funcționează în OpenSwan, de exemplu phase2alg=aes_gcm cu ike=aes256-sha1;modp1024, trebuie tradusă în forma esp= și ike= a strongSwan, iar numele algoritmilor diferă. Deoarece GCM autentifică în timp ce criptează, nu are nevoie de o transformare de integritate separată, spre deosebire de un set CBC asociat cu SHA. O linie de faza 2 lipită dintr-un demon în altul fără traducere produce o respingere care se citește ca o nepotrivire de selectori.

Verifică asocierea copil, nu indicatorul tunelului

Dacă conexiunea se încarcă dar nu apare nicio asociere copil, a fost respinsă fie propunerea, fie selectorii. Dacă apare un copil și selectorii lui exclud prefixele tale, pachetele sunt filtrate înainte de a ajunge la tunel. Indicatorul consolei acoperă doar nivelul IKE, așa că nu îți poate spune care dintre cele două s-a întâmplat.

ipsec statusall

Caută asocierea de securitate copil și citește selectorii de trafic tipăriți alături, apoi compară-i cu prefixele din configurația generată.

Testează de la o gazdă din prefixul local la o gazdă din prefixul VPC și verifică calea de întoarcere plus orice grup de securitate sau ACL de rețea din partea AWS. Selectorii corecți nu protejează un pachet de a fi aruncat mai târziu.

Când tot eșuează după ce selectorii se potrivesc

Confirmă că ruta din ambele părți duce spre tunel, apoi confirmă că dispozitivul NAT nu rescrie traficul într-un mod pe care politica nu îl așteaptă. Un tunel bazat pe politică potrivește adresele pachetelor, așa că o traducere aplicată după decizia de politică schimbă rezultatul.

Înregistrează un pachet de intrare și unul de ieșire pe fiecare parte înainte de a schimba altă propunere.

Notează selectorii, propunerile de faza 1 și faza 2 și adresa sursă în tichet. Aceste patru valori explică majoritatea eșecurilor site-to-site fără un apel.

Articole similare