strongSwan naar AWS Site-to-Site: waarom de Child SA niets selecteert

Een IKE-tunnel kan actief zijn terwijl de child-associatie uw subnetten uitsluit. Vergelijk eerst de lokale en externe CIDR van AWS met leftsubnet en rightsubnet.

De console toont up, strongSwan meldt een opgezette IKE-associatie, en de pakketten komen nog steeds niet aan. Het volgende dat je moet vergelijken is niet de vooraf gedeelde sleutel, maar het paar prefixen waarvan elke kant denkt dat de tunnel ze beschermt. Loop de controles hieronder in volgorde door, want de eerste twee bepalen of de tunnel je verkeer sowieso kan dragen.

Vertaal de namen van AWS naar de termen van strongSwan

AWS beschrijft de verbinding vanaf de klantzijde: het adres van de klantgateway en de lokale CIDR zijn van jou, en de externe CIDR is van de VPC. strongSwan noemt de twee uiteinden left en right, met jouw prefix in leftsubnet en het VPC-prefix in rightsubnet. Als je één paar omdraait, krijg je een tunnel die het verkeerde verkeer onderhandelt en selecteert.

Download de configuratie die AWS voor de verbinding genereert en behandel die als de referentie voor precies die verbinding, inclusief tunneladressen en prefixen. Als je beide CIDR-velden bij het aanmaken leeg laat, gebruikt de dienst standaard 0.0.0.0/0 aan elke kant. Een router die met een smal prefix is geconfigureerd, zal er dan nooit mee overeenkomen, dus vul de velden in of verbreed de selector bewust.

Een mismatch hier lijkt op een routeringsfout en is het niet.

Zet het adres vast dat AWS werkelijk ziet

Een router achter NAT kan IKE versturen vanaf een interface die de andere kant nooit heeft gekend. Het gateway-adres dat in AWS wordt vastgelegd, moet het adres zijn dat AWS op de lijn ziet, en de router moet aan hetzelfde lokale adres worden vastgezet in plaats van zijn standaardroute te volgen.

conn %default
    local_addrs = 203.0.113.10

In strongSwan kiest local_addrs het bronadres voor IKE, en oudere OpenSwan-configuraties schrijven hetzelfde idee als left. Richt het op de interface met het openbare adres, controleer daarna op het NAT-apparaat zelf dat UDP 500 en 4500 die host bereiken, want een regel die van een eerdere router is achtergebleven, gooit ze stil weg. Een correct selectorpair met het verkeerde bronadres faalt nog steeds, en het logboek zal het voorstel de schuld geven. Die misleiding is de reden waarom het bronadres een eigen controle verdient.

Bevestig de doorstuurregel in plaats van hem aan te nemen, want een regel die voor de vorige router juist was, blijft vaak staan.

Behandel fase 1 en fase 2 apart

AWS toont de IKE- en ESP-opties als afzonderlijke lijsten. Een IKE-suite die beide kanten accepteren zegt niets over het ESP-voorstel, omdat de twee lijsten onafhankelijk zijn. Lees ze beide uit de gegenereerde configuratie en vergelijk ze één voor één.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Syntaxis reist niet tussen implementaties. Een paar dat in OpenSwan werkt, bijvoorbeeld phase2alg=aes_gcm met ike=aes256-sha1;modp1024, moet naar de esp=- en ike=-vorm van strongSwan worden vertaald, en de algoritmenamen verschillen. Omdat GCM authenticeert terwijl het versleutelt, heeft het geen aparte integriteitstransformatie nodig, anders dan een CBC-suite die met SHA is gecombineerd. Een fase 2-regel die onvertaald van de ene daemon naar de andere wordt geplakt, levert een afwijzing op die als een selectormismatch leest.

Controleer de child-associatie, niet de tunnelindicator

Als de verbinding laadt maar er geen child-associatie opkomt, is ofwel het voorstel of zijn de selectors geweigerd. Als er wel een child opkomt en de selectors sluiten jouw prefixen uit, worden pakketten gefilterd voordat ze de tunnel bereiken. De indicator van de console dekt alleen het IKE-niveau, dus hij kan je niet vertellen welke van de twee is gebeurd.

ipsec statusall

Zoek de child-beveiligingsassociatie en lees de verkeersselectors die ernaast zijn afgedrukt, en vergelijk ze daarna met de prefixen uit de gegenereerde configuratie.

Test van een host binnen het lokale prefix naar een host binnen het VPC-prefix, en controleer het retourpad plus elke beveiligingsgroep of netwerk-ACL aan de AWS-kant. Correcte selectors beschermen een pakket er niet tegen dat het later wordt weggegooid.

Wanneer het nog steeds faalt nadat de selectors overeenkomen

Bevestig dat de route aan beide kanten naar de tunnel wijst, en bevestig dan dat het NAT-apparaat het verkeer niet herschrijft op een manier die het beleid niet verwacht. Een op beleid gebaseerde tunnel vergelijkt pakketadressen, dus een vertaling die na de beleidsbeslissing wordt toegepast, verandert de uitkomst.

Log één pakket in en één pakket uit aan elke kant voordat je nog een voorstel wijzigt.

Noteer de selectors, de voorstellen voor fase 1 en fase 2 en het bronadres in het ticket. Die vier waarden verklaren de meeste site-to-site-storingen zonder een telefoontje.

Gerelateerde artikelen