strongSwan op EC2: laat de VPC de werklast routeren

De tunnel staat, de gateway-instantie kan het externe netwerk pingen, en de applicatie-instantie ernaast bereikt niets. Niets is kapot. De test die slaagde, begon op de VPN-host, en hij vroeg nooit of die host een ander bronadres door dezelfde IPsec-relatie kon dragen. Deze runbook sluit die kloof in vier stappen, in de volgorde die elke fout zichtbaar houdt.

Schrijf eerst de vier adressen op

Elke stap hieronder verwijst ernaar, dus vul ze in voor je eigen account voordat je een routetabel aanraakt.

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

Het voorbeeld gaat uit van een goedgekeurde, werkende op beleid gebaseerde IPsec-verbinding en een stroom die de bron behoudt. Dit is geen NAT-client voor externe toegang die één toegewezen adres leent, en dat verschil bepaalt of de selectors moeten veranderen.

Stap 1: geef het werklast-subnet een route

De routetabel die daadwerkelijk aan het werklast-subnet is gekoppeld, heeft een pad nodig voor het externe prefix dat naar de netwerkinterface van de gateway wijst. Een gastroute die in de instantie is geïnstalleerd, is geen vermelding in die AWS-routetabel, en geen enkele hoeveelheid strongSwan-configuratie maakt er een.

De richtlijnen van AWS voor routeren via een apparaat beschrijven doelen van het netwerkinterface-type en de vereiste bron-/bestemmingscontrole van de instantie die doorstuurt. Beperk die controlewijziging tot de gateway-rol en laat gewone applicatie-instanties met rust.

Vervang niet de lokale route van de VPC of elke bestaande vermelding om ruimte te maken voor één goedgekeurd netwerk. Inspecteer wat is gekoppeld en actief, in plaats van wat een consolepagina toont voor een routetabel die niemand gebruikt. Twee tabellen die er hetzelfde uitzien, kunnen verschillende koppelingen hebben. Degene die ertoe doet, is degene waaraan het werklast-subnet is gekoppeld.

Stap 2: schakel doorsturen op de gast in

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

De kernel moet doorsturen en de firewall van de host moet de doorgang toestaan. Voeg de bedoelde doorstuurregels voor de werklast- en externe prefixen toe in plaats van alles te accepteren, en bevestig dat het gateway-subnet een bruikbare transportroute voor zijn eigen verkeer behoudt.

Beveiligingsgroepen zijn waar deze stap meestal vastloopt. Een tussenapparaat erft niet het referentiegedrag van beveiligingsgroepen van directe communicatie tussen instanties, dus een regel die uit een voorbeeld van een beheerde Client VPN is gekopieerd, komt mogelijk nooit overeen. Controleer de beveiligingsgroep en de subnet-ACL op het werkelijke pad, in beide richtingen.

Stap 3: verbreed de selectors naar de echte bronnen

Een beleid dat aan de AWS-kant alleen 10.60.1.10/32 dekt, verklaart een succes dat bij de gateway begon zonder 10.60.2.20 te dekken. Een route naar de externe bestemming verbreedt geen verkeersselector, en dat is de tweede helft van dezelfde verrassing.

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

Als het overeengekomen ontwerp de hele VPC beschermt, moeten beide peers 10.60.0.0/16 en 10.90.0.0/24 accepteren. Als het één werklast beschermt, gebruik dan bewust dat smallere prefix. Hoe dan ook, inspecteer het geïnstalleerde CHILD-SA-beleid, want een configuratie die je hebt bewerkt en een peer die het anders heeft vernauwd, zijn niet dezelfde overeenkomst.

De externe locatie moet ook antwoorden voor de behouden VPC-bronnen terugrouteren via de bedoelde IPsec-gateway. Behoud de ondersteunde NAT-uitzondering voor beschermd verkeer waar andere bron-NAT-regels bestaan; een niet-goedgekeurde werklast vertalen naar een toegestaan hostadres is een ander identiteitscontract, geen snelkoppeling naar de toegang die je wilde.

Stap 4: verifieer en draai indien nodig terug

Test vanaf de werklast zelf met een nieuwe toegestane applicatiebewerking en herhaal daarna met een bestemming die uitgesloten zou moeten zijn. Noteer het bronadres dat de externe dienst ziet en het retourpad dat hij gebruikt. Een gateway-ping of een groene IKE-status is die test niet.

Als de werklast nog steeds faalt terwijl de gateway werkt, loop dan de stappen in volgorde terug: selector, dan doorsturen en beveiligingsgroepen, dan de gekoppelde routetabel. Elk heeft een eigen symptoom, en gissen slaat degene over die echt verkeerd is.

Terugdraaien keert dezelfde volgorde om. Verwijder de route van het werklast-subnet als laatste, nadat je de vorige selectors hebt hersteld, zodat je geen subnet achterlaat dat naar een gateway wijst die de bronnen niet meer beschermt. Zelf hosten kan meer dan de gateway-host dienen wanneer deze contracten gelden, en door AWS beheerde Site-to-Site VPN is een ander bedieningsmodel waarbij strongSwan in plaats daarvan aan de klantgateway-kant kan zitten.