Elastic IP v EC2 ni zasebni naslov VPN instance

Instanca ima zasebni naslov, Elastic IP je povezan z njim, in pot za ta javni /32 se doda v VPN v upanju, da bosta oba postala ista stvar. Ne postaneta. Elastic IP je prevod, ki se izvede zunaj gosta, prek internetnega prehoda, na prometu, ki gre po internetni poti. Operacijski sistem gosta nikoli ne vidi tega naslova konfiguriranega na vmesniku. Njegova dodaja na vmesnik tunela ne ponovi zgornjega prevoda in ustvari drugo, nasprotujočo identiteto za isti stroj.

Dva naslova, ena instanca

Omrežni vmesnik instance ima zasebni naslov znotraj VPC, in to je naslov, ki ga gost pozna. Elastic IP je povezan z istim vmesnikom, vendar živi na javni strani preslikave.

Vse, kar doseže instanco prek interneta, prispe prevedeno na zasebni naslov. Vse, kar instanca pošlje v internet, odide z Elastic IP kot virom, spet zaradi tega prevoda.

Znotraj gosta obstaja en naslov. Zunaj dva. Ta asimetrija pojasnjuje večino zmede na tem področju. Gost ne more konfigurirati, kaj prehod prevaja. Lahko odgovori le na naslovu, ki ga dejansko ima.

Kaj internetni prehod dejansko počne

Dokumentacija AWS o internetnem prehodu opisuje ureditev: instanca pozna svoj zasebni naslov IPv4, prehod pa zagotavlja ustrezni prevod v javni IPv4 ali Elastic IP za promet na internetni poti.

To je prevajanje omrežnih naslovov, ne alias. Preslikavo vzdržuje prehod, vezana je na povezavo in velja le za pakete, ki gredo skoznjo. Odstranite povezavo in javna identiteta izgine, ne da bi gost kar koli opazil.

Zato se zasebni paket VPN, naslovljen na javni /32, ne reinterpretira kot zasebni paket na lokalni naslov gosta. Paket sledi poti, ki se ujema, ta pa ga pošlje internetnemu prehodu, vedenje prehoda pa je odvisno od tega, ali je pot dovoljena v obe smeri.

Zakaj trik z vmesnikom tunela ne uspe

Dodelitev Elastic IP vmesniku tunela zahteva od gosta, da javni naslov obravnava kot lokalnega. Zdaj si isti naslov lastita dve stvari: prevod prehoda na internetni poti in lokalni vmesnik znotraj tunela. Povratni promet nima doslednega odgovora, kateri velja.

Tudi ko se zdi, da deluje, je zasnova skrila pravo vprašanje. Odjemalci dosežejo zasebni naslov skozi tunel ali javno končno točko prek interneta, in ti dve poti imata različne varnostne skupine, različno beleženje in različne načine odpovedi.

Naslov nikoli ni bil težava. Izbira poti je bila.

Trije cilji, tri zasnove

Če je cilj javna končna točka VPN, je Elastic IP pravo orodje: oddaljeni partnerji se nanjo povežejo prek interneta in šifriran prenos se konča na instanci. Notranji promet aplikacije nato uporablja zasebni naslov.

Če je cilj zasebni dostop do aplikacije, je cilj zasebni naslov ali zasebno ime DNS, ki se nanj razreši, in pot VPN, varnostna skupina ter povratna pot se morajo vse ujemati. Elastic IP v tej zasnovi sploh ne nastopa.

Če je cilj stabilna javna izhodna identiteta za uporabnike VPN, je to zasnova NAT na izhodni strani, ne naslov na tunelu odjemalca. Trije podobno zveneči cilji dajo tri različne diagrame in le eden od njih vključuje postavitev Elastic IP na novo mesto.

Preverite pot, ki ste jo izbrali

Za zasebni dostop preverite, da pot VPN pokriva zasebno predpono, da usmerjevalna tabela VPC vrača promet v tunel, da varnostna skupina dovoljuje vir odjemalca in da lastni požarni zid odjemalca dovoljuje odgovor. Nato preizkusite eno resnično zahtevo namesto pinga.

Za javni dostop preverite internetni izhod odjemalca, usmerjanje javnega vhoda in njegovo varnostno politiko. Ali lahko odjemalec VPN doseže javno končno točko skozi tunel, je odvisno od pravil izhoda in požarnega zidu tunela, ne od povezave Elastic IP.

Če mora javno ime gostitelja delovati z obeh strani, uporabite zasnovo DNS, ki odgovori z zasebnim naslovom odjemalcem VPN in z javnim naslovom vsem drugim, in ohranite potrdilo veljavno za ime, ne za naslov. Vrstni red dela: poimenujte cilj, izberite naslov, ki mu pripada, in nato preverite poti, politiko in eno zahtevo.