Från strongSwan till AWS Site-to-Site: varför Child SA inte väljer något

En IKE-tunnel kan vara uppe medan barnassociationen utesluter dina subnät. Jämför först AWS lokala och avlägsna CIDR med leftsubnet och rightsubnet.

Konsolen visar up, strongSwan rapporterar en etablerad IKE-association och paketen kommer fortfarande inte fram. Nästa sak att jämföra är inte den fördelade nyckeln, utan paret prefix som varje sida tror att tunneln skyddar. Gå igenom kontrollerna nedan i ordning, eftersom de två första avgör om tunneln alls kan bära din trafik.

Översätt AWS namn till strongSwans begrepp

AWS beskriver anslutningen från kundsidan: kundgatewayens adress och det lokala CIDR:et tillhör dig, och det avlägsna CIDR:et tillhör VPC:n. strongSwan kallar de två ändarna left och right, med ditt prefix i leftsubnet och VPC:ns prefix i rightsubnet. Byter du ett par får du en tunnel som förhandlar och väljer fel trafik.

Ladda ner konfigurationen som AWS genererar för anslutningen och behandla den som referensen för just den anslutningen, inklusive tunneladresser och prefix. Om du lämnar båda CIDR-fälten tomma vid skapandet använder tjänsten standardvärdet 0.0.0.0/0 på varje sida. En router som konfigurerats med ett smalt prefix kommer då aldrig att matcha, så fyll i fälten eller bredda väljaren medvetet.

En avvikelse här ser ut som ett routingfel och är det inte.

Fäst adressen som AWS faktiskt ser

En router bakom NAT kan skicka IKE från ett gränssnitt som den andra sidan aldrig har känt till. Gatewayadressen som registreras i AWS måste vara den AWS observerar på nätet, och routern måste fästas vid samma lokala adress i stället för att följa sin standardrutt.

conn %default
    local_addrs = 203.0.113.10

I strongSwan väljer local_addrs källadressen för IKE, och äldre OpenSwan-konfigurationer skriver samma idé som left. Peka den mot gränssnittet som har den publika adressen, kontrollera sedan på själva NAT-enheten att UDP 500 och 4500 når den värden, eftersom en regel som ligger kvar från en tidigare router tyst slänger dem. Ett korrekt väljarpar med fel källadress misslyckas ändå, och loggen kommer att skylla på förslaget. Just denna vilseledning är skälet till att källadressen förtjänar en egen kontroll.

Bekräfta vidarebefordringsregeln i stället för att anta den, eftersom en regel som var rätt för den förra routern ofta ligger kvar.

Behandla fas 1 och fas 2 separat

AWS visar IKE- och ESP-alternativen som separata listor. En IKE-svit som båda sidor accepterar säger ingenting om ESP-förslaget, eftersom de två listorna är oberoende. Läs båda från den genererade konfigurationen och jämför dem en i taget.

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

Syntax flyttar inte mellan implementationer. Ett par som fungerar i OpenSwan, till exempel phase2alg=aes_gcm med ike=aes256-sha1;modp1024, behöver översättas till strongSwans esp=- och ike=-form, och algoritmnamnen skiljer sig. Eftersom GCM autentiserar medan den krypterar behöver den ingen separat integritetstransform, till skillnad från en CBC-svit parad med SHA. En fas 2-rad som klistras in från en daemon till en annan utan översättning ger ett avslag som läses som en väljaravvikelse.

Kontrollera barnassociationen, inte tunnelindikatorn

Om anslutningen laddas men ingen barnassociation kommer upp, har antingen förslaget eller väljarna avvisats. Om ett barn kommer upp och dess väljare utesluter dina prefix filtreras paketen innan de når tunneln. Konsolens indikator täcker bara IKE-nivån, så den kan inte säga vilket av de två som hände.

ipsec statusall

Leta upp barnassociationen för säkerhet och läs trafikväljarna som skrivs ut bredvid, jämför dem sedan med prefixen från den genererade konfigurationen.

Testa från en värd inom det lokala prefixet till en värd inom VPC-prefixet, och kontrollera returvägen samt eventuell säkerhetsgrupp eller nätverks-ACL på AWS-sidan. Korrekta väljare skyddar inte ett paket från att slängas senare.

När det fortfarande misslyckas efter att väljarna matchar

Bekräfta att rutten på båda sidor pekar mot tunneln, och bekräfta sedan att NAT-enheten inte skriver om trafiken på ett sätt som policyn inte förväntar sig. En policybaserad tunnel matchar paketadresser, så en översättning som tillämpas efter policybeslutet ändrar resultatet.

Logga ett paket in och ett paket ut på varje sida innan du ändrar ytterligare ett förslag.

Anteckna väljarna, förslagen för fas 1 och fas 2 och källadressen i ärendet. Dessa fyra värden förklarar de flesta site-to-site-fel utan ett samtal.

Relaterade artiklar