De strongSwan a AWS Site-to-Site: per què el Child SA no selecciona res

Un túnel IKE pot estar actiu mentre l’associació filla exclou les vostres subxarxes. Compareu primer els CIDR local i remot d’AWS amb leftsubnet i rightsubnet.

La consola mostra l’estat actiu, strongSwan informa d’una associació IKE establerta i les trames continuen sense arribar. El següent que cal comparar no és la clau prèviament compartida, sinó la parella de prefixos que cada costat creu que el túnel protegeix. Seguiu les comprovacions següents per ordre, perquè les dues primeres decideixen si el túnel pot arribar a transportar el vostre trànsit.

Traduïu els noms d’AWS als termes de strongSwan

AWS descriu la connexió des del costat del client: l’adreça de la passarel·la del client i el CIDR local són vostres, i el CIDR remot pertany a la VPC. strongSwan anomena els dos extrems left i right, amb el vostre prefix a leftsubnet i el prefix de la VPC a rightsubnet. Si invertiu una parella, obteniu un túnel que negocia i selecciona el trànsit equivocat.

Baixeu la configuració que AWS genera per a la connexió i tracteu-la com la referència d’aquesta connexió concreta, incloent-hi les adreces del túnel i els prefixos. Si deixeu tots dos camps CIDR buits en crear-la, el servei fa servir el valor predeterminat 0.0.0.0/0 a cada costat. Un encaminador configurat amb un prefix estret llavors no hi coincidirà mai, així que ompliu els camps o amplieu el selector deliberadament.

Una discrepància aquí sembla una fallada d’encaminament i no ho és.

Fixeu l’adreça que AWS veu realment

Un encaminador darrere de NAT pot originar IKE des d’una interfície que el costat remot mai no ha conegut. L’adreça de passarel·la registrada a AWS ha de ser la que AWS observa a la xarxa, i l’encaminador s’ha de fixar a la mateixa adreça local en lloc de seguir la seva ruta predeterminada.

conn %default
    local_addrs = 203.0.113.10

A strongSwan, local_addrs selecciona l’adreça d’origen per a IKE, i les configuracions antigues d’OpenSwan escriuen la mateixa idea com a left. Apunteu-lo a la interfície que té l’adreça pública, després verifiqueu al mateix dispositiu NAT que UDP 500 i 4500 arriben a aquest amfitrió, perquè una regla que queda d’un encaminador anterior les descarta en silenci. Una parella de selectors correcta amb l’adreça d’origen equivocada encara falla, i el registre culparà la proposta. Aquest engany és la raó per la qual l’adreça d’origen mereix una comprovació pròpia.

Confirmeu la regla de reenviament en lloc de suposar-la, perquè una regla que era correcta per a l’encaminador anterior sovint queda.

Tracteu la fase 1 i la fase 2 per separat

AWS exposa les opcions d’IKE i ESP com a llistes separades. Un conjunt IKE que les dues parts accepten no diu res sobre la proposta ESP, perquè les dues llistes són independents. Llegiu-ne les dues a la configuració generada i compareu-les d’una en una.

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

La sintaxi no viatja entre implementacions. Una parella que funciona a OpenSwan, com ara phase2alg=aes_gcm amb ike=aes256-sha1;modp1024, necessita traducció a la forma esp= i ike= de strongSwan, i els noms dels algorismes difereixen. Com que GCM autentica mentre xifra, no necessita una transformació d’integritat separada, a diferència d’un conjunt CBC aparellat amb SHA. Una línia de fase 2 enganxada d’un dimoni a un altre sense traduir produeix un rebuig que es llegeix com una discrepància de selectors.

Comproveu l’associació filla, no l’indicador del túnel

Si la connexió es carrega però no apareix cap associació filla, s’ha rebutjat la proposta o els selectors. Si apareix una filla i els seus selectors exclouen els vostres prefixos, les trames es filtren abans d’arribar al túnel. L’indicador de la consola només cobreix el nivell IKE, així que no us pot dir quina de les dues coses ha passat.

ipsec statusall

Cerqueu l’associació de seguretat filla i llegiu els selectors de trànsit impresos al costat, i després compareu-los amb els prefixos de la configuració generada.

Proveu des d’un amfitrió dins del prefix local cap a un amfitrió dins del prefix de la VPC, i comproveu el camí de tornada i qualsevol grup de seguretat o ACL de xarxa al costat d’AWS. Els selectors correctes no protegeixen una trama de ser descartada més endavant.

Quan encara falla després que els selectors coincideixin

Confirmeu que la ruta a tots dos costats apunta al túnel, i després confirmeu que el dispositiu NAT no reescriu el trànsit d’una manera que la política no espera. Un túnel basat en política coincideix amb les adreces de les trames, així que una traducció aplicada després de la decisió de política canvia el resultat.

Registreu una trama d’entrada i una de sortida a cada costat abans de canviar una altra proposta.

Anoteu els selectors, les propostes de fase 1 i fase 2 i l’adreça d’origen al tiquet. Aquests quatre valors expliquen la majoria de fallades site-to-site sense cap trucada.

Articles relacionats