strongSwan til AWS Site-to-Site: hvorfor Child SA ikke vælger noget

En IKE-tunnel kan være oppe, mens child-forbindelsen udelukker dine undernet. Sammenlign først AWS’ lokale og fjernede CIDR med leftsubnet og rightsubnet.

Konsollen viser up, strongSwan rapporterer en etableret IKE-forbindelse, og pakkerne ankommer stadig ikke. Det næste, der skal sammenlignes, er ikke den foruddelte nøgle, men det par af præfikser, som hver side mener, at tunnelen beskytter. Gå gennem kontrollerne nedenfor i rækkefølge, fordi de to første afgør, om tunnelen overhovedet kan bære din trafik.

Oversæt AWS’ navne til strongSwans

AWS beskriver forbindelsen fra kundens side: kundegateway-adressen og det lokale CIDR tilhører dig, og det fjernede CIDR tilhører VPC’en. strongSwan kalder de to ender left og right, med dit præfiks i leftsubnet og VPC-præfikset i rightsubnet. Bytter du et par om, får du en tunnel, der forhandler og vælger den forkerte trafik.

Download den konfiguration, AWS genererer til forbindelsen, og brug den som reference for netop den forbindelse, inklusive tunneladresser og præfikser. Lader du begge CIDR-felter stå tomme ved oprettelsen, bruger tjenesten standarden 0.0.0.0/0 i hver side. En router, der er konfigureret med et smalt præfiks, vil så aldrig matche den, så enten udfyld felterne, eller udvid vælgeren bevidst.

En uoverensstemmelse her ligner en routingfejl og er det ikke.

Fastgør den adresse, AWS faktisk ser

En router bag NAT kan sende IKE fra et interface, som den anden side aldrig har kendt. Gateway-adressen, der er registreret i AWS, skal være den, AWS ser på nettet, og routeren skal fastgøres til samme lokale adresse i stedet for at følge sin standardrute.

conn %default
    local_addrs = 203.0.113.10

I strongSwan vælger local_addrs kildeadressen til IKE, og ældre OpenSwan-konfigurationer skriver samme idé som left. Peg den mod det interface, der har den offentlige adresse, og bekræft derefter på selve NAT-enheden, at UDP 500 og 4500 når den vært, fordi en regel tilbage fra en tidligere router dropper dem lydløst. Et korrekt vælgerpar med den forkerte kildeadresse fejler stadig, og loggen vil give forslaget skylden. Den vildledning er grunden til, at kildeadressen fortjener sin egen kontrol.

Bekræft videresendelsesreglen i stedet for at antage den, fordi en regel, der var rigtig for den forrige router, ofte bliver hængende.

Behandl fase 1 og fase 2 hver for sig

AWS viser IKE- og ESP-indstillinger som separate lister. Et IKE-sæt, som begge sider accepterer, siger intet om ESP-forslaget, fordi de to lister er uafhængige. Læs begge fra den genererede konfiguration, og sammenlign dem én ad gangen.

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

Syntaks flytter ikke mellem implementeringer. Et par, der virker i OpenSwan, for eksempel phase2alg=aes_gcm med ike=aes256-sha1;modp1024, skal oversættes til strongSwans esp= og ike= form, og algoritmenavnene er forskellige. Fordi GCM autentificerer, mens det krypterer, har det ikke brug for en separat integritetstransformation, i modsætning til et CBC-sæt parret med SHA. En fase 2-linje, der indsættes fra en daemon til en anden uden oversættelse, giver en afvisning, der lyder som en vælger-uoverensstemmelse.

Kontroller child-forbindelsen, ikke tunnelindikatoren

Hvis forbindelsen indlæses, men ingen child-forbindelse opstår, blev enten forslaget eller vælgerne afvist. Hvis der opstår et child, og dets vælgere udelukker dine præfikser, filtreres pakkerne, før de når tunnelen. Konsollens indikator dækker kun IKE-niveauet, så den kan ikke sige, hvilken af de to ting der skete.

ipsec statusall

Find child-sikkerhedsforbindelsen, og læs de trafikvælgere, der står ud for den, og sammenlign dem derefter med præfikserne fra den genererede konfiguration.

Test fra en vært i det lokale præfiks til en vært i VPC-præfikset, og kontroller returvejen plus enhver sikkerhedsgruppe eller netværks-ACL på AWS-siden. Korrekte vælgere beskytter ikke en pakke mod at blive droppet senere.

Når det stadig fejler, efter at vælgerne matcher

Bekræft, at ruten på begge sider peger mod tunnelen, og bekræft derefter, at NAT-enheden ikke omskriver trafik på en måde, som politikken ikke forventer. En politikbaseret tunnel matcher pakkeadresser, så en oversættelse, der anvendes efter politikbeslutningen, ændrer resultatet.

Log én pakke ind og én pakke ud i hver side, før du ændrer endnu et forslag.

Notér vælgerne, fase 1- og fase 2-forslagene og kildeadressen i billetten. De fire værdier forklarer de fleste site-to-site-fejl uden et opkald.

Relaterede artikler