EC2-ko Elastic IP bat ez da instantziaren VPN helbide pribatua

Instantziak helbide pribatu bat du, Elastic IP-a hari lotuta dago, eta /32 publiko horretarako bide bat VPNari gehitzen zaio biak gauza bera izango direlakoan. Ez dira. Elastic IP-a gonbidatuaren kanpoaldean egiten den itzulpena da, interneteko atebidearen eskutik, interneteko bidea hartzen duen trafikoan. Gonbidatuaren sistema eragileak ez du inoiz helbide hori interfaze batean konfiguratuta ikusten. Tunel-interfaze bati gehitzeak ez du goragoko itzulpena berregiten eta bigarren identitate bat sortzen du, kontraesankorra, makina bererako.

Bi helbide, instantzia bat

Instantziaren sare-interfazeak VPCren barruan helbide pribatu bat du, eta hori da gonbidatuak ezagutzen duen helbidea. Elastic IP-a interfaze berari lotuta dago, baina mapaketaren alde publikoan bizi da.

Interneten bidez instantziara iristen den guztia helbide pribatura itzulita iristen da. Instantziak internet-era bidaltzen duen guztia Elastic IP-a iturri duela ateratzen da, berriz ere itzulpen hori dela medio.

Gonbidatuaren barruan helbide bat dago. Kanpoan bi daude. Asimetria horrek azaltzen du arlo honetako nahasmenaren zatirik handiena. Gonbidatuak ezin du konfiguratu atebideak zer itzultzen duen. Benetan duen helbidean soilik erantzun dezake.

Zer egiten du benetan interneteko atebideak

AWS-en interneteko atebideari buruzko dokumentazioak antolaketa deskribatzen du: instantzia bere IPv4 helbide pribatuaz ohartzen da, eta atebideak interneteko bidean doan trafikoarentzako IPv4 publiko edo Elastic IP itzulpena ematen du.

Sare-helbideen itzulpena da, ez alias bat. Atebideak mantentzen du mapaketa, elkarketari lotuta dago, eta zeharkatzen duten paketeei soilik aplikatzen zaie. Kendu elkarketa eta identitate publikoa desagertu egiten da gonbidatuak ezer nabaritu gabe.

Horregatik, /32 publikoari zuzendutako VPN pakete pribatu bat ez da berrinterpretatzen gonbidatuaren helbide lokalera doan pakete pribatu gisa. Paketeak bat datorren bidea jarraitzen du, eta horrek interneteko atebidera bidaltzen du; atebidearen portaera bidea bi noranzkoetan baimenduta dagoen ala ez da.

Zergatik huts egiten du tunel-interfazearen trikimailuak

Elastic IP-a tunel-interfaze bati esleitzeak gonbidatuari eskatzen dio helbide publiko bat lokal gisa tratatzeko. Orain bi gauzak helbide bera eskatzen dute: atebidearen itzulpena interneteko bidean eta tunelaren barruko interfaze lokala. Itzulera-trafikoak ez du erantzun koherenterik zein aplikatzen den.

Funtzionatzen duela dirudienean ere, diseinuak benetako galdera ezkutatu du. Bezeroek tunelaren bidez helbide pribatura iristen dira edo interneten bidez amaiera-puntu publikora iristen dira, eta bi bideek segurtasun-talde desberdinak, erregistratze desberdina eta hutsegite modu desberdinak dituzte.

Helbidea ez zen inoiz arazoa izan. Bidearen hautaketa zen.

Hiru helburu, hiru diseinu

Helburua VPN amaiera-puntu publikoa bada, Elastic IP-a tresna zuzena da: urrutiko parekideak interneten bidez konektatzen dira eta garraio zifratua instantzian amaitzen da. Aplikazioaren barruko trafikoak helbide pribatua erabiltzen du gero.

Helburua aplikaziorako sarbide pribatua bada, helmuga helbide pribatua edo hara ebazten duen DNS izen pribatu bat da, eta VPNaren bideak, segurtasun-taldeak eta itzulera-bideak bat etorri behar dute. Elastic IP-a ez da diseinu horretan agertzen.

Helburua VPN erabiltzaileentzako irteera-identitate publiko egonkorra bada, hori irteera-aldeko NAT diseinu bat da, ez bezeroaren tuneleko helbide bat. Antzeko entzuten duten hiru helburuk hiru diagrama desberdin sortzen dituzte, eta horietako batek soilik dakar Elastic IP bat leku berri batean jartzea.

Egiaztatu aukeratu duzun bidea

Sarbide pribaturako, egiaztatu VPNaren bideak aurrizki pribatua estaltzen duela, VPCren bide-taulak trafikoa tunelera itzultzen duela, segurtasun-taldeak bezeroaren iturria uzten duela eta bezeroaren suebakiak erantzuna uzten duela. Gero probatu benetako eskaera bat, ping bat izan beharrean.

Sarbide publikorako, egiaztatu bezeroaren internet irteera, sarrera publikoaren bideratzea eta haren segurtasun-politika. VPN bezero bat tuneletik amaiera-puntu publikora irits daitekeen tuneleko irteera- eta suebaki-arauen araberakoa da, ez Elastic IParen elkarketaren araberakoa.

Host-izen publiko batek bi aldeetatik funtzionatu behar badu, erabili DNS diseinu bat VPN bezeroentzat helbide pribatuarekin eta gainerako guztientzat helbide publikoarekin erantzuten duena, eta mantendu ziurtagiria izenarentzat baliozkoa, ez helbidearentzat. Lan-ordena: izendatu helburua, aukeratu hari dagokion helbidea, eta gero egiaztatu bideak, politika eta eskaera bat.