EC2 saatavuusvyöhykkeiden välillä: tarkista reititys ennen VPN:ää

Ennen kuin asennat VPN-ohjelmiston kahden EC2-instanssin väliin, vastaa yhteen kysymykseen: ovatko ne samassa VPC:ssä? Jos ovat, yksityinen polku on jo olemassa, eikä sijoittaminen eri vyöhykkeille muuta sitä. Suurin osa tässä tilanteessa tehtävästä työstä on sen vahvistamista, mitä reititystaulukkoa kukin aliverkko todella käyttää, ja sen selvittämistä, oliko vika ylipäätään reititysongelma. Tunneli on yleensä väärä vastaus tähän nimenomaiseen kysymykseen.

Tarkistus 1: sama VPC vai eri VPC:t

VPC on alueellinen ja kattaa saatavuusvyöhykkeet, kun taas kukin aliverkko kuuluu täsmälleen yhteen vyöhykkeeseen. Kaksi instanssia yhden VPC:n eri vyöhykkeillä on yhä saman yksityisen reititysalueen sisällä.

Erilliset VPC:t eivät koskaan saa yksityistä reittiä vain siksi, että ne jakavat alueen tai vyöhyketunnisteen. Sellainen tapaus vaatii tuetun yhteyden sekä oman työn reittien ja käyttöoikeuksien parissa, mikä on erillinen päätös.

Tarkistus 2: mitä aliverkkojen reititystaulukot sanovat

Kirjoita asetelma ylös todellisilla arvoilla. VPC osoitteessa 10.60.0.0/16 aliverkkoineen 10.60.1.0/24 ja 10.60.2.0/24 antaa instansseille 10.60.1.10 ja 10.60.2.20 polun VPC:n paikallisen reitin kautta.

Tarkastele sitten molempiin aliverkkoihin liitettyjä taulukoita, älä vain sitä, jonka löysit ensin. Tarkempi tarkastus- tai laitereitti voi ohittaa perusreitin, ja paikallisen reitin kohde voi itsessään korvautua uudemmissa kokoonpanoissa. Konsolissa jossain näkyvä paikallinen reitti ei todista, että molemmat työkuormat käyttävät sitä.

Käytä niitä yksityisiä osoitteita ja nimiä, jotka VPC todella myöntää. Yksityisen osoitteen ei tarvitse alkaa numerolla 10, ja muistista keksitty osoite on juuri se tapa, jolla toimiva ympäristö diagnosoidaan väärin.

Tarkistus 3: reititys vai valtuutus

Reititys vie paketin vain kohteen verkkoliitännälle. Kohteen tietoturvaryhmän on yhä hyväksyttävä lähde ja palvelu, lähteen ulosmenevien sääntöjen on sallittava pyyntö, ja minkä tahansa verkon ACL:n on sallittava molemmat suunnat, koska ACL:t eivät muista tilaa.

Sen takana ovat vieraan palomuuri, kuuntelijan sidonta ja sovelluksen oma identiteetti. Jokainen niistä voi hylätä pyynnön, jonka reititys toimitti moitteettomasti.

Hyväksynnän on oltava sovelluksen todellinen toiminto. Onnistunut ping ei anna sovelluskäyttöoikeutta eikä todista, että TLS-nimi ja tunnistetiedot ovat oikein, eikä estetty ping osoita, että jokainen yksityinen palvelu on alas ajettu.

Tarkistus 4: tarvitaanko erillinen yhteys todella

VPN voi yhä kuulua suunnitelmaan, mutta ilmoitetusta syystä: tämän VPC:n yhdistäminen toimistoon, kannettavien päästäminen sisään tai peittoverkon vaatimuksen täyttäminen. Tämä syy eroaa tavallisesta saman VPC:n sisäisestä viestinnästä.

Muista myös, mikä VPC ei ole. Se ei ole kotiverkon Ethernet-segmentin jatke. Sovellus, joka riippuu lähetystoimintaisesta havaitsemisesta, tarvitsee erillisen vaatimuksen arvioitavaksi. Se on suunnittelun aukko, ei reititysvirhe.

Tarkistus 5: salauskysymys

Yksityinen osoite ja sallintasääntö eivät kerro mitään salausteknisestä suojauksesta sovelluskerroksessa. Jos tiedot tarvitsevat päästä päähän -suojausta, se tulee protokollasta ja identiteettimallista, jota palvelu todella tukee.

Pidä verkkokerroksen ja sovelluskerroksen väitteet erillään suunnittelumuistiossa, sillä niiden yhdistäminen on se tapa, jolla katselmus lopulta väittää suojausta, jota kukaan ei toteuttanut.

Mitä kirjata

Kirjaa molempien aliverkkojen tunnisteet, kuhunkin liittyvä reititystaulukko, tietoturvaryhmien viittaukset ja testaamasi sovellustoiminto. Nämä ovat neljä tosiseikkaa, ja ne ratkaisevat useimmat tulevat kiistat tästä polusta.

Pelkkä sijoittaminen vyöhykkeelle ei koskaan kerro, että lisäisit VPN:n, eikä se koskaan selitä, miksi yksityinen pyyntö epäonnistui.