strongSwan op EC2: laat die VPC die werklas roeteer

Die tonnel is op, die poort-instansie kan die afgeleë netwerk ping, en die toepassing-instansie langsaan kan niks bereik nie. Niks is stukkend nie. Die toets wat geslaag het, het op die VPN-gasheer begin, en dit het nooit gevra of daardie gasheer ’n ander bronadres deur dieselfde IPsec-verhouding kon dra nie. Hierdie runbook sluit daardie gaping in vier stappe, in die volgorde wat elke fout sigbaar hou.

Skryf eers die vier adresse neer

Elke stap hieronder verwys na hierdie, so vul dit vir jou eie rekening in voordat jy aan ’n roetetabel raak.

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

Die voorbeeld neem ’n goedgekeurde, werkende beleidsgebaseerde IPsec-verbinding en ’n bronbehoudende vloei aan. Dit is nie ’n NAT-remote-toegangskliënt wat een toegewysde adres leen nie, en daardie verskil bepaal of die keurders moet verander.

Stap 1: gee die werklas-subnet ’n roete

Die roetetabel wat werklik aan die werklas-subnet gekoppel is, benodig ’n pad vir die afgeleë voorvoegsel wat na die poort se netwerkkoppelvlak wys. ’n Gastoete wat binne die instansie geïnstalleer is, is nie ’n inskrywing in daardie AWS-rotetabel nie, en geen hoeveelheid strongSwan-konfigurasie sal een skep nie.

AWS se toestelroeterings-riglyne beskryf netwerkkoppelvlak-teikens en die aanstuurinstansie se bron/bestemming-kontrole-vereiste. Beperk daardie kontroleverandering tot die poortrol, en laat gewone toepassinginstansies alleen.

Moenie die VPC se plaaslike roete of elke bestaande inskrywing vervang om plek te maak vir een goedgekeurde netwerk nie. Ondersoek wat gekoppel en aktief is eerder as wat ’n konsolblad wys vir ’n roetetabel wat niemand gebruik nie. Twee tabelle wat eenders lyk, kan verskillende koppelings hê. Die een wat saak maak, is die een waaraan die werklas-subnet geheg is.

Stap 2: aktiveer aansturing op die gas

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

Die kern moet aanstuur, en die gasheer se firewall moet die deurvoer toelaat. Voeg die bedoelde aanstuur-reëls vir die werklas- en afgeleë voorvoegsels by eerder as om alles te aanvaar, en bevestig dat die poort-subnet ’n bruikbare vervoerroete vir sy eie verkeer behou.

Sekuriteitsgroepe is waar hierdie stap gewoonlik vasloop. ’n Middelkas erf nie die sekuriteitsgroep-verwysingsgedrag van direkte instansie-kommunikasie nie, so ’n reël wat uit ’n bestuurde Client VPN-voorbeeld gekopieer is, sal dalk nooit pas nie. Kontroleer die sekuriteitsgroep en subnet-ACL op die werklike pad, in beide rigtings.

Stap 3: verbreed die keurders na die werklike bronne

’n Beleid wat net 10.60.1.10/32 aan die AWS-kant dek, verduidelik ’n sukses wat by die poort begin het sonder om 10.60.2.20 te dek. ’n Roete na die afgeleë bestemming brei nie ’n verkeerskeurder uit nie, en dit is die tweede helfte van dieselfde verrassing.

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

As die ooreengekome ontwerp die hele VPC beskerm, moet albei eweknieë 10.60.0.0/16 en 10.90.0.0/24 aanvaar. As dit een werklas beskerm, gebruik daardie nouer voorvoegsel doelbewus. Hoe dit ook al sy, ondersoek die geïnstalleerde CHILD-SA-beleid, want ’n konfigurasie wat jy gewysig het en ’n eweknie wat dit anders vernou het, is nie dieselfde ooreenkoms nie.

Die afgeleë terrein moet ook antwoorde vir die bewaarde VPC-bronne deur die bedoelde IPsec-poort terugroeteer. Behou die ondersteunde NAT-vrystelling vir beskermde verkeer waar ander bron-NAT-reëls bestaan; om ’n nie-goedgekeurde werklas in ’n toegelate gasheeradres te vertaal, is ’n ander identiteitskontrak, nie ’n kortpad na die toegang wat jy wou hê nie.

Stap 4: verifieer, en rol dan terug indien nodig

Toets vanuit die werklas self met ’n nuwe toegelate toepassingsbewerking, en herhaal dan met ’n bestemming wat uitgesluit moet word. Teken die bronadres aan wat die afgeleë diens sien en die terugpad wat dit gebruik. ’n Poort-ping of ’n groen IKE-status is nie daardie toets nie.

As die werklas steeds misluk terwyl die poort werk, stap terug deur die stappe in volgorde: keurder, dan aansturing en sekuriteitsgroepe, dan die gekoppelde roetetabel. Elkeen het ’n duidelike simptoom, en raai slaan die een oor wat eintlik verkeerd is.

Terugrol keer dieselfde volgorde om. Verwyder die werklas-subnet se roete laaste, nadat jy die vorige keurders herstel het, sodat jy nie ’n subnet laat wys na ’n poort wat sy bronne nie meer beskerm nie. Self-hosting kan meer as die poort-gasheer dien wanneer hierdie kontrakte geld, en AWS-bestuurde Site-to-Site VPN is ’n ander bedryfsmodel waar strongSwan eerder aan die kliëntpoort-kant kan sit.