Elastic IP u EC2 nije privatna VPN adresa instance

Instanca ima privatnu adresu, Elastic IP je povezan s njom, a ruta za taj javni /32 dodaje se u VPN u nadi da će to dvoje postati isto. Ne postaju. Elastic IP je prijevod koji se izvodi izvan gosta, pomoću internetskog pristupnika, na prometu koji ide internetskim putem. Operacijski sustav gosta nikada ne vidi tu adresu konfiguriranu na sučelju. Dodavanje na tunelsko sučelje ne reproducira uzvodni prijevod i stvara drugi, proturječni identitet za isti stroj.

Dvije adrese, jedna instanca

Mrežno sučelje instance drži privatnu adresu unutar VPC-a, i to je adresa koju gost poznaje. Elastic IP povezan je s istim sučeljem, ali živi na javnoj strani preslikavanja.

Sve što do instance stigne putem interneta dolazi prevedeno na privatnu adresu. Sve što instanca pošalje na internet odlazi s Elastic IP-om kao izvorom, opet zbog tog prijevoda.

Unutar gosta postoji jedna adresa. Izvana postoje dvije. Ta asimetrija objašnjava većinu zbrke u ovom području. Gost ne može konfigurirati ono što pristupnik prevodi. Može odgovarati samo na adresi koju stvarno drži.

Što internetski pristupnik zapravo radi

AWS-ova dokumentacija o internetskom pristupniku opisuje raspored: instanca je svjesna svoje privatne IPv4 adrese, a pristupnik osigurava odgovarajući prijevod javne IPv4 ili Elastic IP adrese za promet na internetskom putu.

To je prijevod mrežnih adresa, a ne alias. Preslikavanje održava pristupnik, vezano je uz asocijaciju i primjenjuje se samo na pakete koji ga prolaze. Uklonite asocijaciju i javni identitet nestaje, a gost ništa ne primjećuje.

Zato se privatni VPN paket upućen na javni /32 ne tumači ponovno kao privatni paket na lokalnu adresu gosta. Paket slijedi rutu kojoj odgovara, koja ga šalje internetskom pristupniku, a ponašanje pristupnika ovisi o tome je li put dopušten u oba smjera.

Zašto trik s tunelskim sučeljem ne uspijeva

Dodjela Elastic IP-a tunelskom sučelju traži od gosta da javnu adresu tretira kao lokalnu. Sada dvije stvari polažu pravo na istu adresu: pristupnikov prijevod na internetskom putu i lokalno sučelje unutar tunela. Povratni promet nema dosljedan odgovor koje od njih vrijedi.

Čak i kad se čini da radi, dizajn je sakrio pravo pitanje. Klijenti ili dosežu privatnu adresu kroz tunel ili dosežu javnu krajnju točku kroz internet, a ta dva puta imaju različite sigurnosne grupe, različito zapisivanje i različite načine kvara.

Adresa nikada nije bila problem. Odabir puta je bio.

Tri cilja, tri dizajna

Ako je cilj javna VPN krajnja točka, Elastic IP je pravi alat: udaljeni partneri povezuju se s njim preko interneta i šifrirani prijevoz završava na instanci. Unutarnji promet aplikacije zatim koristi privatnu adresu.

Ako je cilj privatan pristup aplikaciji, odredište je privatna adresa ili privatno DNS ime koje se u nju razrješava, a VPN ruta, sigurnosna grupa i povratni put moraju se svi slagati. Elastic IP u tom dizajnu uopće se ne pojavljuje.

Ako je cilj stabilan javni identitet izlaza za VPN korisnike, to je NAT dizajn na strani izlaza, a ne adresa na klijentskom tunelu. Tri cilja koja zvuče slično daju tri različita dijagrama, a samo jedan uključuje stavljanje Elastic IP-a na novo mjesto.

Provjerite put koji ste odabrali

Za privatan pristup potvrdite da VPN ruta pokriva privatni prefiks, da VPC tablica ruta vraća promet u tunel, da sigurnosna grupa dopušta izvor klijenta i da klijentov vlastiti vatrozid dopušta odgovor. Zatim testirajte jedan stvarni zahtjev umjesto pinga.

Za javni pristup potvrdite klijentov internetski izlaz, usmjeravanje javnog ulaza i njegovu sigurnosnu politiku. Može li VPN klijent dosegnuti javnu krajnju točku kroz tunel ovisi o pravilima izlaza i vatrozida tunela, a ne o asocijaciji Elastic IP-a.

Ako javno ime hosta mora raditi s obje strane, upotrijebite DNS dizajn koji odgovara privatnom adresom za VPN klijente i javnom adresom za sve ostale, i držite certifikat valjanim za ime, a ne za adresu. Redoslijed rada: imenujte cilj, odaberite adresu koja mu pripada, zatim provjerite rute, politiku i jedan zahtjev.