AWS Client VPN með skiptri göng: hvaða leiðir þú ættir að birta

Stjórnborðið býður upp á rofa fyrir skipt göng, svo ákvörðunin virðist eins og gátbox. Hún er það ekki. Það sem raunverulega berst til biðlarans er birt leiðasett endapunktsins, og sá listi ræður því hvaða einkaforskeyti nota göngin, hvort almenn netumferð verður staðbundin eða fer út um AWS, og við hvaða resolver biðlarinn getur enn talað. Þrjár spurningar ráða hönnuninni, og hægt er að svara hverri þeirra illa á meðan tengingin tekst samt.

Fáninn fyrir skipt göng er ekki áfangalisti

AWS lýsir skiptum göngum sem viðbæti leiða endapunktsins við leiðatöflu biðlarans þegar tenging er sett upp. Leið fyrir einkarekna VPC takmarkar göngin við þann áfangastað; allt annað fylgir venjulegri leið biðlarans. Sjálfgefin leið er önnur fyrirmæli með aðra virkni, þess vegna varar skjölunin um skipt göng við að birta 0.0.0.0/0 á endapunkt sem er stilltur fyrir þennan hátt: það brýtur tengingu frekar en að útvíkka hana. Leiðatafla endapunktsins er stefnan, og leiðatafla biðlarans er niðurstaðan sem þú getur skoðað.

Lestu leiðatöflu endapunktsins og uppsettu leiðir biðlarans saman. Merkið lýsir áformi; leiðirnar lýsa því sem gerist.

Fyrsta ákvörðun: á almenn netumferð að vera staðbundin?

Ef vafran á að nota eigin tengingu notandans skaltu aðeins birta þá einkareknu áfangastaði sem verkið þarf og stoppa þar. Ekki bæta við netleið vegna þess að kennsluefni um heil göng hafði eina, og ekki gera ráð fyrir að aukaleiðin bæti öryggi. Hún breytir leiðinni, bætir ekki við stefnu, og kostar venjulega seinkun sem þú áætlaðir ekki.

Ef netumferð á að fara út um AWS skaltu byggja skjalfesta netaðgangsarkitektúrinn: leið endapunkts, heimildarreglur, leið tengda undirnetsins, öryggisstefnu og vinnandi útstreymi. Ein sjálfgefin leið veitir ekkert af þessu.

Önnur ákvörðun: hvaða einkaforskeyti, heimilað af hverjum?

Birtu minnsta sett áfangastaða sem þjónar raunverulegu vinnuálagi, og athugaðu að hvert tengt undirnet geti beint leið til þeirra. Leiðarmarkmið endapunktsins og VPC-beining undirnetsins eru mismunandi lög, og leið sem er til í öðru er ekki sönnun um hið síðara. Heimildin er aftur aðskilin: áfangastaður getur verið aðgengilegur og samt neitað því að hópur biðlarans hefur enga reglu sem leyfir hann.

Að prófa eina farsæla lotu sannar eina leið. Athugaðu hvert tengt undirnet, því undirnetstenging sem var bætt við síðar er einmitt staðurinn þar sem vantandi leiðin er venjulega.

Þegar áfangastaður verður að vera aðgengilegur eftir nafni skaltu hafa í huga að næsta spurning er nafnaleysing, ekki leiðin.

Þriðja ákvörðun: hvaða resolver fylgir göngunum?

Biðlari getur fengið DNS-þjón sem er aðeins aðgengilegur í gegnum VPN, og sá resolver virkar aðeins ef vistfang hans er sjálft innan heimilaðrar leiðar. Staðfestu báða helminga: vistfang resolversins fylgir birtri leið, og þjónninn svarar þeim nöfnum sem forritið spyr um. Beiðni sem tekst eftir vistfangi en mistekst eftir hýsinafni bendir á nafngift, ekki beiningu, og að kemba göngin í því tilfelli sóar síðdeginu.

Opinber nöfn ættu að leysast eins og fyrir tenginguna, sem er önnur ástæða til að vera nákvæm um það sem þú birtir.

Breyttu leiðasetinu og staðfestu síðan báða heimana

AWS skjalfestir að breyting leiða á endapunkti skiptra ganga endurstillir tengingar biðlara. Skipuleggðu breytinguna með það í huga: beittu henni, tengdu aftur í gegnum studda biðlarann og lestu uppsettu leiðirnar að nýju í stað þess að treysta stöðu sem var beitt fyrir breytinguna. Úrelt beitt staða er algengasta ástæðan fyrir því að rétt breyting virðist brotin.

Samþykktu hönnunina aðeins þegar ein einkarekinn auðlind og einn opinber áfangastaður hegða sér eins og ætlað er, eftir nafni og vistfangi, í þeim vistfangafjölskyldum sem þú styður í raun. Göng sem auðkenna eru ekki það sama og göng sem skipta rétt.

Skrifaðu leiðarlistann í runbook við hlið röksemdarinnar, svo næsta manneskja geti greint viljandi útilokun frá gleymdri.