EC2 oer beskikberenssônes: kontrolearje routing foar in VPN

Foardat jo VPN-software tusken twa EC2-eksimplaren ynstallearje, beäntwurdzje ien fraach: sitte se yn deselde VPC? As dat sa is, bestiet it privee paad al en in pleatsing oer sônes feroaret dat net. It measte wurk yn dizze situaasje is befêstigje hokker routingstabel elk subnet echt brûkt, en dêrnei útfine oft de flater ea in routingprobleem wie. In tunnel is meastentiids it ferkearde antwurd op dizze spesifike fraach.

Kontrôle 1: deselde VPC as ferskate VPC's

In VPC is regionaal en omfettet beskikberenssônes, wylst elk subnet by krekt ien sône heart. Twa eksimplaren yn ferskate sônes fan ien VPC sitte noch altyd yn itselde privee routingdomein.

Ferskate VPC's krije nea in privee rûte om't se in regio of in sône-etiket diele. Dat gefal freget in stipe ferbining en eigen wurk oan rûtes en tastimmingen, wat in apart beslút is.

Kontrôle 2: wat de routingstabellen fan de subnets sizze

Skriuw de opstelling op mei echte wearden. In VPC op 10.60.0.0/16 mei subnets 10.60.1.0/24 en 10.60.2.0/24 jout de eksimplaren 10.60.1.10 en 10.60.2.20 in paad fia de lokale rûte fan de VPC.

Undersykje dêrnei de tabellen dy't oan beide subnets keppele binne, net allinnich dy't jo earst fûnen. In spesifiker ynspeksje- as apparaatrûte kin de basisrûte oerskriuwe, en it doel fan de lokale rûte kin sels ferfongen wurde yn nijere konfiguraasjes. In lokale rûte dy't earne yn 'e konsole te sjen is, bewiist net dat beide wurklasten dy brûke.

Brûk de privee adressen en nammen dy't de VPC echt tawijst. In privee adres hoecht net mei 10 te begjinnen, en ien út it ûnthâld betinke is de manier wêrop in wurkjende omjouwing ferkeard diagnoaze wurdt.

Kontrôle 3: routing of autorisaasje

Routing bringt it pakket allinnich nei de netwurkynterface fan it doel. De befeiligingsgroep fan it doel moat noch de boarne en de tsjinst talitte, de útgeande regels fan de boarne moatte it fersyk tastean, en elke netwurk-ACL moat beide rjochtingen tastean om't ACL's gjin tastân ûnthâlde.

Dêrefter sitte de gastfirewall, de bining fan de listener en de eigen identiteit fan de applikaasje. Elk fan harren kin in fersyk wegerje dat routing perfekt levere hat.

De akseptaasje moat de echte applikaasje-operaasje wêze. In slagge ping jout gjin applikaasjetagong en bewiist net dat in TLS-namme en oanmeldgegevens korrekt binne, en in blokkearre ping bewiist net dat elke privee tsjinst del is.

Kontrôle 4: is in aparte ferbining echt nedich

In VPN kin noch altyd yn it ûntwerp hearre, mar om in neamde reden: dizze VPC mei in kantoar ferbine, laptops talitte of foldwaan oan in oerlappend laachferlet. Dy reden ferskilt fan gewoane kommunikaasje binnen deselde VPC.

Tink ek oan wat de VPC net is. It is gjin útwreiding fan in húshâldlik Ethernet-segmint. In applikaasje dy't fan broadcast-ûntdekking ôfhinklik is, hat in apart ferlet om te beoardieljen. Dat is in ûntwerkleemte en gjin routingflater.

Kontrôle 5: de fersiferingfraach

In privee adres en in tastimmingsregel sizze neat oer kryptografyske beskerming op de applikaasjelaach. As de gegevens beskerming fan ein oant ein nedich hawwe, komt dy fan it protokol en it identiteitsmodel dat de tsjinst echt stipet.

Hâld bewearings oer de netwurklach en de applikaasjelaach apart yn 'e ûntwerpnotysje, want se gearfoegje is hoe't in resinsje úteinlik beskerming beweart dy't nimmen implementearre hat.

Wat op te tekenjen

Tekenje beide subnet-ID's op, de routingstabel dy't oan elk keppele is, de befeiligingsgroepferwizings en de applikaasje-operaasje dy't jo testen. Dat binne fjouwer feiten, en se besljochtsje de measte takomstige diskusjes oer dit paad.

Sôneplakking allinnich seit jo nea om in VPN ta te foegjen, en it ferklearret nea wêrom't in privee fersyk mislearre.