EC2 Elastic IP er ekki einkafang VPN-tilviksins

Tilvikið hefur einkafang, Elastic IP er tengt því, og leið fyrir þetta opinbera /32 er bætt við VPN í von um að þau verði sami hluturinn. Það verður ekki. Elastic IP er þýðing sem framkvæmd er utan gestarins, af internetgáttinni, á umferð sem fer internetleiðina. Stýrikerfi gestarins sér aldrei þetta fang stillt á tengi. Að bæta því við göngutengi endurgerir ekki þýðinguna ofar og býr til aðra, misvísandi auðkenni fyrir sömu vél.

Tvö föng, eitt tilvik

Nettengi tilviksins heldur einkafangi innan VPC, og það er fangið sem gesturinn þekkir. Elastic IP er tengt sama tengi en lifir á opinberri hlið vörpunarinnar.

Allt sem nær til tilviksins um internetið kemur þýtt yfir á einkafangið. Allt sem tilvikið sendir á internetið fer út með Elastic IP sem upptök, aftur vegna þeirrar þýðingar.

Inni í gestinum er eitt fang. Utan hans eru tvö. Þessi ósamhverfa skýrir mestu ruglið á þessu sviði. Gesturinn getur ekki stillt það sem gáttin þýðir. Hann getur aðeins svarað á fanginu sem hann hefur í raun.

Hvað internetgáttin gerir í raun

Skjöl AWS um internetgáttina lýsa fyrirkomulaginu: tilvikið er meðvitað um einkafang sitt IPv4, og gáttin veitir samsvarandi þýðingu á opinberu IPv4 eða Elastic IP fyrir umferð á internetleiðinni.

Þetta er þýðing netfanga, ekki samheiti. Gáttin heldur vörpuninni, hún er bundin við samtengingu og á aðeins við um pakka sem fara í gegnum hana. Fjarlægðu samtenginguna og opinbera auðkennið hverfur án þess að gesturinn taki eftir neinu.

Þess vegna er einkapakki VPN sem er beint á opinbera /32 ekki endurtúlkaður sem einkapakki á staðarfang gestarins. Pakkinn fylgir leiðinni sem hann passar við, sem sendir hann á internetgáttina, og hegðun gáttarinnar fer eftir því hvort leiðin er leyfð í báðar áttir.

Hvers vegna brellan með göngutengið mistekst

Að úthluta Elastic IP á göngutengi biður gestinn að meðhöndla opinbert fang sem staðbundið. Nú gera tveir hlutir tilkall til sama fangs: þýðing gáttarinnar á internetleiðinni og staðbundið tengið inni í göngunni. Endurkoma hefur ekki samkvæmt svar um hvert þeirra gildir.

Jafnvel þegar það virðist virka hefur hönnunin falið raunverulegu spurninguna. Biðlarar ná annað hvort einkafanginu í gegnum gönguna eða opinberu endastöðinni í gegnum internetið, og leiðirnar tvær hafa mismunandi öryggishópa, mismunandi skráningu og mismunandi bilanatilfelli.

Fangið var aldrei vandamálið. Leiðarvalið var það.

Þrjú markmið, þrjár hannanir

Ef markmiðið er opinber VPN-endastöð, er Elastic IP rétta tólið: fjarlægir jafningjar tengjast henni um internetið og dulritaða flutningnum lýkur á tilvikinu. Innri umferð forritsins notar þá einkafangið.

Ef markmiðið er einkaaðgangur að forritinu, er áfangastaðurinn einkafangið eða einkat DNS-nafn sem leysir til þess, og VPN-leiðin, öryggishópurinn og endurleiðin verða öll að stemma. Elastic IP kemur alls ekki fyrir í þeirri hönnun.

Ef markmiðið er stöðugt opinbert útgangsauðkenni fyrir VPN-notendur, er það NAT-hönnun á útgangshliðinni, ekki fang á göngu biðlarans. Þrjú markmið sem hljóma svipað gefa þrjár mismunandi skýringarmyndir, og aðeins ein þeirra felur í sér að setja Elastic IP á nýjan stað.

Staðfestu leiðina sem þú valdir

Fyrir einkaaðgang, staðfestu að VPN-leiðin nái yfir einkaforskeytið, að leiðatöflu VPC skili umferð í gönguna, að öryggishópurinn leyfi upptök biðlarans og að eigin eldveggur biðlarans leyfi svarið. Prófaðu síðan eina raunverulega beiðni í stað ping.

Fyrir opinn aðgang, staðfestu internetútgang biðlarans, leiðsögn opinberu inngöngunnar og öryggisstefnu hennar. Hvort VPN-biðlari getur náð opinberri endastöð í gegnum gönguna fer eftir útgangs- og eldveggjareglum göngunnar, ekki samtengingu Elastic IP.

Ef opinbert hýsilnafn á að virka frá báðum hliðum, notaðu DNS-hönnun sem svarar með einkafanginu fyrir VPN-biðlara og opinbera fanginu fyrir alla aðra, og haltu vottorðinu gildum fyrir nafnið frekar en fangið. Vinnuröð: nefndu markmiðið, veldu fangið sem tilheyrir því og staðfestu síðan leiðir, stefnu og eina beiðni.