Az EC2 Elastic IP nem az instance privát VPN-címe

Az instance-nek van egy privát címe, az Elastic IP hozzá van társítva, és egy útvonalat adnak a VPN-hez ehhez a nyilvános /32-höz abban a reményben, hogy a kettő ugyanaz lesz. Nem lesznek azok. Az Elastic IP olyan fordítás, amelyet a vendégen kívül, az internetes átjáró végez az internetes útvonalat használó forgalmon. A vendég operációs rendszere soha nem látja ezt a címet egy interfészen beállítva. Egy alagút-interfészhez hozzáadva nem reprodukálja a felsőbb fordítást, és második, ellentmondó identitást hoz létre ugyanahhoz a géphez.

Két cím, egy instance

Az instance hálózati interfésze privát címet tart a VPC-n belül, és ez az a cím, amelyet a vendég ismer. Az Elastic IP ugyanahhoz az interfészhez van társítva, de a leképezés nyilvános oldalán él.

Minden, ami az interneten keresztül eléri az instance-t, a privát címre fordítva érkezik. Minden, amit az instance az internetre küld, az Elastic IP-vel mint forrással lép ki, ismét e fordítás miatt.

A vendégen belül egy cím létezik. Kívül kettő. Ez az aszimmetria magyarázza a terület zavarának nagy részét. A vendég nem tudja beállítani, mit fordít az átjáró. Csak arra a címre tud válaszolni, amely valóban a birtokában van.

Mit tesz valójában az internetes átjáró

Az AWS internetes átjáróról szóló dokumentációja leírja az elrendezést: az instance ismeri a privát IPv4-címét, és az átjáró biztosítja a megfelelő nyilvános IPv4- vagy Elastic IP-fordítást az internetes útvonal forgalmához.

Ez hálózati címfordítás, nem alias. A leképezést az átjáró tartja fenn, a társításhoz kötődik, és csak a rajta áthaladó csomagokra vonatkozik. Távolítsa el a társítást, és a nyilvános identitás eltűnik anélkül, hogy a vendég bármit észrevenne.

Ezért a nyilvános /32-re címzett privát VPN-csomagot nem értelmezik újra a vendég helyi címére menő privát csomagként. A csomag azt az útvonalat követi, amelyhez illeszkedik, ez pedig az internetes átjáróhoz küldi, és az átjáró viselkedése attól függ, hogy az útvonal mindkét irányban engedélyezett-e.

Miért bukik el az alagút-interfész trükkje

Az Elastic IP alagút-interfészhez rendelése azt kéri a vendégtől, hogy a nyilvános címet helyiként kezelje. Most két dolog tart igényt ugyanarra a címre: az átjáró fordítása az internetes útvonalon és az alagúton belüli helyi interfész. A visszafolyó forgalomnak nincs következetes válasza arra, melyik érvényes.

Még ha működni is látszik, a tervezés elrejtette a valódi kérdést. Az ügyfelek vagy az alagúton keresztül érik el a privát címet, vagy az interneten keresztül a nyilvános végpontot, és a két útvonal biztonsági csoportjai, naplózása és hibaformái eltérnek.

A cím soha nem volt a probléma. Az útvonalválasztás volt az.

Három cél, három terv

Ha a cél egy nyilvános VPN-végpont, az Elastic IP a megfelelő eszköz: a távoli partnerek az interneten keresztül csatlakoznak hozzá, és a titkosított átvitel az instance-on végződik. A belső alkalmazásforgalom ezután a privát címet használja.

Ha a cél az alkalmazáshoz való privát hozzáférés, a cél a privát cím vagy egy privát DNS-név, amely erre oldódik fel, és a VPN-útvonalnak, a biztonsági csoportnak és a visszaútnak mind egyeznie kell. Az Elastic IP egyáltalán nem jelenik meg ebben a tervben.

Ha a cél stabil nyilvános kimenő identitás a VPN-felhasználók számára, az NAT-terv a kimenő oldalon, nem cím az ügyfél alagútján. Három hasonlóan hangzó cél három különböző diagramot ad, és csak az egyikük jár azzal, hogy egy Elastic IP-t új helyre tesznek.

Ellenőrizze a választott útvonalat

Privát hozzáférés esetén ellenőrizze, hogy a VPN-útvonal lefedi a privát előtagot, a VPC útvonaltáblája visszaküldi a forgalmat az alagútba, a biztonsági csoport engedélyezi az ügyfél forrását, és az ügyfél saját tűzfala engedélyezi a választ. Ezután egy valódi kérést teszteljen ping helyett.

Nyilvános hozzáférés esetén ellenőrizze az ügyfél internetes kimenetét, a nyilvános belépés útválasztását és annak biztonsági szabályzatát. Az, hogy egy VPN-ügyfél el tud-e érni egy nyilvános végpontot az alagúton keresztül, az alagút kimenő és tűzfal-szabályaitól függ, nem az Elastic IP társításától.

Ha egy nyilvános gazdanévnek mindkét oldalról működnie kell, használjon olyan DNS-tervet, amely a VPN-ügyfeleknek a privát címmel, mindenki másnak a nyilvános címmel válaszol, és a tanúsítványt a névhez, ne a címhez tartsa érvényesnek. A munka sorrendje: nevezze meg a célt, válassza ki a hozzá tartozó címet, majd ellenőrizze az útvonalakat, a szabályzatot és egy kérést.