EC2 oor beskikbaarheidsones: kontroleer roetering voor 'n VPN

Voordat jy VPN-sagteware tussen twee EC2-instansies installeer, beantwoord een vraag: is hulle in dieselfde VPC? As dit so is, bestaan die private pad reeds en 'n plasing oor zones verander dit nie. Die meeste werk in hierdie situasie is om te bevestig watter roetetabel elke subnet werklik gebruik, en dan vas te stel of die fout ooit 'n roeteringsprobleem was. 'n Tonnel is gewoonlik die verkeerde antwoord op hierdie spesifieke vraag.

Kontrole 1: dieselfde VPC of verskillende VPC's

'n VPC is streeksgebonde en strek oor beskikbaarheidsones, terwyl elke subnet aan presies een sone behoort. Twee instansies in verskillende sones van een VPC is steeds binne dieselfde private roeteringsdomein.

Verskillende VPC's kry nooit 'n private roete omdat hulle 'n streek of 'n sonelabel deel nie. Daardie geval het 'n ondersteunde verbinding en sy eie roete- en toestemmingswerk nodig, wat 'n aparte besluit is.

Kontrole 2: wat die subnet-roetetabelle se

Skryf die uitleg met werklike waardes neer. 'n VPC by 10.60.0.0/16 met subnette 10.60.1.0/24 en 10.60.2.0/24 gee instansies 10.60.1.10 en 10.60.2.20 'n pad deur die VPC se plaaslike roete.

Ondersoek dan die tabelle wat met albei subnette geassosieer word, nie net die een wat jy eerste gevind het nie. 'n Meer spesifieke inspeksie- of toestelroete kan die basislyn oorheers, en die plaaslike roete se teiken kan self in nuwer konfigurasies vervang word. 'n Plaaslike roete wat erens in die konsole sigbaar is, bewys nie dat albei werklading dit gebruik nie.

Gebruik die private adresse en name wat die VPC werklik toeken. 'n Private adres hoef nie met 10 te begin nie, en om een uit die geheue te versin, is hoe 'n werkende omgewing verkeerd gediagnoseer word.

Kontrole 3: roetering of magtiging

Roetering kry net die pakkie by die teiken se netwerkkoppelvlak. Die teiken-sekuriteitsgroep moet steeds die bron en die diens toelaat, die bron se uitgangsreels moet die versoek toelaat, en enige netwerk-ACL moet beide rigtings permitteer omdat ACL's toestandsloos is.

Daarbenewens is daar die gasheer-vuurmuur, die luisteraar se binding en die toepassing se eie identiteit. Elkeen kan 'n versoek weier wat roetering perfek afgelewer het.

Aanvaarding moet die werklike toepassingsbewerking wees. 'n Suksesvolle ping gee nie toegang tot die toepassing nie en bewys nie dat 'n TLS-naam en geloofsbriewe korrek is nie, en 'n geblokkeerde ping bewys nie dat elke private diens af is nie.

Kontrole 4: is 'n aparte verbinding werklik nodig

'n VPN kan steeds in die ontwerp hoort, maar om 'n genoemde rede: om hierdie VPC aan 'n kantoor te koppel, skootrekenaars toe te laat of aan 'n oorlegvereiste te voldoen. Daardie rede verskil van gewone kommunikasie binne dieselfde VPC.

Onthou ook wat die VPC nie is nie. Dit is nie 'n uitbreiding van 'n huishoudelike Ethernet-segment nie. 'n Toepassing wat van uitsaai-ontdekking afhanklik is, het 'n aparte vereiste om te evalueer. Dit is 'n ontwerpgaping eerder as 'n roeteringsfout.

Kontrole 5: die enkripsievraag

'n Private adres en 'n toelaatreel se niks oor kriptografiese beskerming op die toepassingslaag nie. As die data end-tot-end-beskerming nodig het, kom dit van die protokol en identiteitsmodel wat die diens werklik ondersteun.

Hou netwerklaag- en toepassingslaag-aansprake apart in die ontwerpnota, want om hulle te vermeng, is hoe 'n oorsig uiteindelik beskerming beweer wat niemand geimplementeer het nie.

Wat om op te teken

Teken albei subnet-ID's op, die roetetabel wat met elkeen geassosieer word, die sekuriteitsgroepverwysings en die toepassingsbewerking wat jy getoets het. Dit is vier feite, en hulle besleg die meeste toekomstige argumente oor hierdie pad.

Soneplasing alleen se nooit vir jou om 'n VPN by te voeg nie, en dit verduidelik nooit waarom 'n private versoek misluk het nie.