EC2 kättesaadavustsoonide vahel: kontrollige marsruutimist enne VPN-i

Enne VPN-tarkvara paigaldamist kahe EC2 eksemplari vahele vastake ühele küsimusele: kas need asuvad samas VPC-s? Kui jah, siis privaatne tee on juba olemas ja paigutus eri tsoonidesse ei muuda seda. Suurem osa tööst seisneb selles olukorras selle kinnitamises, millist marsruutimistabelit iga alámvõrk tegelikult kasutab, ja seejärel väljaselgitamises, kas tõrge oli üldse marsruutimisprobleem. Tunnel on sellele konkreetsele küsimusele tavaliselt vale vastus.

Kontroll 1: sama VPC või erinevad VPC-d

VPC on piirkondlik ja hõlmab kättesaadavustsoone, samas kui iga alámvõrk kuulub täpselt ühte tsooni. Kaks eksemplari ühe VPC eri tsoonides on endiselt sama privaatse marsruutimisdomeeni sees.

Erinevad VPC-d ei saa kunagi privaatset marsruuti ainult seetõttu, et nad jagavad piirkonda või tsooni silti. See juhtum vajab toetatud ühendust ning eraldi tööd marsruutide ja õigustega, mis on omaette otsus.

Kontroll 2: mida ütlevad alámvõrkude marsruutimistabelid

Kirjutage paigutus üles tegelike väärtustega. VPC aadressil 10.60.0.0/16 alámvõrkudega 10.60.1.0/24 ja 10.60.2.0/24 annab eksemplaridele 10.60.1.10 ja 10.60.2.20 tee läbi VPC kohaliku marsruudi.

Seejärel uurige mõlema alámvõrguga seotud tabeleid, mitte ainult seda, mille leidsite esimesena. Konkreetsem kontrolli- või seadmemarsruut võib baasjoone üle kirjutada ja kohaliku marsruudi sihtmärk võib uuemates konfiguratsioonides ise asenduda. Kusagil konsoolis nähtav kohalik marsruut ei tõesta, et mõlemad töökoormused seda kasutavad.

Kasutage privaatseid aadresse ja nimesid, mida VPC tegelikult määrab. Privaatne aadress ei pea algama numbriga 10 ja mälust ühe väljamõtlemine on viis, kuidas töötav keskkond valesti diagnoositakse.

Kontroll 3: marsruutimine või autoriseerimine

Marsruutimine viib paketi ainult sihtkoha võrguliideseni. Sihtkoha turvagrupp peab ikkagi allika ja teenuse lubama, allika väljuvad reeglid peavad päringu lubama ja iga võrgu-ACL peab lubama mõlemat suunda, sest ACL-id ei säilita olekut.

Sellest tagapool on külalise tulemüür, kuulaja sidumine ja rakenduse enda identiteet. Igaüks neist võib keelduda päringust, mille marsruutimine laitmatult kohale toimetas.

Vastuvõtt peab olema rakenduse tegelik toiming. Edukas ping ei anna rakendusele juurdepääsu ega tõesta, et TLS-i nimi ja mandaadid on õiged, ning blokeeritud ping ei tõesta, et iga privaatne teenus on maas.

Kontroll 4: kas eraldi ühendust on tõesti vaja

VPN võib endiselt disaini kuuluda, aga nimetatud põhjusel: selle VPC ühendamine kontoriga, sülearvutite lubamine või ülekattetasandi nõude täitmine. See põhjus erineb tavalisest suhtlusest sama VPC sees.

Pidage meeles ka seda, mis VPC ei ole. See ei ole koduse Etherneti segmendi laiendus. Rakendus, mis sõltub leviedastuse tuvastamisest, vajab eraldi hindamist. See on disainilünk, mitte marsruutimisviga.

Kontroll 5: krüpteerimise küsimus

Privaatne aadress ja lubamisreegel ei ütle midagi krüptograafilise kaitse kohta rakenduskihis. Kui andmed vajavad kaitset otsast lõpuni, tuleb see protokollist ja identiteedimudelist, mida teenus tegelikult toetab.

Hoidke võrgu- ja rakenduskihi väited projekteerimismärkuses lahus, sest nende ühendamine on viis, kuidas ülevaatus lõpuks väidab kaitset, mida keegi ei rakendanud.

Mida kirja panna

Pange kirja mõlema alámvõrgu identifikaator, kummagagi seotud marsruutimistabel, turvagruppide viited ja rakenduse toiming, mida testisite. Need on neli fakti ja need lahendavad enamiku tulevasi vaidlusi selle tee üle.

Ainult paigutus tsoonis ei ütle teile kunagi, et lisage VPN, ja ei selgita kunagi, miks privaatne päring ebaõnnestus.