strongSwan na AWS Site-to-Site: waarom die Child SA niks selekteer nie

’n IKE-tonnel kan op wees terwyl die child-assosiasie jou subnetwerke uitsluit. Vergelyk eers die plaaslike en afgeleë CIDR’s in AWS met leftsubnet en rightsubnet.

Die konsole wys op, strongSwan rapporteer ’n gevestigde IKE-assosiasie, en pakkette kom steeds nie aan nie. Die volgende ding om te vergelyk is nie die vooraf gedeelde sleutel nie, maar die paar prefikse wat elke kant dink die tonnel beskerm. Gaan die kontroles hieronder in volgorde deur, want die eerste twee besluit of die tonnel jou verkeer hoegenaamd kan dra.

Vertaal die AWS-benamings na strongSwan se terme

AWS beskryf die verbinding van die klantekant af: die klantpoortadres en plaaslike CIDR behoort aan jou, en die afgeleë CIDR behoort aan die VPC. strongSwan noem die twee kante links en regs, met jou prefiks in leftsubnet en die VPC-prefiks in rightsubnet. As jy een paar omkeer, kry jy ’n tonnel wat die verkeerde verkeer beding en selekteer.

Laai die konfigurasie af wat AWS vir die verbinding genereer en gebruik dit as die verwysing vir daardie spesifieke verbinding, insluitend tonneladresse en prefikse. As jy albei CIDR-velde by die skepping leeg laat, gebruik die diens ’n verstek van 0.0.0.0/0 aan elke kant. ’n Roeteerder wat met ’n smal prefiks opgestel is, sal dit dan nooit pas nie, so vul die velde in of maak die selektor doelbewus wyer.

’n Wanverhouding hier lyk soos ’n roeteerfout en is nie een nie.

Pen die adres vas wat AWS werklik sien

’n Roeteerder agter NAT kan IKE vanaf ’n koppelvlak stuur waarvan die ander kant nooit geleer het nie. Die poortadres wat in AWS aangeteken is, moet die een wees wat AWS op die draad sien, en die roeteerder moet aan dieselfde plaaslike adres vasgepen word eerder as om sy verstekroete te volg.

conn %default
    local_addrs = 203.0.113.10

In strongSwan kies local_addrs die bronadres vir IKE, en ouer OpenSwan-konfigurasies spel dieselfde idee as left. Wys dit na die koppelvlak wat die openbare adres hou, en verifieer dan op die NAT-toestel self dat UDP 500 en 4500 daardie gasheer bereik, want ’n reël wat van ’n vroeëre roeteerder oorgebly het, laat hulle stilweg val. ’n Korrekte selektorpair met die verkeerde bronadres misluk steeds, en die log sal die voorstel blameer. Daardie misleiding is waarom die bronadres sy eie kontrole verdien.

Bevestig die aanstuurreël eerder as om dit te aanvaar, want ’n reël wat vir die vorige roeteerder reg was, is ’n algemene oorblyfsel.

Behandel fase 1 en fase 2 afsonderlik

AWS stel IKE- en ESP-opsies as afsonderlike lyste bekend. ’n IKE-stel wat albei kante aanvaar, sê niks oor die ESP-voorstel nie, want die twee lyste is onafhanklik. Lees albei uit die gegenereerde konfigurasie en vergelyk hulle een op ’n slag.

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

Sintaksis reis nie tussen implementasies nie. ’n Paar wat in OpenSwan werk, soos phase2alg=aes_gcm met ike=aes256-sha1;modp1024, moet in strongSwan se esp= en ike=-vorm vertaal word, en die algoritmename verskil. Omdat GCM verifieer terwyl dit versleutel, het dit geen aparte integriteitstransform nodig nie, anders as ’n CBC-stel wat met SHA gepaar is. ’n Fase 2-reël wat onvertaal van een daemon na ’n ander geplak word, lewer ’n verwerping op wat soos ’n selektorwanverhouding lees.

Kontroleer die kind-assosiasie, nie die tonnelaanwyser nie

As die verbinding laai maar geen kind-assosiasie opkom nie, is óf die voorstel óf die selektors geweier. As daar wel ’n kind opkom en sy selektors sluit jou prefikse uit, word pakkette gefiltreer voordat hulle die tonnel bereik. Die konsole se aanwyser dek net die IKE-vlak, so dit kan nie vir jou sê watter van die twee gebeur het nie.

ipsec statusall

Soek die kind-sekuriteitsassosiasie en lees die verkeersselektors wat daarnaas gedruk is, en vergelyk hulle dan met die prefikse uit die gegenereerde konfigurasie.

Toets van ’n gasheer binne die plaaslike prefiks na ’n gasheer binne die VPC-prefiks, en kontroleer die terugpad plus enige sekuriteitsgroep of netwerk-ACL aan die AWS-kant. Korrekte selektors beskerm nie ’n pakket teen later val nie.

Wanneer dit steeds misluk nadat die selektors pas

Bevestig dat die roete aan albei kante na die tonnel wys, en bevestig dan dat die NAT-toestel nie verkeer herskryf op ’n manier wat die beleid nie verwag nie. ’n Beleidgebaseerde tonnel pas op pakketadresse, so ’n vertaling wat ná die beleidsbesluit toegepas word, verander die uitkoms.

Teken een pakket in en een pakket uit aan elke kant voordat jy nog ’n voorstel verander.

Teken die selektors, die fase 1- en fase 2-voorstelle en die bronadres in die kaartjie aan. Daardie vier waardes verduidelik die meeste site-to-site-mislukkings sonder ’n oproep.

Verwante artikels