strongSwan til AWS Site-to-Site: hvorfor Child SA ikke velger noe

En IKE-tunnel kan være oppe mens barneassosiasjonen utelukker subnettet ditt. Sammenlign først AWS’ lokale og eksterne CIDR med leftsubnet og rightsubnet.

Konsollen viser up, strongSwan rapporterer en etablert IKE-assosiasjon, og pakkene kommer fortsatt ikke frem. Det neste som skal sammenlignes er ikke den forhåndsdelte nøkkelen, men paret av prefikser som hver side tror tunnelen beskytter. Gå gjennom kontrollene nedenfor i rekkefølge, fordi de to første avgjør om tunnelen i det hele tatt kan bære trafikken din.

Oversett AWS-navnene til strongSwans begreper

AWS beskriver forbindelsen fra kundens side: kundegateway-adressen og den lokale CIDR-en tilhører deg, og den eksterne CIDR-en tilhører VPC-en. strongSwan kaller de to endene left og right, med prefikset ditt i leftsubnet og VPC-prefikset i rightsubnet. Bytter du om ett par, får du en tunnel som forhandler og velger feil trafikk.

Last ned konfigurasjonen AWS genererer for forbindelsen og behandle den som referansen for akkurat den forbindelsen, inkludert tunneladresser og prefikser. Lar du begge CIDR-feltene stå tomme ved opprettelsen, bruker tjenesten standardverdien 0.0.0.0/0 på hver side. En ruter konfigurert med et smalt prefiks vil da aldri matche, så enten fyll ut feltene eller utvid velgeren bevisst.

Et avvik her ser ut som en rutingfeil og er det ikke.

Fest adressen AWS faktisk ser

En ruter bak NAT kan sende IKE fra et grensesnitt den andre siden aldri har kjent. Gateway-adressen som registreres i AWS, må være den AWS observerer på nettet, og ruteren må festes til samme lokale adresse i stedet for å følge standardruten.

conn %default
    local_addrs = 203.0.113.10

I strongSwan velger local_addrs kildeadressen for IKE, og eldre OpenSwan-konfigurasjoner skriver samme idé som left. Pek den mot grensesnittet som har den offentlige adressen, og bekreft deretter på selve NAT-enheten at UDP 500 og 4500 når den verten, fordi en regel som er igjen fra en tidligere ruter dropper dem lydløst. Et korrekt velgerpar med feil kildeadresse feiler likevel, og loggen vil gi forslaget skylden. Nettopp denne villledningen er grunnen til at kildeadressen fortjener sin egen kontroll.

Bekreft videresendingsregelen i stedet for å anta den, fordi en regel som var riktig for den forrige ruteren ofte blir liggende.

Behandle fase 1 og fase 2 hver for seg

AWS viser IKE- og ESP-valgene som separate lister. Et IKE-sett som begge sider godtar, sier ingenting om ESP-forslaget, fordi de to listene er uavhengige. Les begge fra den genererte konfigurasjonen og sammenlign dem én om gangen.

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

Syntaks flytter seg ikke mellom implementasjoner. Et par som virker i OpenSwan, for eksempel phase2alg=aes_gcm med ike=aes256-sha1;modp1024, må oversettes til strongSwans esp=- og ike=-form, og algoritmenavnene er forskjellige. Fordi GCM autentiserer mens den krypterer, trenger den ingen egen integritetstransformasjon, i motsetning til et CBC-sett paret med SHA. En fase 2-linje limt inn fra én daemon til en annen uten oversettelse gir en avvisning som leses som et velgeravvik.

Kontroller barneassosiasjonen, ikke tunnelindikatoren

Hvis forbindelsen lastes men ingen barneassosiasjon kommer opp, ble enten forslaget eller velgerne avvist. Hvis et barn kommer opp og velgerne utelukker prefiksene dine, filtreres pakkene før de når tunnelen. Konsollens indikator dekker bare IKE-nivået, så den kan ikke si hvilken av de to tingene som skjedde.

ipsec statusall

Finn barneassosiasjonen for sikkerhet og les trafikkvelgerne som er skrevet ut ved siden av, og sammenlign dem deretter med prefiksene fra den genererte konfigurasjonen.

Test fra en vert inne i det lokale prefikset til en vert inne i VPC-prefikset, og kontroller returveien samt enhver sikkerhetsgruppe eller nettverks-ACL på AWS-siden. Korrekte velgere beskytter ikke en pakke mot å bli droppet senere.

Når det fortsatt feiler etter at velgerne matcher

Bekreft at ruten på begge sider peker mot tunnelen, og bekreft deretter at NAT-enheten ikke skriver om trafikken på en måte politikken ikke forventer. En politikkbasert tunnel matcher pakkeadresser, så en oversettelse som brukes etter politikkbeslutningen endrer resultatet.

Logg én pakke inn og én pakke ut på hver side før du endrer et annet forslag.

Noter velgerne, forslagene for fase 1 og fase 2 og kildeadressen i saken. Disse fire verdiene forklarer de fleste site-to-site-feil uten en telefonsamtale.

Relaterte artikler