EC2 starp pieejamības zonām: pirms VPN pārbaudiet maršrutēšanu

Pirms VPN programmatūras instalēšanas starp divām EC2 instancēm, atbildiet uz vienu jautājumu: vai tās ir vienā VPC? Ja jā, privātais ceļš jau pastāv, un izvietojums dažādās zonās to nemaina. Lielākā daļa darba šajā situācijā ir apstiprināt, kuru maršrutēšanas tabulu katrs apakštīkls faktiski izmanto, un pēc tam noskaidrot, vai kļūme vispār bija maršrutēšanas problēma. Tunelis parasti ir nepareiza atbilde uz šo konkrēto jautājumu.

Pārbaude 1: viens un tas pats VPC vai dažādi VPC

VPC ir reģionāls un aptver pieejamības zonas, bet katrs apakštīkls pieder tieši vienai zonai. Divas instances dažādās viena VPC zonās joprojām atrodas tajā pašā privātās maršrutēšanas domēnā.

Dažādi VPC nekad nesaņem privātu maršrutu tikai tāpēc, ka tiem ir kopīgs reģions vai zonas marķējums. Šāds gadījums prasa atbalstītu savienojumu un savu darbu ar maršrutiem un atļaujām, kas ir atsevišķs lēmums.

Pārbaude 2: ko saka apakštīklu maršrutēšanas tabulas

Pierakstiet izkārtojumu ar reālām vērtībām. VPC ar adresi 10.60.0.0/16 ar apakštīkliem 10.60.1.0/24 un 10.60.2.0/24 piešķir instancēm 10.60.1.10 un 10.60.2.20 ceļu caur VPC lokālo maršrutu.

Pēc tam pārbaudiet tabulas, kas saistītas ar abiem apakštīkliem, nevis tikai to, kuru atradāt pirmo. Konkrētāks pārbaudes vai ierīces maršruts var aizstāt bāzes maršrutu, un lokālā maršruta mērķis pats var tikt aizstāts jaunākās konfigurācijās. Konsolē kaut kur redzams lokālais maršruts nepierāda, ka abi darba apjomi to izmanto.

Izmantojiet tās privātās adreses un nosaukumus, ko VPC faktiski piešķir. Privātai adresei nav jāsākas ar 10, un izdomāšana no atmiņas ir veids, kā funkcionējošu vidi diagnosticēt nepareizi.

Pārbaude 3: maršrutēšana vai autorizācija

Maršrutēšana tikai nogādā pakešu tīkla interfeisā. Mērķa drošības grupai joprojām jāpieņem avots un pakalpojums, avota izejošajiem noteikumiem jāatļauj pieprasījums, un jebkuram tīkla ACL jāatļauj abi virzieni, jo ACL neuzglabā stāvokli.

Aiz tā atrodas viesa ugunsmūris, klausītāja piesaiste un pašas lietojumprogrammas identitāte. Jebkurš no tiem var noraidīt pieprasījumu, ko maršrutēšana piegādāja nevainojami.

Pieņemšanai jābūt īstajai lietojumprogrammas darbībai. Veiksmīgs ping nepiešķir piekļuvi lietojumprogrammai un nepierāda, ka TLS nosaukums un akreditācijas dati ir pareizi, un bloķēts ping nepierāda, ka visi privātie pakalpojumi ir izslēgti.

Pārbaude 4: vai tiešām ir vajadzīgs atsevišķs savienojums

VPN joprojām var būt dizainā, bet ar norādītu iemeslu: savienot šo VPC ar biroju, ielaist klēpjdatorus vai izpildīt pārklājuma prasību. Šis iemesls atšķiras no parastas saziņas vienā VPC.

Atcerieties arī to, kas VPC nav. Tas nav mājas Ethernet segmenta paplašinājums. Lietojumprogrammai, kas balstās uz apraides atklāšanu, ir atsevišķa prasība, kas jāizvērtē. Tā ir dizaina nepilnība, nevis maršrutēšanas kļūda.

Pārbaude 5: šifrēšanas jautājums

Privāta adrese un atļaujas noteikums neko nepasaka par kriptogrāfisko aizsardzību lietojumprogrammu slānī. Ja datiem nepieciešama aizsardzība no gala līdz galam, tā nāk no protokola un identitātes modeļa, ko pakalpojums faktiski atbalsta.

Dizaina piezīmē turiet atsevišķi tīkla un lietojumprogrammu slāņa apgalvojumus, jo to sapludināšana ir veids, kā pārskats galu galā apgalvo aizsardzību, ko neviens nav ieviesis.

Kas jāpieraksta

Pierakstiet abus apakštīklu identifikatorus, ar katru saistīto maršrutēšanas tabulu, drošības grupu atsauces un lietojumprogrammas darbību, ko pārbaudījāt. Tie ir četri fakti, un tie atrisina lielāko daļu nākotnes strīdu par šo ceļu.

Tikai izvietojums zonā nekad nepasaka, ka jāpievieno VPN, un nekad neizskaidro, kāpēc privāts pieprasījums neizdevās.