strongSwan pe EC2: lasă VPC-ul să ruteze sarcina de lucru

Tunelul este activ, instanța de gateway poate face ping către rețeaua îndepărtată, iar instanța de aplicație de lângă nu ajunge nicăieri. Nimic nu este stricat. Testul care a reușit a pornit de pe gazda VPN și nu a întrebat niciodată dacă acea gazdă poate transporta o altă adresă sursă prin aceeași relație IPsec. Acest runbook închide acel gol în patru pași, în ordinea care păstrează fiecare eșec vizibil.

Scrie mai întâi cele patru adrese

Fiecare pas de mai jos se referă la ele, așa că completează-le pentru propriul cont înainte de a atinge un tabel de rutare.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Exemplul presupune o conexiune IPsec bazată pe politici aprobată și funcțională, și un flux care păstrează sursa. Acesta nu este un client de acces la distanță cu NAT care împrumută o adresă alocată, iar această diferență decide dacă selectorii trebuie schimbați.

Pasul 1: dă o rută subrețelei sarcinii de lucru

Tabelul de rutare asociat efectiv subrețelei sarcinii de lucru are nevoie de o cale pentru prefixul îndepărtat care indică interfața de rețea a gateway-ului. O rută de invitat instalată în interiorul instanței nu este o intrare în acel tabel de rutare AWS, iar nicio cantitate de configurare strongSwan nu va crea una.

Îndrumările AWS privind rutarea prin dispozitiv descriu ținte de interfață de rețea și cerința de verificare sursă/destinație a instanței care redirecționează. Limitează această schimbare de verificare la rolul de gateway și lasă instanțele de aplicație obișnuite în pace.

Nu înlocui ruta locală a VPC-ului sau fiecare intrare existentă pentru a face loc unei singure rețele aprobate. Inspectează ce este asociat și activ, nu ce arată o pagină de consolă pentru un tabel de rutare pe care nu îl folosește nimeni. Două tabele care arată la fel pot avea asocieri diferite. Cel care contează este cel de care este atașată subrețeaua sarcinii de lucru.

Pasul 2: activează redirecționarea pe invitat

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Kernelul trebuie să redirecționeze, iar firewall-ul gazdei trebuie să permită tranzitul. Adaugă regulile de redirecționare prevăzute pentru prefixele sarcinii de lucru și cele îndepărtate în loc să accepți tot, și confirmă că subrețeaua gateway-ului păstrează o rută de transport utilizabilă pentru propriul trafic.

Grupurile de securitate sunt locul unde acest pas se blochează de obicei. Un dispozitiv intermediar nu moștenește comportamentul de referință al grupurilor de securitate din comunicarea directă între instanțe, așa că o regulă copiată dintr-un exemplu de Client VPN administrat poate să nu se potrivească niciodată. Verifică grupul de securitate și ACL-ul subrețelei pe calea reală, în ambele sensuri.

Pasul 3: extinde selectorii la sursele reale

O politică ce acoperă doar 10.60.1.10/32 pe partea AWS explică un succes originat în gateway fără a acoperi 10.60.2.20. O rută către destinația îndepărtată nu extinde un selector de trafic, iar aceasta este a doua jumătate a aceleiași surprize.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Dacă designul convenit protejează întregul VPC, ambii parteneri trebuie să accepte 10.60.0.0/16 și 10.90.0.0/24. Dacă protejează o singură sarcină, folosește deliberat acel prefix mai îngust. În orice caz, inspectează politica CHILD-SA instalată, pentru că o configurație pe care ai editat-o și un partener care a restrâns-o altfel nu sunt același acord.

Situl îndepărtat trebuie, de asemenea, să ruteze răspunsurile pentru sursele VPC păstrate înapoi prin gateway-ul IPsec prevăzut. Păstrează excepția NAT acceptată pentru traficul protejat acolo unde există alte reguli NAT de sursă; a traduce o sarcină neaprobată într-o adresă de gazdă permisă este un alt contract de identitate, nu o scurtătură către accesul dorit.

Pasul 4: verifică, apoi revino dacă e nevoie

Testează din sarcina de lucru însăși cu o operație de aplicație permisă și nouă, apoi repetă cu o destinație care ar trebui exclusă. Notează adresa sursă pe care o vede serviciul îndepărtat și calea de întoarcere pe care o folosește. Un ping către gateway sau un status IKE verde nu este acel test.

Dacă sarcina încă eșuează în timp ce gateway-ul funcționează, parcurge pașii înapoi în ordine: selector, apoi redirecționare și grupuri de securitate, apoi tabelul de rutare asociat. Fiecare are un simptom distinct, iar ghicitul sare peste cel care este cu adevărat greșit.

Revenirea inversează aceeași ordine. Elimină ruta subrețelei sarcinii de lucru ultima, după ce ai restaurat selectorii anteriori, ca să nu lași o subrețea îndreptată către un gateway care nu îi mai protejează sursele. Găzduirea proprie poate servi mai mult decât gazda gateway-ului atunci când aceste contracte sunt valabile, iar VPN-ul Site-to-Site administrat de AWS este un model operațional diferit în care strongSwan poate sta la capătul gateway-ului clientului.