strongSwan op EC2: loos d'VPC d'Aarbechtslaascht routeieren

En Tunnel, dee vum Gateway funktionnéiert, beweise just de Gateway. Routeier d'Subnetz vun der Aarbechtslaascht, aktivéier d'Weiderleeden um Gast, erweider d'Selektoren an test da vun do.

Den Tunnel ass op, d'Gateway-Instanz kann dat wäit Netzwierk pingen, an d'Applikatiounsinstanz dernieft ereecht näischt. Naischt ass futti. Den Test, dee geklappt huet, huet um VPN-Host ugefaangen, an en huet ni gefrot, ob deen Host eng aner Quelladress duerch déiselwecht IPsec-Bezéiung konnt droen. Dëse Runbook schléisst déi Lück a véier Schrëtt, an der Rei, déi all Feeler sichtbar hält.

Schreif d'éischt déi véier Adressen op

All Schrëtt hei drënner bezitt sech op déi, also fëll se fir däin eegene Kont aus, ier s du eng Routingstabell beréiers.

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

D'Beispill geet vun enger geneemter, funktionéierender policybaséierter IPsec-Verbindung an engem quellentreie Floss aus. Dëst ass kee NATte Remote-Access-Client, deen eng zougewisen Adress leint, an deen Ënnerscheed entscheet, ob d'Selektoren mussen geännert ginn.

Schrëtt 1: gëff dem Subnetz vun der Aarbechtslaascht eng Route

D'Routingstabell, déi tatsächlech mam Subnetz vun der Aarbechtslaascht verbonnen ass, brauch e Wee fir de wäite Präfix, deen op d'Netzwierkinterface vum Gateway weist. Eng Gastroute, déi an der Instanz installéiert ass, ass keen Antrag an där AWS-Routingstabell, an et gëtt keng Quantitéit strongSwan-Konfiguratioun, déi eng erstallt.

Dem AWS seng Richtlinnen zum Routing iwwer Apparater beschreiwen Netzwierkinterface-Ziler an d'Ufuerderung vun der Quell-/Zil-Kontroll vun der Instanz, déi weiderleet. Beschränk déi Kontrollännerung op d'Gateway-Roll, a loos gewéinlech Applikatiounsinstanzen a Rou.

Ersetz net d'lokal Route vun der VPC oder all existéierend Antrag, fir Plaz fir een geneemten Netzwierk ze maachen. Inspektéier, wat verbonnen an aktiv ass, amplaz wat eng Konsolsäit fir eng Routingstabell weist, déi kee benotzt. Zwou Tabellelen, déi d'selwecht ausgesinn, kënnen ënnerschiddlech Verbindungen hunn. Déi, déi zielt, ass déi, un déi d'Subnetz vun der Aarbechtslaascht ugeschloss ass.

Schrëtt 2: aktivéier d'Weiderleeden um Gast

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

De Kernel muss weiderleeden, an d'Firewall vum Host muss den Duerchgang erlaben. Füüg déi virgesinn Weiderleedungsregelen fir d'Präfixer vun der Aarbechtslaascht a vun der Wäit bäi, amplaz alles ze akzeptéieren, a bestäteg, datt d'Gateway-Subnetz eng brauchbar Transportroute fir säin eegene Verkéier behält.

Sécherheetsgruppen sinn de Punkt, wou dëse Schrëtt meeschtens hänke bleift. En Tëschentapparat ierft net d'Referenzverhalen vu Sécherheetsgruppen aus der direkter Instanzkommunikatioun, also eng Regel, déi aus engem Beispill vun engem verwalteten Client VPN kopéiert gouf, passt vläicht ni. Kontrolléier d'Sécherheetsgrupp an d'Subnetz-ACL um tatsächleche Wee, an zwou Richtungen.

Schrëtt 3: erweider d'Selektoren op déi richteg Quellen

Eng Politik, déi op der AWS-Säit nëmmen 10.60.1.10/32 deckt, erkläert e Succès, deen um Gateway ugefaangen huet, ouni 10.60.2.20 ze decken. Eng Route an Richtung vum wäiten Zil erweidert kee Verkéiersselektor, an dat ass déi zweet Hallschent vun der selwechter Iwwerraschung.

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

Wann den ausgemaachten Design déi ganz VPC schützt, mussen allebéi Peeren 10.60.0.0/16 an 10.90.0.0/24 akzeptéieren. Wann e just eng Aarbechtslaascht schützt, benotz dee méi enke Präfix bewosst. Op alle Fall inspektéier d'installéiert CHILD-SA-Politik, well eng Konfiguratioun, déi s du geännert hues, an e Peer, deen se anescht enk gemaach huet, sinn net déiselwecht Ofmachung.

Déi wäit Plaz muss och d'Äntwerten fir déi erhalen VPC-Quelle iwwer de virgesinnte IPsec-Gateway zréckroutéieren. Behäl d'ënnerstëtzt NAT-Ausnam fir geschützt Verkéier, wou aner Quell-NAT-Regelen existéieren; eng net geneemt Aarbechtslaascht an eng erlaabt Hostadress z'iwwersetzen ass en anere Identitéitskontrakt, keen Ofkierzung zum Zougang, deen s du wollts.

Schrëtt 4: verifizéier, a setz dann zréck, wann néideg

Test vun der Aarbechtslaascht selwer mat enger neier erlaabter Applikatiounsoperatioun, a widderhuel dann mat engem Zil, dat soll ausgeschloss ginn. Nottéier d'Quelladress, déi de wäite Service gesäit, an de Réckwee, deen en notzt. E Gateway-Ping oder e gréine IKE-Status ass deen Test net.

Wann d'Aarbechtslaascht nach ëmmer feelt, während de Gateway funktionnéiert, geh d'Schrëtt an der Rei zréck: Selektor, dann Weiderleeden a Sécherheetsgruppen, dann d'verbonne Routingstabell. Jiddwereen huet en anere Symptom, a Rode spréngt deen, deen tatsächlech falsch ass.

D'Zrécksetzen dréit déi selwecht Rei ëm. Huels d'Route vum Subnetz vun der Aarbechtslaascht als Lescht eraus, nodeem s du déi vireg Selektoren erëm hiergestallt hues, fir datt s du keng Subnetz hannerloosst, déi op e Gateway weist, deen seng Quelle net méi schützt. Selbsthosting kann méi wéi den Gateway-Host déngen, wann dës Kontrakter halen, an de vun AWS verwaltete Site-to-Site VPN ass en anere Betribsmodell, wou strongSwan amplaz um Client-Gateway-Ende ka sëtzen.

Ähnlech Artikelen