strongSwan na EC2: neka VPC usmjerava radno opterećenje
Tunel koji radi s gejtveja dokazuje samo gejtvej. Usmjerite podmrežu radnog opterećenja, omogućite prosljeđivanje na gostu, proširite selektore i zatim testirajte s njega.
Tunel je aktivan, instanca gejtveja može pingovati udaljenu mrežu, a instanca aplikacije pored nje ne može doći ni do čega. Ništa nije pokvareno. Test koji je uspio počeo je na VPN hostu i nikada nije pitao može li taj host nositi drugu izvornu adresu kroz isti IPsec odnos. Ovaj runbook zatvara taj jaz u četiri koraka, redoslijedom koji svaki neuspjeh drži vidljivim.
Prvo zapišite četiri adrese
Svaki korak ispod odnosi se na njih, pa ih popunite za svoj račun prije nego što dotaknete tablicu ruta.
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
Primjer pretpostavlja odobrenu, ispravnu IPsec vezu zasnovanu na pravilima i tok koji čuva izvor. Ovo nije NAT-ovani klijent za daljinski pristup koji posuđuje jednu dodijeljenu adresu, i ta razlika odlučuje moraju li se selektori promijeniti.
Korak 1: dajte podmreži radnog opterećenja rutu
Tablica ruta koja je zapravo povezana s podmrežom radnog opterećenja treba putanju za udaljeni prefiks koja pokazuje na mrežno sučelje gejtveja. Ruta gosta instalirana unutar instance nije zapis u toj AWS tablici ruta i nikakva količina strongSwan konfiguracije je neće stvoriti.
AWS-ove smjernice za usmjeravanje preko aparata opisuju ciljeve mrežnog sučelja i zahtjev za provjeru izvora/odredišta instance koja prosljeđuje. Ograničite tu promjenu provjere na ulogu gejtveja i ostavite obične instance aplikacija na miru.
Ne zamjenjujte lokalnu rutu VPC-a ni svaki postojeći zapis da biste napravili mjesta za jednu odobrenu mrežu. Provjerite što je povezano i aktivno, a ne što konzolna stranica prikazuje za tablicu ruta koju nitko ne koristi. Dvije tablice koje izgledaju isto mogu imati različite veze. Bitna je ona na koju je priključena podmreža radnog opterećenja.
Korak 2: omogućite prosljeđivanje na gostu
sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot
Jezgro mora prosljeđivati, a firewall hosta mora dopustiti prolaz. Dodajte predviđena pravila prosljeđivanja za prefikse radnog opterećenja i udaljene mreže umjesto da prihvatite sve i potvrdite da podmreža gejtveja zadržava upotrebljivu transportnu rutu za vlastiti promet.
Sigurnosne grupe su mjesto gdje se ovaj korak obično zaglavi. Posredni uređaj ne nasljeđuje ponašanje referenciranja sigurnosnih grupa direktne komunikacije instanci, pa pravilo kopirano iz primjera upravljanog Client VPN-a možda nikada neće odgovarati. Provjerite sigurnosnu grupu i ACL podmreže na stvarnoj putanji, u oba smjera.
Korak 3: proširite selektore na stvarne izvore
Pravilo koje na AWS strani pokriva samo 10.60.1.10/32 objašnjava uspjeh koji potječe s gejtveja bez pokrivanja 10.60.2.20. Ruta prema udaljenom odredištu ne proširuje prometni selektor, i to je druga polovica istog iznenađenja.
swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors
Ako dogovoreni dizajn štiti cijeli VPC, oba partnera moraju prihvatiti 10.60.0.0/16 i 10.90.0.0/24. Ako štiti jedno radno opterećenje, namjerno koristite taj uži prefiks. U svakom slučaju, pregledajte instalirano CHILD-SA pravilo, jer konfiguracija koju ste uredili i partner koji ju je drugačije suzio nisu isti dogovor.
Udaljena lokacija također mora usmjeravati odgovore za sačuvane VPC izvore natrag kroz predviđeni IPsec gejtvej. Zadržite podržano NAT izuzeće za zaštićeni promet gdje postoje druga pravila izvornog NAT-a; prevođenje neodobrenog radnog opterećenja u dopuštenu adresu hosta je drugačiji ugovor o identitetu, a ne prečica do pristupa koji ste željeli.
Korak 4: provjerite, pa vratite ako je potrebno
Testirajte s radnog opterećenja novom dopuštenom operacijom aplikacije, zatim ponovite s odredištem koje treba biti isključeno. Zabilježite izvornu adresu koju udaljena usluga vidi i povratnu putanju koju koristi. Ping gejtveja ili zeleni IKE status nije taj test.
Ako radno opterećenje i dalje ne uspijeva dok gejtvej radi, vratite se kroz korake redom: selektor, zatim prosljeđivanje i sigurnosne grupe, zatim povezana tablica ruta. Svaki ima različit simptom, a nagađanje preskače onaj koji je stvarno pogrešan.
Vraćanje obrće isti redoslijed. Uklonite rutu podmreže radnog opterećenja posljednju, nakon što obnovite prethodne selektore, da ne ostavite podmrežu koja pokazuje na gejtvej koji više ne štiti njene izvore. Samostalno hostanje može služiti više od hosta gejtveja kada ovi ugovori vrijede, a AWS-om upravljani Site-to-Site VPN je drugačiji operativni model u kojem strongSwan može sjediti na strani korisničkog gejtveja.