AWS Client VPN er tengt, en EC2 svarar samt ekki

Fartölvan mín sagði tengt. AWS Client VPN-biðlarinn sýndi grænt ástand sitt, endpoint skráði lotu, og samt náði ég ekki að opna MongoDB-gátt á EC2-tilviki í einkaundirneti. Ekkert var augljóslega bilað: skírteinið var gilt, sniðið kom frá stjórnborðinu og göngin báru umferð. Mistökin voru mín, því ég las tengt sem heimilað.

Innskráning svarar nákvæmlega einni spurningu: má þessi auðkenni stofna lotu? Allt það sem kemur á eftir er ákveðið af aðskildum reglum sem sjá aldrei skírteinið þitt. Lota sem auðkennir sig og pakki sem kemur að eru tveir mismunandi árangrar, og bilið á milli þeirra er þar sem flest tilkynningin af gerðinni VPN er uppi en hýsillinn er óaðgengilegur lifa.

Athuganirnar hér fyrir neðan eru röðin sem ég nota núna.

Hvað tengt lota sannar í raun

Meðan á handshake stendur staðfestir endpoint biðlaraskírteinið gagnvart trust store sínu, eða beinir vafranum að auðkennisveitunni þinni þegar SAML er stillt. Ef það gengur, fær biðlarinn vistfang úr biðlara-CIDR endpoint og stjórnborðið sýnir virka tengingu. Á engum punkti í þeirri skiptum spyr neitt hvort þú megir ná 10.0.4.17 á gátt 27017.

Heimild fyrir áfangastað er aðskilinn hlutur á endpoint. Hvert streymi er borið saman við heimildarreglurnar, og hver þeirra parar áfangastaðar-CIDR við hópinn sem reglan er veitt. Þegar engin regla nær yfir áfangastaðinn tekur endpoint lotunni og hendir umferðinni. Það er enginn borði, engin endurtengingarlykkja og ekkert í viðmóti biðlarans sem segir hafnað.

Berðu heimildarregluna saman við auðlindina, ekki VPC-ið

Skráðu reglurnar og settu þær við hlið vistfangsins sem tilvikið hefur í raun:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Úttakið sýnir áfangastaðar-CIDR og hóp-ID fyrir hverja reglu. Tvö mistök leynast í því. Reglan getur heimilað 10.0.0.0/16 á meðan tilvikið situr í peeruðu VPC á 10.1.0.0/16; peering-slóðin er til, en enginn skrifaði heimildarreglu fyrir seinna sviðið. Eða reglan vísar á skráarhóp sem notandinn tilheyrir í skránni en ekki í hópnum sem endpoint metur.

Skrifaðu þrengstu regluna sem nær yfir áfangastaðinn, og bættu annarri við aðeins þegar annað CIDR er sannarlega nauðsynlegt. Breið 0.0.0.0/0 regla frá skjótri byrjun virkar, og þess vegna lifir hún inn í framleiðslu og felur líkanið.

Tvær slóðatöflur ákveða hvort pakkinn hreyfist

Endpoint-slóð varpar áfangastaðar-CIDR á eitt af undirnetunum sem endpoint er tengt. Það er hálf leið. Eigin slóðatafla undirnetsins verður enn að vita hvernig pakkinn er sendur áfram, og það skiptir máli á þeirri stundu þegar áfangastaðurinn er bak við peering-tengingu, transit gateway eða staðbundið svið sem er aðgengilegt um site-to-site göng.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Leitaðu að slóð þar sem áfangastaðurinn passar við CIDR auðlindarinnar og markið er tengt undirnet. Ef slóðin vantar, bættu henni við. Ef hún er til og hýsillinn þegir enn, er bilið á VPC-hliðinni, svo berðu saman við slóðatöflu tengingarundirnetsins.

Ein stilling á biðlarahlið brýtur leiðsögn án þess að brjóta göngin: snið sem inniheldur route-nopull. Fyrirmælin segja biðlara sem byggir á OpenVPN að hunsa slóðirnar sem þjónninn ýtir, svo viðmótið rís aðeins með eigin vistfangi endpoint og áfangastaðurinn hefur einfaldlega enga slóð. Athugaðu með ip route show á Linux eða netstat -rn á macOS hvort slóð um tun-viðmótið er til. Ef ekki, fjarlægðu route-nopull úr útfluttu sniðinu og tengdu aftur svo ýttu slóðirnar gildi.

Öryggishópar sjá ekki vistfang biðlarans þíns

Þetta er hlutinn sem ég hafði rangt í heilan síðdegi. Fyrir IPv4-endpoint sem er tengt undirneti þýðir þjónustan upprunavistfang biðlarans í vistfang netviðmóts endpoint í því undirneti. Pakkinn sem kemur að tilvikinu ber ekki vistfangið sem biðlarinn þinn sýndi, svo öryggishóparegla sem heimilar biðlarahópinn, segjum 172.16.0.0/22, passar við ekkert.

Heimilaðu gáttina frá öryggishópi endpoint, sem er festur við viðmót tengingarinnar, frekar en frá biðlara-CIDR. Að vísa í hópinn er varanlegra en að harðkóða vistfang, því viðmótsvistfangið er ekki þitt að stjórna. Net-ACL eru án stöðu, svo þar sem sérsniðnar færslur eru verða bæði innstreymis- og útstreymisstefnan að heimila streymið.

Tengdu líka við einkavistfang tilviksins. Opinbert IP færir pakkann út úr VPC og inn aftur um aðra leið með öðrum reglum, svo próf á opinberu vistfangi segir ekkert um einkaleiðina.

Einangrunarröð sem stöðvast við fyrstu bilun

Farðu í gegnum þessar í röð og stöðvaðu þar sem ein bregst. Hvert skref útilokar eitt lag frekar en öll.

1. Staðfestu hvaða auðkenni lotan notaði og hvaða hóp endpoint metur. Skírteini frá einu trust store er ekki sami aðilinn og SAML-yrðing frá skránni.
2. Staðfestu að heimildarregla nái yfir CIDR auðlindarinnar fyrir þann hóp.
3. Staðfestu að endpoint-slóð sé til og beinist að tengdu undirneti, og svo að slóðatafla undirnetsins geti sent áfram.
4. Staðfestu að öryggishópurinn heimili gáttina frá viðmóti endpoint, ekki frá biðlarahópnum.
5. Prófaðu innan úr VPC, með SSM-lotu á öðru tilviki í sama undirneti, til að aðskilja forritavandamál frá vandamáli í biðlaraleiðinni.

Þegar skrefin eru ekki afgerandi, er þessi tafla það sem ég gríp til:

Tveir reikningsupplýsingar framleiða einkenni sem líta út eins og heimildarbilanir. Hver notandi þarf sér skírteini biðlarans; að deila einu á milli tveggja véla lætur loturnar þrýsta hvor annarri út, og útkoman er endurtengingarlykkja frekar en synjun. Þegar nýtt endpoint er búið til sýnir stjórnborðið DNS-nafn sem sumar biðlaraútgáfur samþykkja aðeins með slembiforskeytinu sem birtist á endpoint-síðunni, svo afritaðu fulla nafnið í stað þess að endurgera það.

Ef fimmta skrefið stöðvar þig, náðu í tengiskrá endpoint og lestu heimildarfærslurnar áður en þú breytir nokkru. Skráin nefnir áfangastaðinn sem var athugaður og regluna sem passaði eða passaði ekki, og það þjappar spurningunni um fjögur lög í eitt svar.