Een EC2 Elastic IP is niet het privé-VPN-adres van de instantie

De instantie heeft een privéadres, de Elastic IP is eraan gekoppeld, en er wordt een route voor die openbare /32 aan de VPN toegevoegd in de hoop dat beide hetzelfde worden. Dat worden ze niet. Een Elastic IP is een vertaling die buiten de gast plaatsvindt, door de internetgateway, op verkeer dat het internetpad volgt. Het besturingssysteem van de gast ziet dat adres nooit op een interface geconfigureerd. Het toevoegen aan een tunnelinterface reproduceert de upstream-vertaling niet en creëert een tweede, tegenstrijdige identiteit voor dezelfde machine.

Twee adressen, één instantie

De netwerkinterface van de instantie heeft een privéadres binnen de VPC, en dat is het adres dat de gast kent. De Elastic IP is aan dezelfde interface gekoppeld maar leeft aan de openbare kant van de mapping.

Alles wat de instantie via internet bereikt, komt vertaald naar het privéadres aan. Alles wat de instantie naar internet stuurt, vertrekt met de Elastic IP als bron, wederom door die vertaling.

Binnen de gast bestaat één adres. Buiten bestaan er twee. Die asymmetrie verklaart het meeste van de verwarring op dit gebied. De gast kan niet configureren wat de gateway vertaalt. Hij kan alleen antwoorden op het adres dat hij werkelijk heeft.

Wat de internetgateway werkelijk doet

De AWS-documentatie over de internetgateway beschrijft de opzet: de instantie kent haar privé-IPv4-adres en de gateway levert de bijbehorende vertaling naar een openbaar IPv4- of Elastic IP-adres voor verkeer op het internetpad.

Dat is netwerkadresvertaling, geen alias. De mapping wordt door de gateway onderhouden, is aan de associatie gebonden en geldt alleen voor pakketten die erdoorheen gaan. Verwijder de associatie en de openbare identiteit verdwijnt zonder dat de gast iets merkt.

Daarom wordt een privé-VPN-pakket dat aan de openbare /32 is geadresseerd niet opnieuw geïnterpreteerd als een privépakket naar het lokale adres van de gast. Het pakket volgt de route die erbij past, die het naar de internetgateway stuurt, en het gedrag van de gateway hangt af van of het pad in beide richtingen is toegestaan.

Waarom de tunnelinterface-truc mislukt

Het toewijzen van de Elastic IP aan een tunnelinterface vraagt de gast een openbaar adres als lokaal te behandelen. Nu claimen twee dingen hetzelfde adres: de vertaling van de gateway op het internetpad en de lokale interface in de tunnel. Retourverkeer heeft geen consistent antwoord over welke geldt.

Zelfs wanneer het lijkt te werken, heeft het ontwerp de echte vraag verborgen. Clients bereiken ofwel het privéadres via de tunnel ofwel het openbare eindpunt via internet, en de twee paden hebben verschillende beveiligingsgroepen, verschillende logging en verschillende faalmodi.

Het adres was nooit het probleem. De padkeuze was het.

Drie doelen, drie ontwerpen

Als het doel een openbaar VPN-eindpunt is, is de Elastic IP het juiste hulpmiddel: externe peers verbinden er via internet mee en het versleutelde transport eindigt op de instantie. Het interne applicatieverkeer gebruikt daarna het privéadres.

Als het doel privétoegang tot de applicatie is, is de bestemming het privéadres of een privé-DNS-naam die daarheen resolvet, en de VPN-route, de beveiligingsgroep en het retourpad moeten allemaal overeenkomen. De Elastic IP komt in dat ontwerp helemaal niet voor.

Als het doel een stabiele openbare egress-identiteit voor VPN-gebruikers is, is dat een NAT-ontwerp aan de egress-kant, geen adres op de tunnel van de client. Drie doelen die hetzelfde klinken leveren drie verschillende diagrammen op, en slechts één ervan houdt in dat een Elastic IP ergens nieuws wordt geplaatst.

Controleer het pad dat u hebt gekozen

Controleer voor privétoegang dat de VPN-route het privéprefix dekt, dat de routetabel van de VPC verkeer naar de tunnel terugstuurt, dat de beveiligingsgroep de bron van de client toestaat en dat de firewall van de client zelf het antwoord toestaat. Test daarna één echt verzoek in plaats van een ping.

Controleer voor openbare toegang de internet-egress van de client, de routering van de openbare ingang en het beveiligingsbeleid daarvan. Of een VPN-client een openbaar eindpunt via de tunnel kan bereiken, hangt af van de egress- en firewallregels van de tunnel, niet van de Elastic IP-associatie.

Als een openbare hostnaam vanaf beide kanten moet werken, gebruik dan een DNS-ontwerp dat antwoordt met het privéadres voor VPN-clients en het openbare adres voor alle anderen, en houd het certificaat geldig voor de naam in plaats van het adres. Werkvolgorde: benoem het doel, kies het adres dat erbij hoort en controleer daarna routes, beleid en één verzoek.