strongSwan á EC2: látu VPC-ina beina vinnuálaginu

Tunnill sem virkar frá gáttinni sannar aðeins gáttina. Beindu undirneti vinnuálagsins, kveiktu á framsendingu á gestinum, víkkaðu valarana og prófaðu svo frá því.

Tunnillinn er uppi, gáttarílátið getur pingað fjarnetið, og forritarílátið við hliðina nær engu. Ekkert er bilað. Prófið sem tókst byrjaði á VPN-hýsilnum, og það spurði aldrei hvort sá hýsill gæti borið annað upprunanetfang í gegnum sama IPsec-sambandið. Þessi leiðarvísir lokar því bili í fjórum skrefum, í þeirri röð sem heldur hverri bilun sýnilegri.

Skrifaðu fyrst niður netfangið fjögur

Hvert skref hér að neðan vísar í þau, svo fylltu þau út fyrir þinn eigin reikning áður en þú snertir beiningartöflu.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Dæmið gerir ráð fyrir samþykktri, virkri stefnubundinni IPsec-tengingu og flæði sem varðveitir uppruna. Þetta er ekki NATaður fjartengingarþjónn sem fær eitt úthlutað netfang að láni, og sá munur ræður því hvort valararnir þurfi að breytast.

Skref 1: gefðu undirneti vinnuálagsins beiningu

Beiningartaflan sem er í raun tengd undirneti vinnuálagsins þarf slóð fyrir fjartáknið sem bendir á netviðmót gáttarinnar. Gestabeining sem sett er upp inni í ílátinu er ekki færsla í þeirri AWS-beiningartöflu, og engin uppsetning strongSwan mun búa hana til.

Leiðbeiningar AWS um beiningar gegnum tæki lýsa skotmörkum netviðmóts og kröfunni um uppruna/áfangastað eftirlit framsendingarílátsins. Takmarkaðu þá eftirlitsbreytingu við hlutverk gáttarinnar og láttu venjuleg forritarílát vera í friði.

Skiptu ekki út staðbundinni beiningu VPC-sins né hverri fyrirliggjandi færslu til að gera pláss fyrir eitt samþykkt net. Skoðaðu hvað er tengt og virkt frekar en hvað stjórnborðssíða sýnir fyrir beiningartöflu sem enginn notar. Tvær töflur sem líta eins út geta haft mismunandi tengingar. Sú sem skiptir máli er sú sem undirnet vinnuálagsins er tengt við.

Skref 2: kveiktu á framsendingu á gestinum

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Kjarninn verður að senda áfram og eldveggur hýsilsins að leyfa gegnumstreymið. Bættu við fyrirhuguðum framsendingarreglum fyrir táknið vinnuálagsins og fjar-táknið í stað þess að samþykkja allt, og staðfestu að gáttarundirnetið haldi nothæfri flutningsslóð fyrir eigin umferð.

Öryggishópar eru þar sem þetta skref stöðvast venjulega. Millitæki erfa ekki tilvísunarhegðun öryggishópa beinnar ílátasamskipta, svo regla sem afrituð er úr dæmi um stýrða Client VPN passar kannski aldrei. Athugaðu öryggishópinn og undirnets-ACL á raunverulegu slóðinni, í báðar áttir.

Skref 3: víkkaðu valarana að raunverulegu upprununum

Stefna sem nær aðeins yfir 10.60.1.10/32 á AWS-hliðinni útskýrir árangur sem byrjaði á gáttinni án þess að ná yfir 10.60.2.20. Beining í átt að fjaráfangastaðnum víkkar ekki umferðarvalara, og það er seinni helmingurinn af sömu óvæntu upplifun.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Ef samþykkta hönnunin verndar allt VPC-ið verða báðir jafningjar að samþykkja 10.60.0.0/16 og 10.90.0.0/24. Ef hún verndar eitt vinnuálag skaltu nota það þrengra tákn viljandi. Hvort sem er, skoðaðu uppsettu CHILD-SA-stefnuna, því uppsetning sem þú breyttir og jafningi sem þrengdi hana öðruvísi eru ekki sami samningurinn.

Fjarstaðurinn verður líka að beina svörum fyrir varðveittu VPC-upprunana til baka gegnum fyrirhuguðu IPsec-gáttina. Haltu studdu NAT-undanþágunni fyrir verndaða umferð þar sem aðrar uppruna-NAT-reglur eru til; að þýða ósamþykkt vinnuálag í leyft hýsilnetfang er annar sjálfsmyndarsamningur, ekki flýtileið að þeim aðgangi sem þú vildir.

Skref 4: staðfestu og farðu svo til baka ef þörf krefur

Prófaðu frá vinnuálaginu sjálfu með nýrri leyfðri forritaaðgerð og endurtaktu svo með áfangastað sem ætti að vera útilokaður. Skráðu upprunanetfangið sem fjartengda þjónustan sér og afturleiðina sem hún notar. Ping á gátt eða græn IKE-staða er ekki það próf.

Ef vinnuálagið mistekst áfram meðan gáttin virkar skaltu ganga til baka í gegnum skrefin í röð: valari, svo framsending og öryggishópar, svo tengda beiningartöflan. Hvert þeirra hefur sitt einkenni, og gisk sleppir því sem er í raun rangt.

Afturköllun snýr sömu röð við. Fjarlægðu beiningu undirnets vinnuálagsins síðast, eftir að hafa endurheimt fyrri valarana, svo þú skiljir ekki eftir undirnet sem bendir á gátt sem verndar ekki lengur upprunana. Sjálfhýsing getur þjónað meiru en gáttarhýsilnum þegar þessir samningar standast, og Site-to-Site VPN sem AWS stýrir er önnur rekstrarlíkan þar sem strongSwan getur setið við hlið viðskiptavinagáttarinnar í staðinn.

Tengdir greinar