'n EC2 Elastic IP is nie die instansie se private VPN-adres nie

Die instansie het 'n private adres, die Elastic IP is daaraan gekoppel, en 'n roete vir daardie publieke /32 word by die VPN gevoeg in die hoop dat die twee dieselfde ding word. Dit word nie. 'n Elastic IP is 'n vertaling wat buite die gas uitgevoer word, deur die internet-gateway, op verkeer wat die internetpad volg. Die gas se bedryfstelsel sien nooit daardie adres op 'n koppelvlak gekonfigureer nie. Om dit by 'n tonnelkoppelvlak te voeg, reproduseer nie die opstroom-vertaling nie, en dit skep 'n tweede, botsende identiteit vir dieselfde masjien.

Twee adresse, een instansie

Die instansie se netwerkkoppelvlak hou 'n private adres binne die VPC, en dit is die adres wat die gas ken. Die Elastic IP is aan dieselfde koppelvlak gekoppel maar leef aan die publieke kant van die kartering.

Enigiets wat die instansie deur die internet bereik, kom vertaal na die private adres aan. Enigiets wat die instansie na die internet stuur, verlaat met die Elastic IP as bron, weer weens daardie vertaling.

Binne die gas bestaan een adres. Buite bestaan twee. Daardie asimmetrie verduidelik meeste van die verwarring in hierdie area. Die gas kan nie konfigureer wat die gateway vertaal nie. Dit kan net antwoord op die adres wat dit werklik hou.

Wat die internet-gateway werklik doen

AWS se internet-gateway-dokumentasie beskryf die reeling: die instansie is bewus van sy private IPv4-adres, en die gateway voorsien die ooreenstemmende publieke IPv4- of Elastic IP-vertaling vir verkeer op die internetpad.

Dit is netwerkadresvertaling, nie 'n alias nie. Die kartering word deur die gateway onderhou, aan die assosiasie gekoppel, en geld net vir pakkette wat dit deurkruis. Verwyder die assosiasie en die publieke identiteit verdwyn sonder dat die gas iets agterkom.

Dit is hoekom 'n private VPN-pakket wat aan die publieke /32 geadresseer is, nie herinterpreteer word as 'n private pakket aan die gas se plaaslike adres nie. Die pakket volg die roete wat dit pas, wat dit na die internet-gateway stuur, en die gateway se gedrag hang daarvan af of die pad in beide rigtings toegelaat word.

Hoekom die tonnelkoppelvlak-truuk misluk

Om die Elastic IP aan 'n tonnelkoppelvlak toe te wys, vra die gas om 'n publieke adres as plaaslik te behandel. Nou eis twee dinge dieselfde adres: die gateway se vertaling op die internetpad en die plaaslike koppelvlak binne die tonnel. Retourverkeer het geen konsekwente antwoord oor watter een geld nie.

Selfs wanneer dit blyk te werk, het die ontwerp die werklike vraag verberg. Kliënte bereik óf die private adres deur die tonnel óf die publieke eindpunt deur die internet, en die twee paaie het verskillende sekuriteitsgroepe, verskillende logboekhouding en verskillende foutmodusse.

Die adres was nooit die probleem nie. Die padkeuse was.

Drie doelwitte, drie ontwerpe

As die doel 'n publieke VPN-eindpunt is, is die Elastic IP die regte instrument: afgeleë eweknieë verbind daarmee oor die internet en die versleutelde transport eindig op die instansie. Die innerlike toepassingsverkeer gebruik dan die private adres.

As die doel private toegang tot die toepassing is, is die bestemming die private adres of 'n private DNS-naam wat daarheen oplos, en die VPN-roete, sekuriteitsgroep en retourpad moet almal saamstem. Die Elastic IP verskyn glad nie in daardie ontwerp nie.

As die doel 'n stabiele publieke uitgangsidentiteit vir VPN-gebruikers is, is dit 'n NAT-ontwerp aan die uitgangskant, nie 'n adres op die kliënt se tonnel nie. Drie doelwitte wat soortgelyk klink, lewer drie verskillende diagramme, en net een daarvan behels dat 'n Elastic IP iewers nuuts geplaas word.

Verifieer die pad wat jy gekies het

Vir private toegang, bevestig die VPN-roete dek die private voorvoegsel, die VPC-roetetabel stuur verkeer terug na die tonnel, die sekuriteitsgroep laat die kliënt se bron toe en die kliënt se eie vuurmuur laat die antwoord deur. Toets dan een werklike versoek eerder as 'n ping.

Vir publieke toegang, bevestig die kliënt se internetuitgang, die publieke toegang se roetering en sy sekuriteitsbeleid. Of 'n VPN-kliënt 'n publieke eindpunt deur die tonnel kan bereik, hang af van die tonnel se uitgangs- en vuurmuurreëls, nie van die Elastic IP-assosiasie nie.

As 'n publieke gasheernaam van beide kante moet werk, gebruik 'n DNS-ontwerp wat die private adres vir VPN-kliënte antwoord en die publieke adres vir almal anders, en hou die sertifikaat geldig vir die naam eerder as die adres. Orde van werk: benoem die doel, kies die adres wat daaraan behoort, verifieer dan roetes, beleid en een versoek.