EC2:n Elastic IP ei ole instanssin yksityinen VPN-osoite

Instanssilla on yksityinen osoite, Elastic IP on liitetty siihen, ja reitti tuolle julkiselle /32:lle lisätään VPN:ään siinä toivossa, että kahdesta tulisi sama asia. Niistä ei tule. Elastic IP on käännös, joka tehdään vieraan ulkopuolella, internet-yhdyskäytävän toimesta, liikenteelle, joka kulkee internet-polkua. Vieraan käyttöjärjestelmä ei näe kyseistä osoitetta koskaan liitännälle konfiguroituna. Sen lisääminen tunneliliitännälle ei toista ylempänä tehtyä käännöstä ja luo samalle koneelle toisen, ristiriitaisen identiteetin.

Kaksi osoitetta, yksi instanssi

Instanssin verkkoliitäntä pitää sisällään yksityisen osoitteen VPC:n sisällä, ja se on osoite, jonka vieras tuntee. Elastic IP on liitetty samaan liitäntään mutta elää kartoituksen julkisella puolella.

Kaikki, mikä saavuttaa instanssin internetin kautta, saapuu yksityiseen osoitteeseen käännettynä. Kaikki, mitä instanssi lähettää internetiin, lähtee Elastic IP lähteenään, jälleen tuon käännöksen vuoksi.

Vieraan sisällä on yksi osoite. Ulkopuolella on kaksi. Tämä epäsymmetria selittää suurimman osan tämän alueen sekaannuksesta. Vieras ei voi konfiguroida sitä, mitä yhdyskäytävä kääntää. Se voi vastata vain osoitteessa, joka sillä todella on.

Mitä internet-yhdyskäytävä todella tekee

AWS:n internet-yhdyskäytävää koskeva dokumentaatio kuvaa järjestelyn: instanssi tuntee oman yksityisen IPv4-osoitteensa, ja yhdyskäytävä tarjoaa vastaavan julkisen IPv4- tai Elastic IP -käännöksen internet-polkua kulkevalle liikenteelle.

Se on verkko-osoitteiden käännös, ei alias. Yhdyskäytävä ylläpitää kartoitusta, se on sidottu liitokseen ja koskee vain paketteja, jotka kulkevat sen kautta. Poista liitos, ja julkinen identiteetti katoaa vieraan huomaamatta mitään.

Siksi julkiseen /32:een osoitettua yksityistä VPN-pakettia ei tulkita uudelleen yksityiseksi paketiksi vieraan paikalliseen osoitteeseen. Paketti seuraa reittiä, jota se vastaa, ja se lähettää sen internet-yhdyskäytävälle; yhdyskäytävän toiminta riippuu siitä, onko polku sallittu molempiin suuntiin.

Miksi tunneliliitäntätemppu epäonnistuu

Elastic IP:n osoittaminen tunneliliitännälle pyytää vierasta kohtelemaan julkista osoitetta paikallisena. Nyt kaksi asiaa vaatii samaa osoitetta: yhdyskäytävän käännös internet-polkua pitkin ja tunnelin sisäinen paikallinen liitäntä. Paluuliikenteellä ei ole johdonmukaista vastausta siitä, kumpi pätee.

Vaikka se näyttäisi toimivan, suunnittelu on piilottanut varsinaisen kysymyksen. Asiakkaat joko saavuttavat yksityisen osoitteen tunnelin kautta tai julkisen päätepisteen internetin kautta, ja näillä kahdella polulla on erilaiset turvaryhmät, erilainen lokitus ja erilaiset vikatilat.

Osoite ei ollut koskaan ongelma. Polun valinta oli.

Kolme tavoitetta, kolme suunnittelua

Jos tavoitteena on julkinen VPN-päätepiste, Elastic IP on oikea työkalu: etävertaiset yhdistävät siihen internetin kautta ja salattu siirto päättyy instanssille. Sovelluksen sisäinen liikenne käyttää sen jälkeen yksityistä osoitetta.

Jos tavoitteena on yksityinen pääsy sovellukseen, kohteena on yksityinen osoite tai yksityinen DNS-nimi, joka ratkeaa siihen, ja VPN-reitin, turvaryhmän ja paluupolun on kaikkien sovittava yhteen. Elastic IP ei esiinny siinä suunnittelussa lainkaan.

Jos tavoitteena on vakaa julkinen lähtöidentiteetti VPN-käyttäjille, se on NAT-suunnittelu lähtöpuolella, ei osoite asiakkaan tunnelissa. Kolme samankaltaiselta kuulostavaa tavoitetta tuottavat kolme erilaista kaaviota, ja vain yksi niistä sisältää Elastic IP:n sijoittamisen uuteen paikkaan.

Vahvista valitsemasi polku

Vahvista yksityistä pääsyä varten, että VPN-reitti kattaa yksityisen etuliitteen, että VPC:n reititystaulukko palauttaa liikenteen tunneliin, että turvaryhmä sallii asiakkaan lähteen ja että asiakkaan oma palomuuri sallii vastauksen. Testaa sitten yksi todellinen pyyntö pingin sijaan.

Vahvista julkista pääsyä varten asiakkaan internet-lähtö, julkisen sisäänkäynnin reititys ja sen turvakäytäntö. Se, voiko VPN-asiakas saavuttaa julkisen päätepisteen tunnelin kautta, riippuu tunnelin lähtö- ja palomuurisäännöistä, ei Elastic IP -liitoksesta.

Jos julkisen isäntänimen on toimittava molemmilta puolilta, käytä DNS-suunnittelua, joka vastaa yksityisellä osoitteella VPN-asiakkaille ja julkisella osoitteella kaikille muille, ja pidä varmenne voimassa nimen eikä osoitteen mukaan. Työn järjestys: nimeä tavoite, valitse siihen kuuluva osoite ja vahvista sitten reitit, käytäntö ja yksi pyyntö.